Develop Bugs

Bootloop while changing Buildprops

Every time I change my Buildprops my phone ends up in a bootloop. I'm rooted, using 920 text editor and es file explorer. Made sure both had root access and the New build props saves successfully. I even set permissions. What am I doing wrong? I've been trying to switch my AT&T operated to open this put me in a bootloop twice. I also followed the Carrier IQ removal and went into a bootloop there as well. I'm doing something wrong that's for sure but what?

memtenn said:
Every time I change my Buildprops my phone ends up in a bootloop. I'm rooted, using 920 text editor and es file explorer. Made sure both had root access and the New build props saves successfully. I even set permissions. What am I doing wrong? I've been trying to switch my AT&T operated to open this put me in a bootloop twice. I also followed the Carrier IQ removal and went into a bootloop there as well. I'm doing something wrong that's for sure but what?
Click to expand...
Click to collapse
1. You can't change build prop without boot looping
2. You must be missing something whole trying to disable carrier iq, please list your steps on what you're doing to disable carrier iq as well as what your purpose is to alter build prop. I've disabled my carrier iq successfully with no bootloops

drock212 said:
1. You can't chRebootedrop without boot looping
2. You must be missing something whole trying to disable carrier iq, please list your steps on what you're doing to disable carrier iq as well as what your purpose is to alter build prop. I've disabled my carrier iq successfully with no bootloops
Click to expand...
Click to collapse
I followed the directions from the AT&T forum to
Get rid of my carrier I.Q. As for changing the operater to open instead of ATT I opened es file explorer went into settings tapped to run as root. Then I went into system build props opened with 920 text editor found ro. Operator AT&T switched it to open then saved it went back in to build props permission changed it to 644 saved it then rebooted. That's when it went into bootloop.

drock212 said:
1. You can't change build prop without boot looping
2. You must be missing something whole trying to disable carrier iq, please list your steps on what you're doing to disable carrier iq as well as what your purpose is to alter build prop. I've disabled my carrier iq successfully with no bootloops
Click to expand...
Click to collapse
I read on xda that it was easier to change the operator to open than it was to change carrier I.Q.

Yeah changing some build prop elements will do that with our phones. You need xposed, android tuner, titanium backup, and some sort of file explorer that lets you access system locations. Like root explorer. Give me a minute to find you all the information on how to disable carrier iq without touching build prop
---------- Post added at 08:27 PM ---------- Previous post was at 08:00 PM ----------
Follow these instructions. They're the ones I used.
http://forum.xda-developers.com/showthread.php?p=54217875
Only thing is I didn't delete laddm I froze it. And I didn't delete the lib files I just added .bak to them so they wouldn't be able go run. Hope this helps

Unable to edit build.prop file, need help

I am trying to enable Miracast by editing build.prop but system is not mounting. Tried ES file explorer and build prop editor too. I'm on stock Oreo right now. Any means to edit build prop? Unable to mount system to r/w.

Edit : The problem is may be due to Magisk, the systemless root prevents changes in system files. All the method I've tried the problem seems to be the Magisk. SuperSU working fine.

It is a very good idea not to edit build.prop directly using Magisk. You put some resetprop command in a directory (which changed with newest Magisk, before it was some init.d), and it will be executed on startup. There are quite some threads about this, just search for it.
I asked several times how to prevent system from being mounted r/w. I don't want any app to achieve this. If you find it how you did it, please tell me what to do to enable this problem prevention.

tag68 said:
It is a very good idea not to edit build.prop directly using Magisk. You put some resetprop command in a directory (which changed with newest Magisk, before it was some init.d), and it will be executed on startup. There are quite some threads about this, just search for it.
I asked several times how to prevent system from being mounted r/w. I don't want any app to achieve this. If you find it how you did it, please tell me what to do to enable this problem prevention.
Click to expand...
Click to collapse
I don't know how to do it, I am looking for ways. There is a magisk module for build prop but the problem is it's not for Oreo so it doesn't work. I think I need to make a module but I don't know how to make one.

