Develop Bugs

Building Stock Firmwares (Verizon Specifically)

Hey guys, I've been reading for a while now, finally decided to sign up.
I'm making some modifications to the Galaxy Tab, just playing around and seeing what all is possible. Before I go start deleting potentially important system files, I wanted to get myself a little 'brick insurance'. I'm looking to get a copy of the stock firmware for the US Verizon Wireless version of the Tab (SCH-I800). It is currently running DJ11.
I don't think it is available from either Samsung or Verizon currently, although Samsung HAS provided all of the source code. If I wanted to make a backup of the firmware, something that I could load from the SDCard (ideally, just give it one of those update.zip files) how would I go about doing that?
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
I want to be able to quickly revert back to like-new set up, so I would prefer to not have to use one of the modified European/International versions if possible. Is there any other trick to getting an unmodified firmware to revert to? Any suggestions?
Thank You

I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero

DavidThompson256 said:
This is my current plan, tell me if I'm not on track here. I have downloaded the Android Froyo source code available on the Android site. I downloaded the SCH-I800_OpenSource files from Samsung's open source center. If I combine these files as described in the readme from Samsung, and then build the whole project, I should get some sort of "stock" software, in basically the exact same state that it was when I got it from Verizon. Does this sound right?
Click to expand...
Click to collapse
Not even close i'm afraid!
Samsung are only required to release the Linux kernel source. The actual OS is not licensed under a "copy left" license, so Samsung are under no obligation to release their customized Android code.
So, you could create your own AOSP build, but this would be absolute stock Froyo - no Samsung launcher, or any of their custom apps.
Regards,
Dave

Yaotl said:
I don't think it'll matter until someone creates a new recovery image. If you could get a clockwork recovery image, you'd be a hero
Click to expand...
Click to collapse
You can use odin or redbend_ua to flash firmwares, you don't necessarily need clockwork - although it would be nice!

Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.

ninja4hire said:
Hey infamousjax,
Do you happen to have an update.zip for the verizon tab you can upload? I managed to ninjamorph my framework so nothing opens anymore. I must have used a file that was the wrong png format or something. Anyway I do have the backup framework-res.apk, but I am unsure on the "update-script" as I can't get programs on my tab at the moment.
Click to expand...
Click to collapse
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.

infamousjax said:
I have the Sprint version... and the stock recovery can't flash update.zips unless they are signed.
Click to expand...
Click to collapse
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.

ninja4hire said:
Yeah I just tried to make an update.zip and sign it with a test signer. Now when go into recovery and run the update.zip it freezes on an Android icon with an exclamation point.
Click to expand...
Click to collapse
Can you boot up regularly?

yeah, it's just that I can't open programs or the settings menu.
edit: I have been trying to do an update.zip, but I keep getting "E: signature verification failed". I have tried to different signers already...
This one
http://www.robmcghee.com/android/creating-an-android-update-zip-package/
and this one
http://www.londatiga.net/it/how-to-create-android-update-zip-package/

Your not going to able to sign it without Samsung's signatures... and good luck finding those

yeah I pretty much gave up. I called last night and got the verizon insurance. So now I'm just gonna wait a few days then tell them I dropped it and pay $80 for a new one.

just tell them it started bootlooping for no reason... they should replace it for free if its within 30 days

So it sounds as though I'm not really on the right track here, perhaps I don't need to recompile this thing myself. From some of the replies, I've gathered that there IS at least some way to create a backup of the firmware, in case I screw it up.
Can anyone point me to specific steps on how to do a backup for the Tab? I've seen several guides for other phones before, but I believe that each device is slightly different, and may take different steps. Any suggestions?
Thanks again.

For your stock recovery
Code:
cat /dev/block/bml8 > /sdcard/recovery.bin
For your kernel
Code:
cat /dev/block/bml7 > /sdcard/zImage

Thanks a lot, that info was really helpful!
So, unrelated now, but just kind of curious... is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
I have about 60 different files in that directory, and was just curious to know what each of them was for.
Thanks again for all the info.

DavidThompson256 said:
is there a reference sheet somewhere or something that explains what each of the files in /dev/block is for? I know they are different sections of the filesystem.
Click to expand...
Click to collapse
What they represent is different devices, not different sections of filesystems. At best (without RAID or LVM) each device holds one filesystem. In unix, filesystems can be mounted at various points into the root filesystem to appear as a single namespace, but they will still be separate filesystems.
Under the block dir you will see anything that is a block device, anything that can be written to randomly, as opposed to a serial type of device. So, all the random access hardware on your device (SDCARD, NAND...) will be represented there except for your RAM. Each physical device will likely have partitions on them so, if a device is named xxx, xxx01 will likely mean partition one on device xxx. Sometimes the same device will appear with several names, one may be buffered access, the other may be raw.
Your internal NAND is likely on the same device, just different partitions of that device. Some of these partitions may not hold filesystems, they may hold other blobs such as a boot loader, or the kernel. To see which ones hold filesystems, you can type df in a terminal and you will likely see which devices are mounted where in the filesystem namespace.
As for the rest of the devices and partitions, they are very hardware device specific. And I don't own a Galaxy tab, so I can't help with that, sorry. But, I hope I didn't give you info you already knew and I hope it might have been at least somewhat helpful...

