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.
Related
I am just about to release my new barebones build with a lot of new features but one thing is killing me. I cannot get superuser to work anymore with the latest build and the latest kernel. Rogue tools won't overclock without SU working and that just totall kills the speed of my build =(. The build is based off scoot's release 5 and I am using the latest kernel with and without the module update SU is unaffected. Everything else works though.
What have you changed from the build i sent you that might effect it? Does it work for you with the original build? Things to check are the sysinit.rc, make sure it calls userinit.sh on startup, and also check your userinit.sh in the /bin directory and make sure the su fix is still present in the file Otherwise, try opening the super user app and downloading the latest su binary file, if it fails to install then you most likely have partition permission issues.
I did edit userinit to enable the odex script. I am gonna check that now.
Ok I am pretty sure that was it. how do I add this line to userinit to have it be proper then? /system/bin/odex.sh
aceoyame said:
Ok I am pretty sure that was it. how do I add this line to userinit to have it be proper then? /system/bin/odex.sh
Click to expand...
Click to collapse
You'd need to put it in sysinit.rc like this :
service odex /system/bin/odex.sh
So put that line right at the end then? Or is there a special format it has to go in. Sorry, I have just never had to edit this particular file before lol.
aceoyame said:
So put that line right at the end then? Or is there a special format it has to go in. Sorry, I have just never had to edit this particular file before lol.
Click to expand...
Click to collapse
At the end is fine, you will see some similar lines in there, you may want to add some options such as :
console
user root
oneshot
I don't know what the structure of the odex script is so i don't know which options you will need to get it to run properly but these are the most likely, just experiment and see
I've always put it at the end, after the su fix just as "/system/bin/odex.sh" and nothing else. What does service do? will it run it continuously or just with different permissions?
I would say its more likely that something's gone wrong while you edited userinit.sh, and now it can't be executed.
did you edit it in windows? you may have /n/r line endings now instead of /n
if you did it in linux it may be a permissions problem
fixed! I used the userinit from my old barebones. Something changed in the update. The two looked totally different.
I was trying to change model no. In build prop but after reboot changes not save.
Check if you have root. Bcoz sometimes magisk fails to function properly.
Laz said:
Check if you have root. Bcoz sometimes magisk fails to function properly.
Click to expand...
Click to collapse
Thanks for the suggestion and you are right there is a magisk module(external sd card enabler) which keeps on reverting the build.prop edits........ So than i figure it out that i have to edit build.prop which is created by magisk module in magisk folder in system or delete the module than edit build.prop
Again Thanks for your help!!!?
You're welcome!
Doesn't magisk prevents system modification ? It's how it works, correct me if I'm wrong.
You can't tweak via root explorer, you can't flash the usual twrp flashable stuff, you gotta build your magisk module. Which is in all honestly uber simple and very convenient.
you are far from right duck...
Magisk is a root solution, so you get to have the rights. You can edit via file explorer , granted with root permission. Lolz. Building Modules is really simplified thou, right on that mate.
"YOU CAN TWEAK, via Root Explorer, lol. <-from a guy using Magisk. You just gotta need that root.
Yup.
Pretty much as OP I did a bunch of root editing / flashed some stuff via twrp, and nothing remained at reboot. Never saw that before, and since it works with magisk I may had jumped to conclusions too fast.
figured it out!!!!!
i know im late to the party but i recently came across this same problem. all yous gotsa doos is modify the build.prop located in /sbin/.magisk/mirror/system
after saving changes just check thru all the other location you know for build.prop just to double check that the changes have been made. if the build.prop is not the same in all locations, then the changes will not stick. if the changes affect all system build.props your good to go reboot device and do whacha do (note: just the system build.prop, not the vendor).
sm00th4f3 said:
you are far from right duck...
Magisk is a root solution, so you get to have the rights. You can edit via file explorer , granted with root permission. Lolz. Building Modules is really simplified thou, right on that mate.
"YOU CAN TWEAK, via Root Explorer, lol. <-from a guy using Magisk. You just gotta need that root.
Click to expand...
Click to collapse
---------- Post added at 03:37 PM ---------- Previous post was at 03:32 PM ----------
i know im late to the party but i recently came across this same problem. all yous gotsa doos is modify the build.prop located in /sbin/.magisk/mirror/system
after saving changes just check thru all the other location you know for build.prop just to double check that the changes have been made. if the build.prop is not the same in all locations, then the changes will not stick. if the changes affect all system build.props your good to go reboot device and do whacha do (note: just the system build.prop, not the vendor).
v1nd1cta85 said:
figured it out!!!!!
i know im late to the party but i recently came across this same problem. all yous gotsa doos is modify the build.prop located in /sbin/.magisk/mirror/system
after saving changes just check thru all the other location you know for build.prop just to double check that the changes have been made. if the build.prop is not the same in all locations, then the changes will not stick. if the changes affect all system build.props your good to go reboot device and do whacha do (note: just the system build.prop, not the vendor).
---------- Post added at 03:37 PM ---------- Previous post was at 03:32 PM ----------
i know im late to the party but i recently came across this same problem. all yous gotsa doos is modify the build.prop located in /sbin/.magisk/mirror/system
after saving changes just check thru all the other location you know for build.prop just to double check that the changes have been made. if the build.prop is not the same in all locations, then the changes will not stick. if the changes affect all system build.props your good to go reboot device and do whacha do (note: just the system build.prop, not the vendor).
Click to expand...
Click to collapse
Thanks, this helped me out.
So, grabbed the latest OTA, and went through the usual re-root cycle, but was unable to edit the build.prop. While /root is mountable, /root/system is not, which means no tethering for me.
Anyone else running into the same issue?
I have the same issue, I've been fighting with it all day.
I patched the boot.img with Magisk Manager and flashed it, Magisk Manager show's I'm installed and Root Checker says I'm rooted, I was even able to install Adaway. But i cannot use any root app that needs to mount /System
I tried using Root Uninstaller and it says it has root access but cannot mount /system as R/W
It seems Magisk is only able to partially root on Android 10
I tried this with the Canary version and the standard version of Magisk and the same issue both times
Same issue on regular pixel:
sailfish:/ # mount -o remount,rw /system
'/dev/block/sda33' is read-only
lame
bbarnes1 said:
Same issue on regular pixel:
sailfish:/ # mount -o remount,rw /system
'/dev/block/sda33' is read-only
lame
Click to expand...
Click to collapse
if all you want to do is edit a prop in build.prop, just use the Magisk module MagiskHidePropsConfig....works like a charm (at least it did on Android 9 - assume it would work on 10....it sounded like it worked on the betas)....
https://forum.xda-developers.com/apps/magisk/module-magiskhide-props-config-t3789228
This has been a problem since the Q beta came out, with each update I tried to figure something out. With no luck! I tried the Magisk Mod but it didn't seem to work.
suggestions would be most appreciated!!
Thinkin about a clean install....maybe.....
Edit: It was also a problem with the P beta until it was out of beta (That was my hope for this)
sb1893 said:
if all you want to do is edit a prop in build.prop, just use the Magisk module MagiskHidePropsConfig....
Click to expand...
Click to collapse
I'm trying to add a prop, which seems like a different need, but will look into it.
tufyuma said:
Thinkin about a clean install....maybe.....
Click to expand...
Click to collapse
Was thinking about this, but realized a clean install for every update isn't worth a hotspot to me.
sb1893 said:
if all you want to do is edit a prop in build.prop, just use the Magisk module MagiskHidePropsConfig....works like a charm (at least it did on Android 9 - assume it would work on 10....it sounded like it worked on the betas)....
https://forum.xda-developers.com/apps/magisk/module-magiskhide-props-config-t3789228
Click to expand...
Click to collapse
I gave this a whirl, its doesn't appear to actually be change build.prop
bbarnes1 said:
I gave this a whirl, its doesn't appear to actually be change build.prop
Click to expand...
Click to collapse
It doesn't physically change anything in system. The intent is to offer the same functionality as physically editing the build.prop without modifying that file. It creates the prop and value setting and loads into into memory at boot time.....(similar to the way the build.prop file is read at boot time for those settings.) At least that is my understanding. It works for me on Android 9 for setting the prop for tethering...for example. You can confirm it works by using the getprop command to verify the prop you set is set as you intended.
Welp, still can't mount /system or edit the file directly, but PropsConfig seems to be good enough for my needs.
somethingsomethingroot said:
Welp, still can't mount /system or edit the file directly, but PropsConfig seems to be good enough for my needs.
Click to expand...
Click to collapse
Can you tell me what the process is that got you tethering capability?
Having the same issue on my P2XL which was upgraded via flash of full image minus -w. Using latest canary build of Magisk. I couldn't mount system or anything under it.
I then downgraded Magisk to v19.3 and had no issues mounting system using FX File Explorer, etc. and still had root. But I couldn't mount anything under system so I still can't edit build.prop.
For those who are just trying to find a way to get hotspot working (via build.prop edit), try this...worked for me on a dirty upgrade (A9 -> A10 via full image flash without -w) + latest Magisk Canary:
https://forum.xda-developers.com/showpost.php?p=75238542&postcount=59
IlyaKol said:
For those who are just trying to find a way to get hotspot working (via build.prop edit), try this...worked for me on a dirty upgrade (A9 -> A10 via full image flash without -w) + latest Magisk Canary:
https://forum.xda-developers.com/showpost.php?p=75238542&postcount=59
Click to expand...
Click to collapse
Thanks for posting this, it worked great on my Pixel XL on Sprint. I had about given up on being able to edit the build.prop.
You no longer need the canary version of Magisk. Version 20.00 will rebuild your boot.img and if you load busybox and use a terminal type "props" and follow the onscreen menu. you can get your tethering back. My output:
Your prop
DebianDog said:
You no longer need the canary version of Magisk. Version 20.00 will rebuild your boot.img and if you load busybox and use a terminal type "props" and follow the onscreen menu. you can get your tethering back. My output:
Click to expand...
Click to collapse
Are you sure that your screenshot of the props output is correct? Because it looks like you have the value set to "net.tethering.noprovisioning" and the prop name has =true in it. I'm just trying to figure this out because I've tried this and everything else trying to get my hotspot to work. My hotspot will turn on and devices can connect to it, but they don't have internet access. Any ideas at all?
Edit: Nevermind, I had the custom prop set to post fs data when it was supposed to be set at boot stage (default). My hotspot is working now. Thank you all.
DebianDog said:
You no longer need the canary version of Magisk. Version 20.00 will rebuild your boot.img and if you load busybox and use a terminal type "props" and follow the onscreen menu. you can get your tethering back. My output:
Click to expand...
Click to collapse
Confirming that this works on rooted pixel 4. Thank you for this btw
IlyaKol said:
For those who are just trying to find a way to get hotspot working (via build.prop edit), try this...worked for me on a dirty upgrade (A9 -> A10 via full image flash without -w) + latest Magisk Canary:
https://forum.xda-developers.com/showpost.php?p=75238542&postcount=59
Click to expand...
Click to collapse
This seems to have worked for me, though I don't really understand why or what did it.
For any dummies like me that happen to fall on this post after their build.prop seems to fail to save. The link above to: https://forum.xda-developers.com/showpost.php?p=75238542&postcount=59 worked for me.
download
https://forum.xda-developers.com/attachment.php?attachmentid=4392434&d=1516234353
to the device > run TWRP
I have to run twrp from cmd line since my Pixel XL refuses to install it using command::
.... fastboot boot twrp.img
and installing the zip file above > rebooting
back to cmd line
> adb shell
> settings put global tether_dun_required 0
> reboot
swipe notifications bar and turn on hotspot and wamo she's kicking.
Thanks guys
I haven't been beating my head too hard this time around. Many thanks to the brains that are keeping the rest of us dummies excited to keep tinkering about with our androids!
wolvmarine said:
For any dummies like me that happen to fall on this post after their build.prop seems to fail to save. The link above to: https://forum.xda-developers.com/showpost.php?p=75238542&postcount=59 worked for me.
download
https://forum.xda-developers.com/attachment.php?attachmentid=4392434&d=1516234353
to the device > run TWRP
I have to run twrp from cmd line since my Pixel XL refuses to install it using command::
.... fastboot boot twrp.img
and installing the zip file above > rebooting
back to cmd line
> adb shell
> settings put global tether_dun_required 0
> reboot
swipe notifications bar and turn on hotspot and wamo she's kicking.
Thanks guys
I haven't been beating my head too hard this time around. Many thanks to the brains that are keeping the rest of us dummies excited to keep tinkering about with our androids!
Click to expand...
Click to collapse
Why need to turn on Hotspot for build.Prop editing? What's wamo?
truelies1 said:
Why need to turn on Hotspot for build.Prop editing? What's wamo?
Click to expand...
Click to collapse
Does anyone know a way to enable gestures on 3rd party launchers on stock rom
As this post https://forum.xda-developers.com/showpost.php?p=78125891&postcount=43 describes, I modified mixer_paths_tavil.xml changing the AVC Volume value in attribute headphones-hifi-dac, from 15 to 6, in order to achieve the AUX volume values in normal mode
The file mixer_paths_tavil.xml is saved correctly. Then I mount /vendor read-only again and remount, and I check that the file remains changed with the modification done. The modification date timestamp reflects the change
But no effect in the sound
So I guess I should reboot the phone for the change takes into effect. But then, after the reboot, the mixer_paths_tavil.xml is again the original one without the changes (and the mofication date is Dec 31 2008, the original ...)
So how should I edit this file to keep the changes with the reboot?
I'm on Pie
Thanks in advance
I know with my v30 i changed values in mixer_paths tavil.xml set permissions reboot and I was all good but my lg g7 im still trying to unlock my bootloader with the instructions but after updating magisk manager I have no root to finish the rest of the commands. I wish I could edit this same file and see whats going on and why it wont stick after reboot.
I am also facing the sam issue my bootloader is unlocked and i am rooted on android 10. Changes dont stick after reboot.
First thing is make or edit magisk module to have this file changed. Second thing is make a file called service.sh (with permissions rw- r-- r-- or 0644)
In this file you need to write
Code:
killall audioserver
Explanation: Vendor partition in pie and android 10 is impossible to edit in case of LG G7. You need to have this file modified in magisk module with proper permissions and catalogs (vendor/etc). Even if you have audio related files modified in magisk module, there's second problem. Everything will be booted with default values. That's why you need service.sh with killall audioserver. This will reload all your audio related files at early stage of system boot, and new values will be applied.
ShuAK said:
I am also facing the sam issue my bootloader is unlocked and i am rooted on android 10. Changes dont stick after reboot.
Click to expand...
Click to collapse
Can you please tell me that how you rooted your device?
hasnawtahmed said:
Can you please tell me that how you rooted your device?
Click to expand...
Click to collapse
Are u bootloader unlocked? If not then follow this guide to unlock it.
https://forum.xda-developers.com/lg-g7-thinq/how-to/howto-updated-guide-to-unlock-t4168771
After that rooting is very simple process use QFIL to backup your boot_a img copy it to phone install magisk manager and and patch that file with magisk. Then write this img file to ur boot_a partition using QFIL and thats it.
ShuAK said:
Are u bootloader unlocked? If not then follow this guide to unlock it.
https://forum.xda-developers.com/lg-g7-thinq/how-to/howto-updated-guide-to-unlock-t4168771
After that rooting is very simple process use QFIL to backup your boot_a img copy it to phone install magisk manager and and patch that file with magisk. Then write this img file to ur boot_a partition using QFIL and thats it.
Click to expand...
Click to collapse
I have unlocked bootloader. Qfil gives an error something like firehose failed or download fail somethinh like that.
ShadoV90 said:
First thing is make or edit magisk module to have this file changed. Second thing is make a file called service.sh (with permissions rw- r-- r-- or 0644)
In this file you need to write
Code:
killall audioserver
Explanation: Vendor partition in pie and android 10 is impossible to edit in case of LG G7. You need to have this file modified in magisk module with proper permissions and catalogs (vendor/etc). Even if you have audio related files modified in magisk module, there's second problem. Everything will be booted with default values. That's why you need service.sh with killall audioserver. This will reload all your audio related files at early stage of system boot, and new values will be applied.
Click to expand...
Click to collapse
Where i create service.sh file?
@hasnawtahmed try another pc if u can coz i faced the same issue on my laptop i have windows 7 and i cannot access partition data but i have a windows 10 PC and in that i can easily access and modify.
ShuAK said:
First thing is make or edit magisk module to have this file changed. Second thing is make a file called service.sh (with permissions rw- r-- r-- or 0644)
In this file you need to write
Where i create service.sh file?
@hasnawtahmed try another pc if u can coz i faced the same issue on my laptop i have windows 7 and i cannot access partition data but i have a windows 10 PC and in that i can easily access and modify.
Click to expand...
Click to collapse
I'm also using a windows 10 pc
Then reinstall drivers
ShuAK said:
Where i create service.sh file?
@hasnawtahmed try another pc if u can coz i faced the same issue on my laptop i have windows 7 and i cannot access partition data but i have a windows 10 PC and in that i can easily access and modify.
Click to expand...
Click to collapse
You can create that file in main module catalog.
I created service.sh and copy it inside a dual speaker magisk module zip file.
Yep thnx man its working now sounds are too much lowder
ShuAK said:
I created service.sh and copy it inside a dual speaker magisk module zip file.
Yep thnx man its working now sounds are too much lowder
Click to expand...
Click to collapse
Would you mind to share the modified module? Thank you in advance
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