You do not need to do a Magisk module, although it is possible to so. You probably want to do a shell skript. This is a text file with one line
resetprop (parameters)
You may need to write more lines into it, one for every property you need to change.
Until Magisk 16.3 there was some dir post.fs where you could put startup shell scripts. This changed recently. Please search for the syntax of resetprop and which dir you need to put the skript into.
Please ask how to to do it in this thread, there were some more people which had the same task.
Edit: As usual, do not forget to read the thread before asking anything

tag68 said:
You do not need to do a Magisk module, although it is possible to so. You probably want to do a shell skript. This is a text file with one line
resetprop (parameters)
You may need to write more lines into it, one for every property you need to change.
Until Magisk 16.3 there was some dir post.fs where you could put startup shell scripts. This changed recently. Please search for the syntax of resetprop and which dir you need to put the skript into.
Please ask how to to do it in this thread, there were some more people which had the same task.
Edit: As usual, do not forget to read the thread before asking anything
Click to expand...
Click to collapse
I don't get it. How am I supposed to do this? Any tutorial?

tag68 said:
It is a very good idea not to edit build.prop directly using Magisk. You put some resetprop command in a directory (which changed with newest Magisk, before it was some init.d), and it will be executed on startup. There are quite some threads about this, just search for it.
I asked several times how to prevent system from being mounted r/w. I don't want any app to achieve this. If you find it how you did it, please tell me what to do to enable this problem prevention.
Click to expand...
Click to collapse
I've found a Magisk module that do the same stuff, it's called Magisk props config. You can add tweaks to build prop without editing it. It's so easy and helpful.

how can i enable WiFi hotspot on my rooted device?

I'm using the Magisk module but it doesn't seem to be working

GroovinChip said:
I'm using the Magisk module but it doesn't seem to be working
Click to expand...
Click to collapse
So many variables in play with getting the native hotspot working. Mine is working fine. I'm on a Google Pixel XL. (Verizon) Android 9. Unlocked. Rooted (with Magisk 16.7 (1671)), Magisk Manager 5.8.3, and using the module MagiskHide Props Config to set the prop net.tethering.noprovisioning to true.
On Android 8 and earlier, the module "Tethering Enabler" worked, but I found it no longer worked once I upgraded to Android 9. The module MagiskHideProps Config allows you to set various custom props systemlessly (much as we used to back in the day by just editing the build.prop). You can find information on how to use the module on XDA and it is linked in the module documentation itself. (The module is very well documented. and creates a terminal UI that you execute from a terminal on your device (or via ADB if prefer). I use Termux (from play store on my device). Once you get the custom prop setup via the "Props" program, you can verify it is working via terminal emulator on the device or from computer/ADB by running as root getprop net.tethering.noprovisioning and verifying it returns true. I suspect that your issue is with the Tethering Enabler module (assuming that is what you are using) as I don't believe it was updated to keep up with the changes in Magisk and perhaps Android 9.
Anyways - good luck. Let me know how it goes.

sb1893 said:
So many variables in play with getting the native hotspot working. Mine is working fine. I'm on a Google Pixel XL. (Verizon) Android 9. Unlocked. Rooted (with Magisk 16.7 (1671)), Magisk Manager 5.8.3, and using the module MagiskHide Props Config to set the prop net.tethering.noprovisioning to true.
On Android 8 and earlier, the module "Tethering Enabler" worked, but I found it no longer worked once I upgraded to Android 9. The module MagiskHideProps Config allows you to set various custom props systemlessly (much as we used to back in the day by just editing the build.prop). You can find information on how to use the module on XDA and it is linked in the module documentation itself. (The module is very well documented. and creates a terminal UI that you execute from a terminal on your device (or via ADB if prefer). I use Termux (from play store on my device). Once you get the custom prop setup via the "Props" program, you can verify it is working via terminal emulator on the device or from computer/ADB by running as root getprop net.tethering.noprovisioning and verifying it returns true. I suspect that your issue is with the Tethering Enabler module (assuming that is what you are using) as I don't believe it was updated to keep up with the changes in Magisk and perhaps Android 9.
Anyways - good luck. Let me know how it goes.
Click to expand...
Click to collapse
If you're on Verizon you don't need to anything other than root the phone and the hotspot will work just fine.

airmaxx23 said:
If you're on Verizon you don't need to anything other than root the phone and the hotspot will work just fine.
Click to expand...
Click to collapse
That is only if you are subscribed to the hotspot as part of your plan. Most Verizon plans include some level of hotspot subscription - albeit with throttling to barely usable speeds after hitting data thresholds. I didn't mention that I am on a grandfathered unlimited plan which does not include hotspot. The setting of that build.prop that I mentioned circumvents the subscription check and allows my hotspot to work. Even if rooted, without that prop set, I hit the subscription check and am told to contact Verizon to subscribe. As I said - lots of variables with getting hotspot to work.

sb1893 said:
That is only if you are subscribed to the hotspot as part of your plan. Most Verizon plans include some level of hotspot subscription - albeit with throttling to barely usable speeds after hitting data thresholds. I didn't mention that I am on a grandfathered unlimited plan which does not include hotspot. The setting of that build.prop that I mentioned circumvents the subscription check and allows my hotspot to work. Even if rooted, without that prop set, I hit the subscription check and am told to contact Verizon to subscribe. As I said - lots of variables with getting hotspot to work.
Click to expand...
Click to collapse
I'm not on a hotspot plan and all I've ever done is root my device (currently a Pixel XL) and setup the hotspot and it works. I'm also grandfathered in with unlimited data and I did it just recently when installing Pie.

airmaxx23 said:
I'm not on a hotspot plan and all I've ever done is root my device (currently a Pixel XL) and setup the hotspot and it works. I'm also grandfathered in with unlimited data and I did it just recently when installing Pie.
Click to expand...
Click to collapse
Hmmmm - well that is interesting and certainly a different experience than mine. I've always had to do some level of mod - build.prop edits, modified carrierentitlement.apk in the SuperSu days and then tethering enabler or the systemless prop edit I just described on Magisk....(I'm also on a Pixel XL / Stock)

sb1893 said:
Hmmmm - well that is interesting and certainly a different experience than mine. I've always had to do some level of mod - build.prop edits, modified carrierentitlement.apk in the SuperSu days and then tethering enabler or the systemless prop edit I just described on Magisk....(I'm also on a Pixel XL / Stock)
Click to expand...
Click to collapse
Yeah that is a bit strange.