[ROM] CM9 For SGH-I957 Galaxy Tab LTE (Test Build -- Android 4.0.4 ICS!)

NOTE: Due to the fact that the Jellybean build went smoother and we all want the latest candy anyway, I've scrapped this effort. Get your candy at: http://forum.xda-developers.com/showthread.php?t=1867579
DISCLAIMER: This is a test build. It works for me, and I spent a good bit of time cleaning up the rough edges and fixing a few silly things, but for all I know it will make zombie worms run out of your tab resulting in your untimely death without warning. If you're not comfortable hacking a Galaxy-series android, probably best to wait for the official update from Samsung and be a good compliant end user and update with Kies... If the death star ever lets the ICS update out, that is.
As Cyanogen likes to say on his work in progress repos: MAY EAT YOUR CAT
ALSO: This is wholly unsupported and I have no affiliation with the Cyanogenmod team. If you bug them for help with this, they will send a laser-equipped triangle-shaped monolith of a hovercraft to your location and decimate anything in your general vicinity with insane force and completely reckless abandon. Well, maybe not, but you get the idea. Don't piss off superman.
First, the bad.. I'm going to start a list of what seems broken:
- Camera. Tablet reboots on snapping photo, preview is 90 degrees off.. weird.
- Google Talk: Looks related to the camera problem. All seems to center around some camera effects issue. Talk.apk from the original honeycomb image does work, so if you need google talk, just swap it out.
Taking what I learned from building CM10 for this device, I grabbed the CM9 tree, which is supposedly final now, and built that too. This time, I'm dropping a flashable .zip, since CM9 is "solid" and won't be updated any more. That doesn't mean this is perfect, as Cyanogenmod is only the android framwork -- The dirty low level bits still come from the OEM, and samsung hasn't released those yet, but.. It's good enough for me, so... Maybe it is for you too!
Since AT&T is still jerking around with the official ICS update, worried about their pathetic "value added" software instead of dropping a clean build, there's no official, fully regression tested radio/RIL combo... So I've yanked the RIL from the Note, a very similar device. It seems to work, but may or may not get LTE at first -- Might stick in HSPA mode a bit, might get LTE, it's a little flaky. May work better in your area, may also depend on network conditions. I'm not completely up to speed on cellular tech so the cryptic debug output doesn't say much to me. However, unlike my work with Jellybean, at least the stock radio works on ICS... For me. If you flash this, please share your 3G/4G experience, and be sure to indicate which carrier and area you are in, if you don't mind.
In Settings, Wireless/Network, More..., Mobile Networks... There is a network mode option. Be sure that is set to LTE/GSM, not GSM. In ICS, this setting actually seems to work - In Jellybean, it does nothing.
WiFi should work without any effort, bluetooth too, and it has the phone app, so you can voice call. Video playback works, audio works, GPS works, and I didn't run into troubles with about 10-15 of the more popular apps from the market.
Tether works, and I changed the tether service to hand out the google DNS server (8.8.8.8/8.8.4.4) to clients, because AT&T's DNS tends to be annoyingly slow.
I also noticed stagefright (a video rendering library, among other things) refused to play anything besides the base-quality x264 videos, so I commented out the retarded bailout (return with unspecified error) in stagefright.so, because all the better-quality youtube videos just refused to play with no reason, just a generic error (what a POS) - So have fun watching HD videos on youtube, although some of the top-quality ones (1080) are a bit on the tough side for the GPU to render. Ah well, beats a non-sensical error.
Samsung did already release the 3.0.8 ICS kernel, for the SHV-140, which is the same hardware with a different radio.. That kernel, in it's .config, has an option for the SGH-i957, so I built that and stuffed resulting kernel binary into boot.img, and packed that into the zip. boot.img also enables early ADB, so you can adb shell into it even if the framework completely shats itself, which it sure did before I got the proper production-level Adreno 220 drivers straight from qualcomm into the build. So the main advantage of this build over jellybean right now is an official Samsung kernel built from their unmodified source code and official release Qualcomm GPU driver binaries.
I also changed apns-conf.xml to use the proper "Broadband" APN for AT&T LTE data-only, as is usually sold with these tablets.
To get this going, start with TWRP recovery -- if you don't have it already, visit that thread in this forum and get yourself hooked up, drop the zip in /sdcard, boot into recovery and..
1) Make a complete TWRP backup before you do anything further! (of course)
2) Wipe -> Factory Reset
3) Wipe -> System
4) Install the .zip I'm about to link you to
5) Reboot, receive bacon.
http://d-h.st/W3X
I've not tested everything and anything, and some things may not be fixable until we get the binary bits from Samsung when they drop ICS officially for this device. However, please report any problems you have here. If I can find time to reproduce and fix, you might get lucky
Enjoy! Honeycomb got boring long ago!