BuildProp Editor
Add line:
net.tethering.noprovisioning=true
save
reboot

crackerjack1957 said:
BuildProp Editor
Add line:
net.tethering.noprovisioning=true
save
reboot
Click to expand...
Click to collapse
This did it, thanks!
Sent from my Google Pixel XL using XDA Labs

Here is the newest module for magisk. Works for me.

tweaked said:
Here is the newest module for magisk. Works for me.
Click to expand...
Click to collapse
Cool - I didn't realize that module had been updated to work on PIE. Looks like a few viable options to get tethering working depending on preference. I'm going to stick with the MagiskHideProps method for now as it also allows for other systemless build.prop edits if any are needed in the future....Thanks, all!

tweaked said:
Here is the newest module for magisk. Works for me.
Click to expand...
Click to collapse
Do you install this via recovery? Or do I have to drop zip into a specific folder?
---------- Post added at 05:31 PM ---------- Previous post was at 05:30 PM ----------
sb1893 said:
Cool - I didn't realize that module had been updated to work on PIE. Looks like a few viable options to get tethering working depending on preference. I'm going to stick with the MagiskHideProps method for now as it also allows for other systemless build.prop edits if any are needed in the future....Thanks, all!
Click to expand...
Click to collapse
Curious what you are using to edit build prop. I have MagiskHideProps installed via Magisk but not sure how to edit build prop

cwburns32 said:
Do you install this via recovery? Or do I have to drop zip into a specific folder?
---------- Post added at 05:31 PM ---------- Previous post was at 05:30 PM ----------
Curious what you are using to edit build prop. I have MagiskHideProps installed via Magisk but not sure how to edit build prop
Click to expand...
Click to collapse
You can Flash with TWRP just make sure you know where you put it. I like to keep my stuff in downloads.
Sent from my Pixel XL using Tapatalk

cwburns32 said:
Do you install this via recovery? Or do I have to drop zip into a specific folder?
---------- Post added at 05:31 PM ---------- Previous post was at 05:30 PM ----------
Curious what you are using to edit build prop. I have MagiskHideProps installed via Magisk but not sure how to edit build prop
Click to expand...
Click to collapse
There are build.prop editors on the play store to make it easier