Appreciate all the work. I'll hopefully have time to flash tomorrow. Looking forward to dumping honeycomb.

really glad to see developement picking up for this tab!

I never use the camera or the 4G. I'm gonna flash this in the am. Thanks!
Sent from my SAMSUNG-SGH-I727 using xda app-developers app

Flashed and currently running this build. Looks stable enough so far, a couple of FC's but definitely manageable. I know this far fetched but once CM9 gets more stable, will we be able to start porting cm9 based roms? Or can we only port roms created for devices with similar CPU/structures/etc?
Sent from my SAMSUNG-SGH-I957 using xda premium

This is great, thanks for the build. Working great for a 1st edition. From a few minutes playing with it, I noticed that vibrate doesn't work nor does MTP (drivers refuse to install). Not deal breakers and I'm going to use this as my main OS - much better than honeycomb.

I can confirm that this is working very well on rogers, havent tested all functions but my tablet is now 10 times better, currently running Apex launcher. Dont forget to flash gapps for ics....

Something is up with package manager, can't install xda app
Sent from my SAMSUNG-SGH-I717 using xda app-developers app

Confirming difficulty with package manager, for both side loading and loading from the Google Play App. However, if I load from the Google Play website the installation works.
Other than that I'm very impressed by the quality and stability of what you've built here - many thanks.

My package installer seems to work just fine.
70ish apps from the play store installed fine, and a dozen or so non market apps.

Ive had some good success with this rom and my apps are installing as well. I do have a situation where I tried using an update to rom manager and it seemed to have broke my recovery and I cant get it back! I would like to try using twrp and how do I install it? I would flash through odin but I don't have the file :crying:

cottageboy said:
Ive had some good success with this rom and my apps are installing as well. I do have a situation where I tried using an update to rom manager and it seemed to have broke my recovery and I cant get it back! I would like to try using twrp and how do I install it? I would flash through odin but I don't have the file :crying:
Click to expand...
Click to collapse
Yikes! Never good when you lose recovery, that's a bad place to be. I'm assuming you have a working image on the device that isn't locked down? IE the CM9 image and/or a rooted honeycomb image is still functional?
Recovery image at:
https://dl.dropbox.com/u/69488769/twrp_recovery_SGHI957_2.2.1.5.img
From a shell, either via adb or via the terminal, just dd (block copy) the image to the recovery partition
dd if=twrp_recovery_SGHI957_2.2.1.5.img of=/dev/block/mmcblk0p22
That should solve that

dan-htc-touch said:
Something is up with package manager, can't install xda app
Click to expand...
Click to collapse
I'm getting an "Error Processing Purchase" on the xda FREE app?? logcat shows google's server returns HTTP/500
Code:
E/Volley ( 8075): [386] BasicNetwork.performRequest: Unexpected response code 500 for https://android.clients.google.com/fdfe/purchase
HTTP 500 = Server Error
Looks like a problem others have had and may relate to the app caching information it shouldnt?
http://code.google.com/p/android/issues/detail?id=30039
also,
http://forum.xda-developers.com/showthread.php?t=1695519
After clearing the play store's DB, the google services framework database, and removing/readding my google account, the error went away.
Then I got another vague error, which the following text from logcat explained:
I/PackageHelper( 3428): Size of container 5 MB
E/PackageHelper( 3428): Failed to create secure container smdl2tmp1
D/VoldCmdListener( 157): asec create smdl2tmp1 5 fat {} 10012
E/Vold ( 157): Error creating imagefile (Read-only file system)
E/Vold ( 157): ASEC image file creation failed (Read-only file system)
W/Vold ( 157): Returning OperationFailed - no handler for errno 30
E/DefContainer( 3428): Failed to create container smdl2tmp1
Click to expand...
Click to collapse
Anyone know anything about how to configure the ASEC location? I've never delved into ASEC and probably need to configure something in the image to account for handling ASEC transactions.
... Looks like I'll need to tweak a few things in the initial ramdisk to get the asec mountpoint correctly set. Good grief, the freaking thing wants to set up a loopback block device on a tmpfs partition to install an application. That's pretty sad... /hacking it

I'm confused. How do I log into my Google account? Where's "my files" folder?
Sent from my SAMSUNG-SGH-I727 using xda app-developers app

ZX6Chris said:
I'm confused. How do I log into my Google account? Where's "my files" folder?
Sent from my SAMSUNG-SGH-I727 using xda app-developers app
Click to expand...
Click to collapse
You need to flash gapps for ICS for your Google account and apps.
The "my files" app does not exist on AOSP. You will need to download another file explorer.
Excellent work so far!
Snappy and mostly stable it seems.
Clicking on storage under settings causes a FC, the camera is derpy as stated in the op, and an occasional YouTube derp as stated in the op.
No hapatic at all either.
3g/hspa+/4g lte all working perfectly here.
Thanks!!