cwburns32 said:
Do you install this via recovery? Or do I have to drop zip into a specific folder?
---------- Post added at 05:31 PM ---------- Previous post was at 05:30 PM ----------
Curious what you are using to edit build prop. I have MagiskHideProps installed via Magisk but not sure how to edit build prop
Click to expand...
Click to collapse
MagiskHideProps allows you to enjoy the effect of editing build.prop without actually physically altering the file. You are basically injecting build.prop values into system memory at boot time (my understanding). This achieves the same effect as editing build.prop without making changes to the file itself in system. (systemless change) Once you have installed MagiskHideProps you can use a terminal emulator on your phone or ADB Shell session via your computer to execute the simple program "Props". The documentation of MagiskHideProps is very detailed and easy to follow. You need to add a new prop set to True for net.tethering.noprovisioning. Good luck.
S

roman.ramirez.12 said:
You can Flash with TWRP just make sure you know where you put it. I like to keep my stuff in downloads.
Click to expand...
Click to collapse
Phalanx7621 said:
There are build.prop editors on the play store to make it easier
Click to expand...
Click to collapse
sb1893 said:
MagiskHideProps allows you to enjoy the effect of editing build.prop without actually physically altering the file. You are basically injecting build.prop values into system memory at boot time (my understanding). This achieves the same effect as editing build.prop without making changes to the file itself in system. (systemless change) Once you have installed MagiskHideProps you can use a terminal emulator on your phone or ADB Shell session via your computer to execute the simple program "Props". The documentation of MagiskHideProps is very detailed and easy to follow. You need to add a new prop set to True for net.tethering.noprovisioning. Good luck.
S
Click to expand...
Click to collapse
Thank you all. I ended up using zip file but still have MagiskHideProps installed for future build.prop edits. Thanks again!

guys my hotspot is unlocked i just want to hide my hotspot useage from verizion. is there a guide to do this???

crackerjack1957 said:
BuildProp Editor
Add line:
net.tethering.noprovisioning=true
save
reboot
Click to expand...
Click to collapse
Excellent! I edited the build.prop using a text editor and added this setting but to no avail. I guess the trick is to use the BuildProp Editor app and follow your instructions. My Pixel 3 XL's native hotspot works like a champ now. Thanks again!!!!

crackerjack1957 said:
BuildProp Editor
Add line:
net.tethering.noprovisioning=true
save
reboot
Click to expand...
Click to collapse
:good: You rock! Quick and easy fix. Did it in less than a minute and that included downloading the app.

[ROOT] [MAGISK] Global ROM on CN Device - WORKING ROOT

THIS IS NOT FOR FAINT OF HEART. DON'T BLAME ME IF YOU BREAK SOMETHING.
Mount system as RW in TWRP. (this took mounting, unmounting, then remounting for me)
Use the following commands CAREFULLY from a computer.
cat /system/build.prop > /sdcard/build.prop
Open the build.prop from the sdcard and edit the following line numbers: 25, 26
You are changing:
ro.product.name=perseus
ro.product.device=perseus
To this:
ro.product.name=perseus_global
ro.product.device=perseus_global
save the file on the sdcard
Go back to ADB session and do this:
cat /sdcard/build.prop > /system/build.prop
IF THIS FAILS YOUR SYSTEM IS NOT RW, UNMOUNT AND REMOUNT IN THE MOUNTS MENU.
Go back to the mounts menu and unmount /system
Flash Magisk 17.3 (18.0 seems to be having intermittent issues with passing checks)
Reboot, and enjoy your CN device running Global with ROOT.

out-file : Could not find a part of the path 'C:\sdcard\build.prop'.
I got that error above. How do i know twrp mounted system correctly?
nvm... i went into advance and did via terminal

Great find, works!!
Thanks!!

You're welcome. I may try to make a flashable zip to do this automatically, but I haven't had a chance to look at it.

Work so well, Thanks @PWn3R!

xterminater07 said:
out-file : Could not find a part of the path 'C:\sdcard\build.prop'.
I got that error above. How do i know twrp mounted system correctly?
nvm... i went into advance and did via terminal
Click to expand...
Click to collapse
Here is the clue. " 'C:\sdcard\build.prop'."
What is a Windows drive letter doing on an Android? Adb session?