neubauej said:
Clicking on storage under settings causes a FC
No hapatic at all either.
Click to expand...
Click to collapse
Interesting, I'll check into that, thanks for that!
It Appears haptic feedback works with the keyboard, and on the home screen softbuttons. immvibed is running and doesn't register any complaints -- atleast that's how it is on my tab. does it not work at all for you?
storage FC: It's looking for /storage/sdcard1, the secondary SD card, which doesn't exist, and it has no error handling for this condition, so it explodes with java exception and the Settings process thus dies.. I believe I just need to yank that definition (for non-existent sdcard1) out of the xml for this package and rebuild, will try that next build!
Figured out the package manager issues, needed to mount tmpfs on both /mnt/secure and /mnt/asec and open up the permissions. That's unfortunately an initial ramdisk (root filesystem) hack, which means a new boot image.
attached. if you're not sure what to do with this, probably best to wait until i roll a few more fixes into a fresh flashable zip.. Otherwise, block copy to mmcblk0p8, reboot.
Been fighting with the camera issue, not having much progress there.
Thanks for the feedback, folks!

when im in my file explorer, where do I find the recovery portion?
im assuming that I put the img file there and using terminal emulator run your commands (do i have to type su first)?
nrvate said:
Yikes! Never good when you lose recovery, that's a bad place to be. I'm assuming you have a working image on the device that isn't locked down? IE the CM9 image and/or a rooted honeycomb image is still functional?
Recovery image at:
https://dl.dropbox.com/u/69488769/twrp_recovery_SGHI957_2.2.1.5.img
From a shell, either via adb or via the terminal, just dd (block copy) the image to the recovery partition
dd if=twrp_recovery_SGHI957_2.2.1.5.img of=/dev/block/mmcblk0p22
That should solve that
Click to expand...
Click to collapse

cottageboy said:
when im in my file explorer, where do I find the recovery portion?
im assuming that I put the img file there and using terminal emulator run your commands (do i have to type su first)?
Click to expand...
Click to collapse
There is no recovery partition to find in root explorer.
Just put the image file in your root directory (/sdcard).
Type "su" enter then the command.
I don't remember if you need to do it as a superuser, but it will certainly work if you are.

cottageboy said:
when im in my file explorer, where do I find the recovery portion?
im assuming that I put the img file there and using terminal emulator run your commands (do i have to type su first)?
Click to expand...
Click to collapse
The recovery emmc partition is /dev/block/mmcblk0p22. The dd command block copies the recovery image (twrp_recovery_SGHI957_2.2.1.5.img) from the filesystem to the emmc partition. if= specifies the image to read from, of= specifies the device to write the image to.
The recovery image is a raw partition image.
You will need to be root to do this.
If you're not comfortable operating on the command line, dan offered a apk to do this: http://db.tt/DXtF5iB6 -- from his TWRP thread @ http://forum.xda-developers.com/showthread.php?t=1697610

Finally got time to flash cm9. Block copied the fixed boot image. Running great. Amazing for a first build. Like a new tablet. Thanks!

[ThinkTank] Obtaining Perma-Root Discussion

{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
In order to keep the Root Progress thread as clean as possible, I took Kenny's advice and created a new thread. So to bring others up to speed, the Galaxy Note 4 variants from AT&T and Verizon have a root, but it's only temporary and resets after a reboot. Also system write is inconsistent.
This thread is for people to share and discuss their ideas and theories of how to make our temp root into a permanent root. Don't be afraid to share or ask any questions you may have because this is the place for them here. Now let's get brainstorming!​

Continuous "Custom padlock" on bootup
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and changing some file permissions and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress, but now pressing the power button brings up the power menu like normal. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?

CJ74753 said:
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
Click to expand...
Click to collapse
Anything is worth mentioning. It's interesting. I've just got my Note 4 warranty replacement yesterday so I'm timid to tinkering with it just yet. On my previous Note 4 I wiped out the EFS while playing in one of those "secret menus' LoL.
My thoughts on how-to obtain permanent root: We'll obviously make use of the temp root from KingRoot, then my idea (if feasible/logical) is to find the flag/eFuse and modify the result or expected result to keep it from reverting back. Now if it's dependent on an eFuse it may not be feasible if it's blown from the factory to lock the bootloader, but if it's like Dan Rosenbergs @djrbliss findings then the eFuse may be blown to unlock the bootloader. It's been a while since I read his findings so I may not be 100% accurate but it makes more sense the first method from a security point-of-view.
Now this was all before dmverity was introduced into KitKat 4.4.4 I believe, so things probably have changed for the worse in our case. I wonder where the weakest link is? I say this because obviously Qualcomm is great at securing their high-level chain of commands lately, but with the Droid Turbo gaining root(same SoC) then I have to believe that a kernel exploit is possible permanently and our road block is Sammy's software. Now with that being said, how tough can their software really be if their flagship S6 (Exynos) was just rooted? BTW good job @idler1984 on that! So you see where I'm going with this right? There's got to be a hole somewhere in Sammy's software after the bootloader, I just don't have a full overview of the boot process as far as where the Qualcomm bootloader hands off to kernel, then to Samsung's KNOX or activation lock etc etc...
Speaking of KNOX (Just rambling here) but has anyone who has used KingRoot ensured that they have turned KNOX and Activation Lock off? That would be funny is that's all it took to retain root

CJ74753 said:
Well I'll join in...
Not sure if it's worth mentioning, but I've successfully got my phone to continuously have the "Custom" message on my bootup screen and I enabled Factory Mode which is enabled at each boot. I managed to edit the /efs/FactoryApp enabling "Factory Mode" and changing some file permissions and not have the system restore the changes to the /efs/FactoryApp folder. When I edited it earlier pressing the power button caused a complete shut down, so I was hoping this was progress, but now pressing the power button brings up the power menu like normal. Is this partition handled differently or is this any progress? Can someone with more knowledge of the system file system comment on this?
Click to expand...
Click to collapse
Don't read too much into the custom message you can trip that a variety of ways even before now.

dagolith said:
Don't read too much into the custom message you can trip that a variety of ways even before now.
Click to expand...
Click to collapse
Well my main point here is that I edited the Factory Mode flag to enabled and was able to force the system to keep it set by editing the file permissions. While this don't work with all the files/folders this might be something to look at. I only wish I understood the file system more so I knew if we could possibly keep the system from restoring apps and removing root.

Here is a message I sent Droid.Ninja az I did not want to clog up the other thread with stupid ideas. But, that has been taken care of by others and their talking about off topic stuff. Any way here is a partial quote of what I sent him a few days ago. I hope that there is something useful here.
Jaytronics said:
Kingroot obtains Root. Be it temporary but Root non the less. Now, from my understanding, the device are trying to install the su binary while booted? Now, I know that and this may not matter. But after Kingroot has done its thing, SuperSU can not be utilized. But, what I have found is, that if hitting the SuperSU icon during Kingroot process. It, the SuperSU app has the ability to be activated. Now, when trying to install it's SU binary. It fails. Is this due to the system not having full R-W-E?
Separate idea. So, Root is temp partly because the RAM gets wiped at boot? That is easy to understand. Would there be a temporary way to energize that location before reboot to keep the Root state? I say this because some apps like Xposed need a reboot to work properly. Now whIle being energized could it be possible to back read the binaries that are trying to write to it from the bootloader as it gives off its authentication key or keys? I know absolutely nothing in regards to this stuff. I am guessing and thinking with pseudo logic. So, please don't think me an idiot. One last thing. I want to learn this stuff. I learn best by doing and experimenting. Could you in form me of the tools that you and other devices are using to try and achieve this? I want to dive head first into this stuff. And no, I don't care if I damage my phone. I will just purchase another one when needed. If need be. I hope in some small way I may have helped out. Last thing, would you know where to get a schematic of the board layout and possibly the pinout of components? Ok, I'm done now. By the way, I am not on the AT&T Note 4. I am a Verizon customer. Wish I was not. But, it is almost unfathomable to give up much unlimited data lines. So, I'm stuck with Evilrizon until they rip this away from me.
Click to expand...
Click to collapse

Jaytronics said:
1. Kingroot obtains Root. Be it temporary but Root non the less. Now, from my understanding, the device are trying to install the su binary while booted? Now, I know that and this may not matter. But after Kingroot has done its thing, SuperSU can not be utilized. But, what I have found is, that if hitting the SuperSU icon during Kingroot process. It, the SuperSU app has the ability to be activated. Now, when trying to install it's SU binary. It fails. Is this due to the system not having full R-W-E?
2. Separate idea. So, Root is temp partly because the RAM gets wiped at boot? That is easy to understand. Would there be a temporary way to energize that location before reboot to keep the Root state? I say this because some apps like Xposed need a reboot to work properly. Now whIle being energized could it be possible to back read the binaries that are trying to write to it from the bootloader as it gives off its authentication key or keys? I know absolutely nothing in regards to this stuff. I am guessing and thinking with pseudo logic. So, please don't think me an idiot. One last thing
3. I want to learn this stuff. I learn best by doing and experimenting. Could you in form me of the tools that you and other devices are using to try and achieve this? I want to dive head first into this stuff. And no, I don't care if I damage my phone. I will just purchase another one when needed. If need be. I hope in some small way I may have helped out. Last thing, would you know where to get a schematic of the board layout and possibly the pinout of components? Ok, I'm done now. By the way, I am not on the AT&T Note 4. I am a Verizon customer. Wish I was not. But, it is almost unfathomable to give up much unlimited data lines. So, I'm stuck with Evilrizon until they rip this away from me..
Click to expand...
Click to collapse
1. I've not used King Root yet as I'm on Lollipop so I can't comment on that issue, maybe someone else can add their experience.
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
3. Learn ADB in and out. One of the best Tools you could use. Give up on the unlimited data, it's overrated :good:

ZPaul2Fresh8 said:
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
Click to expand...
Click to collapse
From what I understand we never get to touch the actual file system of the system. This explains the bootup process of Android http://www.androidenea.com/2009/06/android-boot-process-from-power-on.html So upon bootup it copies the system data into RAM. Some how there must be a way to edit this and force the memory to write to the actual partition like how an update would have to do. This is why I was curious about my editing the /efs and making the changes stick by changing the file permissions.

ZPaul2Fresh8 said:
1. I've not used King Root yet as I'm on Lollipop so I can't comment on that issue, maybe someone else can add their experience.
2. From what I've been reading the system reverts back to the original state, which leads me to wonder if there is a backup of the system/partition elsewhere that is uses to compare or uses if there's any modification done to it? Xposed needs a reboot because it initializes in boot up.
3. Learn ADB in and out. One of the best Tools you could use. Give up on the unlimited data, it's overrated :good:
Click to expand...
Click to collapse
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).

Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V