@PWn3R YOU ARE THE MAN

Has anyone tried a custom kernel on the latest global? I tried androplus v 0.6 and it didnt really work. It allows me to replace files in system but not rename because when I overwrite it still says there is an existing file with same name.
Any kernel that works please let me know. I am working with defcomg to get gcam modded more than the current ones.

I would like to try, i already had install last global, and this rtemove my twrp instead the official recovery.... Can you give me all the steps to do from this position? Thank you

I have a problem with camera, force close no matter what I've done. may be build.prop change?

kbello said:
I have a problem with camera, force close no matter what I've done. may be build.prop change?
Click to expand...
Click to collapse
i got this as well... oh well going back to xiaomi eu rom

Hi the change to the build.prop did not break the camera. Mine is working fine. Maybe clear app data for that app?

I do many times, didn't work,
---------- Post added at 11:45 PM ---------- Previous post was at 11:23 PM ----------
This is the error:
java.lang.RuntimeException: unSupported Saturation
at com.android.camera2.compat.MiCameraCompatBaseImpl.applySaturation(MiCameraCompatBaseImpl.java:248)
at com.android.camera2.compat.MiCameraCompat.applySaturation(MiCameraCompat.java:49)
at com.android.camera2.MiCamera2.applySaturation(MiCamera2.java:2486)
at com.android.camera2.MiCamera2.applyCommonSettings(MiCamera2.java:2858)
at com.android.camera2.MiCamera2.applySettingsForCapture(MiCamera2.java:2971)
at com.android.camera2.MiCamera2ShotNormal.generateRequestBuilder(MiCamera2ShotNormal.java:141)
at com.android.camera2.MiCamera2ShotNormal.startShot(MiCamera2ShotNormal.java:59)
at com.android.camera2.MiCamera2.captureStillPicture(MiCamera2.java:2042)
at com.android.camera2.MiCamera2.triggerCapture(MiCamera2.java:1892)
at com.android.camera2.MiCamera2.takePicture(MiCamera2.java:991)
at com.android.camera.module.Camera2Module.startNormalCapture(Camera2Module.java:1130)
at com.android.camera.module.Camera2Module.onWaitingFocusFinished(Camera2Module.java:406)
at com.android.camera.module.loader.camera2.FocusManager2.capture(FocusManager2.java:767)
at com.android.camera.module.loader.camera2.FocusManager2.doSnap(FocusManager2.java:326)
at com.android.camera.module.Camera2Module.onShutterButtonClick(Camera2Module.java:1057)
at com.android.camera.fragment.bottom.FragmentBottomAction.onSnapClick(FragmentBottomAction.java:1653)
at com.android.camera.ui.CameraSnapView$1.handleMessage(CameraSnapView.java:67)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loop(Looper.java:201)
at android.app.ActivityThread.main(ActivityThread.java:6806)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:547)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:873)

@PWn3R, the root is working but there are some functionalities that disappeared in the setting menu such as slider settings, screen color.
For those who wants to revert to CN rom, revert the changes you have done and DO NOT forget to remove Magisk by flashing the uninstaller zip otherwise the device will bootloop.

I restore the original build.prop and boot.img, the camera came back to work. Any workaround?

kbello said:
I have a problem with camera, force close no matter what I've done. may be build.prop change?
Click to expand...
Click to collapse
I didn't notice if the slider settings were there before changing the build.prop. The problem here is that when you flash magisk it's enabling secure boot, which is triggering a check that normally runs when the device is locked. I think we can probably fix that by modifying the file that causes it and then this will work without build.prop changes. I have not had a chance to look into that, but will try to do so.

any solution to fix the fingerprint on GSI?

Does anyone know if they already have a solution to fix the fingerprint on any GSI on the moto g7 play?

I don't think there will be a fix for it. GSIs are basically developed for testing purposes and are not functionally ROMs.
---------- Post added at 07:01 AM ---------- Previous post was at 06:58 AM ----------
https://source.android.com/setup/build/gsi

Guhl0rd64 said:
Does anyone know if they already have a solution to fix the fingerprint on any GSI on the moto g7 play?
Click to expand...
Click to collapse
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.