Jaytronics said:
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Click to expand...
Click to collapse
I can guarentee you 100% you won't get they keys there is a reason the bootloader has not been crackdx since the note 2 these are not something that can be so easily obtained
Sent From The EDGE

Question. I am still on lolipop so i haven't tried but seeing as android is basically linux. When we obtain root even though its temp can we or has anyone tried mounting all the partitions in /dev to other location to see whats what and whats editable? I would think as root you could just mount and edit the system partition. Assuming you can find which partition is actually the system part.
Sent from my SAMSUNG-SM-N910A using XDA Free mobile app

cstayton said:
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Click to expand...
Click to collapse
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?

delete this if it does help with anything but i was listening to an podcast and they were talking about root and they used an camera app to help install su apk like i said just remember hearing something about it
keep up the good work guys!

CJ74753 said:
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
Click to expand...
Click to collapse
my guess (just speculation at this point) is that the only partition that is :Handled" by the initramfs methods (if that truly is the case) is the system partition (I believe it is mmcblkp026 not sure tho) this would likely make sense due to the fact that if the /EFS partition was also hadled then making changes thru "Secret codes" would also be replaced on reboot meaning that if you borked your IMIE all it would take to fix it is a reboot and from experience we know this is not the case.

Jaytronics said:
Are there any Devs that are good at reading and writing binary? I'm thinking that if someone was to make a mock OTA update file and attempt to load it and could read the processors I/O, then it would be possible to find the signature keys. Also, use the current OTA as it allows the OS to move back to KK. I wonder how fast I could learn ADB and binary. Lol!
Sent from my SM-N900V
Click to expand...
Click to collapse
Your theory is sound and does (to some extent bare a little further research):
Now to explain what i mean by further research: I have been developing ROMS since the early days of Windows mobile (long before android or iPhones) the original process of packaging and pushing a "ROM" to the mobile device involved several binary edits as you had to move your custom ROM into the exact location within the install package, part of the other issue is that your ROM had to be the EXACT same number of bytes as the OEM thus preventing you from adding to stock unless you removed the exact same number of bytes from your build.
Now as far as the theory being sound here is my explanation for that:
IF (and it's a big IF) we were to compare for instance the BL from a Tmobile note4 to that of ours and determine exactly (and I mean EXACTLY) where the binary portion was that contained the "Keys" and that portion was EXACTLY the same byte size then "In Theory" we could insert the "Keys" from our BL into the Tmobile BL and flash it on our device which since the keys would be correct would not balk at doing so.
Now for the explanation as to why this wont work:
In order to insert our keys into the Tmo BL they litteraly would have to be byte for byte identical or every single byte in the entire BL would be offset and this would in turn cause the flash to fail. And in the event it didn't fail the BL memory space would be offset by the exact same number of bytes and would likely brick your device.

cstayton said:
my guess (just speculation at this point) is that the only partition that is :Handled" by the initramfs methods (if that truly is the case) is the system partition (I believe it is mmcblkp026 not sure tho) this would likely make sense due to the fact that if the /EFS partition was also hadled then making changes thru "Secret codes" would also be replaced on reboot meaning that if you borked your IMIE all it would take to fix it is a reboot and from experience we know this is not the case.
Click to expand...
Click to collapse
The strange thing is if you edit /efs/FactoryApp with permission 0775,which is default, pressing the power button causes the phone to completely shut off, no power menu is shown. Changing it to 0644 yields a working power menu, but selecting any of the files to edit shows each file is blank. But I don't understand the fs enough to know a lot so I was just throwing that piece of information out there.

CJ74753 said:
I don't believe I am just seeing the "Updated" apks, such as Evernote. I can do anything I want, but upon reboot that bloat is back. Any idea how the /efs partition isn't restored if you change file permissions to 0644?
Click to expand...
Click to collapse
cstayton said:
in answer to #2, there is two possible explainations for this:
1. those reporting that the system reverts are actually see the "Updated" apks in the /data/app not the actual apks they deleted from /system/app or /system/priv-app. (I'm also on 5.0 so cant test this theory)
2. Samsung is using an initramfs or modified version of it, this would explain the complete revert to stock and possibly even the loss of root as the /system partition is "loaded" into ram and that is where all modifications are being written to including root so once the device reboots ram is cleared and reloaded from the mmcblk0xx firmware partition. (there have been conflicting reports of actual system files reverting).
Click to expand...
Click to collapse
I'm on 4.4.4
I froze all the bloat after the very first boot. Later, after successfully running kingroot, i used root explorer to go in and delete the apks and their associated odex files - both in system/app and system/priv-app. After a reboot, it was all there again.
Running Adaway to put a new hosts file in system/etc also restored the original hosts file after reboot. I was hoping files in system/etc would be more modifiable, but apparently not as Dr. Ketans sound mod apks that modify mixer_paths.xml also reverts.
The only thing that has worked for me is Dr. Ketan's sdcard fix, that allows to write to sdcard in kitkat. That is the only item that has stuck for me of the things I have tried.

jeepers007 said:
I'm on 4.4.4
I froze all the bloat after the very first boot. Later, after successfully running kingroot, i used root explorer to go in and delete the apks and their associated odex files - both in system/app and system/priv-app. After a reboot, it was all there again.
Running Adaway to put a new hosts file in system/etc also restored the original hosts file after reboot. I was hoping files in system/etc would be more modifiable, but apparently not as Dr. Ketans sound mod apks that modify mixer_paths.xml also reverts.
The only thing that has worked for me is Dr. Ketan's sdcard fix, that allows to write to sdcard in kitkat. That is the only item that has stuck for me of the things I have tried.
Click to expand...
Click to collapse
this would definetly point to the initramfs scenario meaning in order for root to "Stick" we would need modifications to kingsroot or whatever perm root method is used to write directly to the mmcblkxx partition rather than the /system folder (which is nothing more than volatile RAM space.)

Same case for me, any changes made were reverted on reboot. I used King to temp root, removed all traces of knox, then actually attempted to convert and install SuperSu but it would not install. Just said that the install failed and to try again.

2016 version (new fingerprint scanner, combined sim/sd)

Hey guys,
It seems more and more people are receiving the new version of the P8000:
- Stock Android 6
- New fingerprint scanner that is moved slightly higher and is able to unlock phone from screen-off (I confirm this is working)
- Sim 2 is combined with the micro-sd (I haven't tried whether you can have them both in at the same time)
- Somethings new about the display, since people are reporting errors with it after flashing older roms.
Warning: do NOT flash other roms. We have no way to unbrick the soft bricks yet!
---
Other topics that refer to this version:
http://forum.xda-developers.com/elephone-p8000/general/rom-p8000-t3431571
http://forum.xda-developers.com/elephone-p8000/help/stock-rom-p8000b-t3434477
http://forum.xda-developers.com/elephone-p8000/general/p8000-version-announced-t3346848
---
For development:
- The phone does not come pre-rooted. We have no way to flash custom recovery yet. Any tips for getting root? I've tried such tools as Kingo and vRoot, they don't work.
- We need the blocks file (scatter file) for SP Flash Tools. MTKDroidTools reports "unknown rom structure". Any help? Would love to start working on this.
Looking forward to hearing from others who have this version/who can help me with these questions.
Thanks!
Emile

Nice! Can you provide a dump from /system and /boot maybe?

BlueFlame4 said:
Nice! Can you provide a dump from /system and /boot maybe?
Click to expand...
Click to collapse
I would, if I knew how to. Any pointers?

Emileh said:
I would, if I knew how to. Any pointers?
Click to expand...
Click to collapse
Sure thing. On a rooted device, go into adb shell.
Then use "mount" command to check which partitions are mounted. One should be "/dev/block/platform/mtk-msdc.0/by-name/system" or similar. Use "dd if=/dev/block/platform/mtk-msdc.0/by-name/system of=/storage/emulated/0/system.img bs=1M" to dump the system to the internal sdcard to the file "system.img". If adb complains that bs=1M is an invalid option, try again without that one. A system dump can take some time where you will not get any feedback, so be patient there
Do the same for boot. So "/dev/block/platform/mtk-msdc.0/by-name/boot" should be the way to go for the path. I cannot tell the definite pathes on Android 6.0 but I am rather sure they are more or less like this.
If you run into troubles, just ask

BlueFlame4 said:
Sure thing. On a rooted device, go into adb shell.
Then use "mount" command to check which partitions are mounted. One should be "/dev/block/platform/mtk-msdc.0/by-name/system" or similar. Use "dd if=/dev/block/platform/mtk-msdc.0/by-name/system of=/storage/emulated/0/system.img bs=1M" to dump the system to the internal sdcard to the file "system.img". If adb complains that bs=1M is an invalid option, try again without that one. A system dump can take some time where you will not get any feedback, so be patient there
Do the same for boot. So "/dev/block/platform/mtk-msdc.0/by-name/boot" should be the way to go for the path. I cannot tell the definite pathes on Android 6.0 but I am rather sure they are more or less like this.
If you run into troubles, just ask
Click to expand...
Click to collapse
Thank you for your great instructions! The problem is that we've yet to achieve root on this device. We don't have a custom recovery for this version of the P8000 yet and other 'standard' methods of rooting don't work for me.
(I'm pretty solid in shell, so I'll do this afterwards, but I guess root is actually the first step).
// Edit to say: it does not come pre-rooted

Since the elephone support on facebook didn't realize there are two different versions of the P8000 available, I still need a ROM to unbrick my phone.

flo1k said:
Since the elephone support on facebook didn't realize there are two different versions of the P8000 available, I still need a ROM to unbrick my phone.
Click to expand...
Click to collapse
Ok, we know that, but doesn't really help us
Can you write them an e-mail?

I will do
Edit: OK, see if there will be an answer.

Thank you flo1k!

I have e-mailed as well, and would like to post on the Elephone forum, but don't seem to have access (because of minimum post count, I guess)
Anyone willing to ask for a ROM for the new P8000 on the forum there?

ROM Dump
@BlueFlame4
I can provide ROM dump in two versions:
1) a dump from adress 0000 0000 to 9d80 0000 (apr. 2.5 GB in one file)
2) a readback generated with the scatter.txt of the 'old' 5.1 stock ROM (apr. 2.8 GB seperated in 23 files)

FrauHofrat said:
@BlueFlame4
I can provide ROM dump in two versions:
1) a dump from adress 0000 0000 to 9d80 0000 (apr. 2.5 GB in one file)
2) a readback generated with the scatter.txt of the 'old' 5.1 stock ROM (apr. 2.8 GB seperated in 23 files)
Click to expand...
Click to collapse
The second choice looks promising