Spaceminer said:
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Click to expand...
Click to collapse
man, you are the g7 play hero ngl, can you post an explanation of what needed to be done when youve done it, you know like the technical side, so people like me can learn?

00p513 said:
man, you are the g7 play hero ngl, can you post an explanation of what needed to be done when youve done it, you know like the technical side, so people like me can learn?
Click to expand...
Click to collapse
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.

Spaceminer said:
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Click to expand...
Click to collapse
Wow, thank you very much my friend, I will test now

Spaceminer said:
I'm working on this right now. It requires a jar from /system/framework, and some libs from the stock OS. And maybe an overlay, but that part I'm unsure about. If I get anything working I'll post a flashable zip.
Click to expand...
Click to collapse
Thank you.
---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------
Guhl0rd64 said:
Wow, thank you very much my friend, I will test now
Click to expand...
Click to collapse
So...?

Marcondes BR said:
Thank you.
---------- Post added at 06:41 PM ---------- Previous post was at 06:40 PM ----------
So...?
Click to expand...
Click to collapse
I installed by TWRP, I have Lineage OS 17.1, still with the same problem

Descendent Modified GSI, doesnt work. It sees the reader, but doesnt recognise me touching it

Spaceminer said:
I use a few methods in general to figure stuff out.
1. Google, Arch linux Wiki, stack exchange.
2. Sleuthing. Go digging though system files or app manifests.
3. Poke it with a stick. Running strings or grep on a file for keywords. Poke the box with the right input, and it'll often give you prizes in return. This is especially true for things you can't just decompile like a bootloader image. You can even do things like tease partition mounts from a vendor image this way.
4. Load files into a hex editor. I personally use HxD. This works similar to the poke the box method. If strings and grep are like a radio, then using a hex editor is like watching TV.
5. Don't reinvent the wheel if you don't have to. Look for things that you know accomplish the same, or a similar task, then adapt them to your situation. This isn't always easy but 90% of the time it'll get you there or damn close.
This project is a combo of 2 and 5.
I first went digging through system and vendor files. I know from prior experience that apps and hardware features often require library files (/system/lib/*.so), bin files (/system/bin & /vendor/bin), jar files (/system/framework/*.jar), and permissions (/system/etc/permissons & (/vendor/etc/permissions). Occasionally hardware features also have an init script to start them. (/system/etc/init & /vendor/etc/init)
So I searched with a root explorer for any files in those locations that have "finger" in the name. That gave me gold. I made a note and created a file structure to match them, then copied the files over and created a zip.
This is where #5 comes in. In order to flash it, we need a script to tell twrp how to mount the partitions we're going to modify, where the files go, and what file permissions to set. (rw-r--r--, 0755 etc.) I knew how to do this from modifying phh's su to work on Lineage OS 17. And I learned how to do that by looking at the flashable zips for, viper for android, and the universal disabler. Since I had adapted those for Phh su, when I needed to do it again, I pulled the scripts from Phh su and edited them to use the new files and permissions.
That's the jist of it. If you want to see how the scripts are written, extract the zip and look at META-INF/com/google/android/updater-script with a text editor. I recommend either Quick Edit pro for android, or notepad++ if using Windows.
Finger Print Test #1
If anyone running a GSI wants to test this, just flash it in twrp and let me know if the finger print sensor works. It should NOT break anything. If you get any flashing errors please tell me. It means there's a typo somewhere in the scripts and I need to fix it.
Click to expand...
Click to collapse
I have tested on several GSI, and I have had no success

Guhl0rd64 said:
I have tested on several GSI, and I have had no success
Click to expand...
Click to collapse
You might need to add ro.fpsensor.position=1 & persist.qfp=false to the build prop.

Spaceminer said:
You might need to add ro.fpsensor.position=1 & persist.qfp=false to the build prop.
Click to expand...
Click to collapse
it still didn't work

Guhl0rd64 said:
it still didn't work
Click to expand...
Click to collapse
I'm unfortunately out ideas at this point.

Spaceminer said:
I'm unfortunately out ideas at this point.
Click to expand...
Click to collapse
I guess this means no fingerprint on Ubuntu Touch when i get it to work