Maybe a stupid question
where shall I upload the files - any preferred webspace?
I'm uploading the files - because they contain my NVRAM I send the link as PM as soon as the upload is finished

FrauHofrat said:
Maybe a stupid question
where shall I upload the files - any preferred webspace?
I'm uploading the files - because they contain my NVRAM I send the link as PM as soon as the upload is finished
Click to expand...
Click to collapse
Are you sure we're talking about the same version of the P8000? Cause as far as I know there isn't 5.1 available for this version... Right?
Just checking thank you for your help in any case!! Really looking forward to it.
// edit: ah, you just used the old scatter file. But does that one work for this version?

Emileh said:
Are you sure we're talking about the same version of the P8000? Cause as far as I know there isn't 5.1 available for this version... Right?
Click to expand...
Click to collapse
No, there is only one Firmware available - the mysterious P8000_6.0_20160516.
Btw, this Phone contains a new mainboard model "K06TS-L-V2.0.3" - the 'old' mainboard is moder "K05T...."
// edit: ah, you just used the old scatter file. But does that one work for this version?
Click to expand...
Click to collapse
No, it doesn't work resp. the phone boots with this firmware, but the LCD-driver is the wrong one - the display only shows coloured lines and blurry spots. And there are probabely some more bugs ....

FrauHofrat said:
No, there is only one Firmware available - the mysterious P8000_6.0_20160516.
Btw, this Phone contains a new mainboard model "K06TS-L-V2.0.3" - the 'old' mainboard is moder "K05T...."
No, it doesn't work resp. the phone boots with this firmware, but the LCD-driver is the wrong one - the display only shows coloured lines and blurry spots. And there are probabely some more bugs ....
Click to expand...
Click to collapse
But if the phone boots with the firmware, doesnt that mean that the scatter file of the regular P8000 works? Since it flashes the firmware correctly.

The problem is that I was not able to flash the 'readback files' to the faulty phone.
When selecting 'Only Download' at SP-Flashtool I got the error "PMT... must be download"
When selecting 'Firmware Upgrade" I got some BROM error code
In both cases I used the same scatter,txt which I used to 'readback' the firmware from the working phone
Actually I have to correct my statement in post #15:
I flashed the faulty phone with the last 5.1 stock ROM (160711) - with this stock ROM the phone boots up but LCD (and probably more things) is not working.

I have actually gotten alot further
You have the use the scatter.txt from Android 6.0, which works perfectly fine. I have been able to extract boot.img, system.img and recovery.img that way (using Readback in SP Flash Tools)
Which ones do you need?
They probably flash fine (only thing I've flashed so far are custom recoveries, and although my ported PhilZ starts, I havent gotten it to mount anything.)
A little warning: don't use anything that has anything to do with Android 5.1. Those scatter files don't work

These are great news!
"Which ones do you need?"
Probably all of them

Ok this contains the scatter file, preloader, system.img, boot.img and stock recovery.img
https://ehaffmans.stackstorage.com/index.php/s/uKGKCir0BociydU
You need SP Flash Tools v5, select the scatter file first, then deselect everything, and only select these 4 and manually select the correct files.
Btw, the name of the preloader file is wrong, don't worry. It came from this phone
I am of course not responsible for anything!
Can you guys please confirm this doesn't contain anything personal? Like personal files or IMEI or something. Thanks!

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