Related
Thanks to anomalous3 over on the vibrant forum he was nice enough to port over his rom to our side based off of the new source code released by samsung
"If you feel like being a guinea pig, or know anyone who does, the deodexed build is here:
http://getyourboneon.com/CaptivateDeodexed.zip
Since I don't have a captivate I can't really test it, but it should work fine. It's based off that UCJH2 build. I didn't include any lag fixes since they've proliferated out of control, but I did include ext manipulation libraries and e2fsck to make life easier for people who want to use one of the lag fixes."
Please note I have NOT tested this rom yet, I don't have my captivate. Please somebody could test this and let us know if there's any problem so we can let him help us fix it.
Again, not responsible for whatever happens to your phone.
Here is the original thread I posted for reference.
http://forum.xda-developers.com/showthread.php?t=746466
EDIT: I'm going to assume you would install this like any other rom via update
EDIT2: anomalous3 has updated the link with corrections. Let us know how it works
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Zilch25 said:
Well... since I can't seem to get enough of abusing my phone, guess I'll give this a whirl =P
And I have JH2, So I suppose that makes me a good candidate
Click to expand...
Click to collapse
let us know how it goes
Do I just rename this to update.zip and go recovery and reinstall packages?
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Will do, flashing back to a stock JH2 while I download! I've been waiting for something like this
Clienterror said:
And when I try it and my phone crashes I'll blame Zilch because it's convenient.
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It probably was my fault anyway =P
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
damn it, wish this was around 2 hours ago when i was bored! its too late now to ruin my phone haha.. tomo sometime maybe i'll try..
Question...Do I have to install the stock Captivate ROM first as it states in the linked post? I have the stock ROM that is rooted with the AT&T bloatware removed. The only other mod is the lagfix version 2.3...Can I just flash this over that?
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
nammyczc said:
you should be able to, according to his original thread on the vibrant forums, the directions were to put on internal sd card and load via clockwork best method. or via recovery mode works too
Click to expand...
Click to collapse
That's what's taking me so long... seems like JH2 is having some issues with update.zips... namely it's getting to the "Opening installer" then "Install Aborted". The(not new) update.zip for root still works, so I'm tossing on clockwork to see if I can get this thing crammed on here with that.
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Zilch25 said:
Installing from Clockwork:
Hoses up during the copying files stage
E:Can't symlink /system/bin/bugreport
E:Failure at line 5:
symlink dumpstate SYSTEM:bin/bugreport
Then install aborts
Click to expand...
Click to collapse
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
BuglessPete said:
That's because the capitvate uses a different independent bugreport that is not a symlink of dumpstate.
Simply edit the update script in the meta folder and remove that line.
I deodexed the actual captivate files the other day, just havnt tested/posted them, way too busy with school
Click to expand...
Click to collapse
I'll pm him about this
nammyczc said:
I'll pm him about this
Click to expand...
Click to collapse
Also ask him why superuser.apk is in the xbin folder.
vietphunguyen said:
Wait a sec, what does deodexed mean? I looked it up and it means no oxded files, but i don't know what those files are...
Click to expand...
Click to collapse
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
golemaw said:
-From googling, found on XDA:
Deodexed ROMs have their .apk's (which are basically the application packages) repackaged in a certain way. An "odex" can be thought of as a collection of parts of applications that have been pulled out and optimized before booting. This speeds up the boot process - in a way, it preloads part of the applications - but it also makes hacking those apps difficult because part of the original code is already extracted somewhere else.
Deodexing is just a process of putting those pieces back into the original applications. It takes a while to extract those parts and build the .dex cache (aka Dalvik cache), but only because the relevant parts aren't in an easy-to-access place for the system. The advantage of this is that an app can be modified effectively and the developer doesn't have to worry about conflicts from the separate odex part of the code.
So, short version: "Deodexed" ROMs have all their apps put back together. If an app can be themed, for example, a deodexed version of that app will not get messed up when the modified .apk tries to mesh with the odex of the original un-modified .apk. Because it's not there.
If you want an aftermarket theme, you need a deodexed ROM. I'm not sure if deodexing can be done to individual apps within a non-deodexed ROM.
Click to expand...
Click to collapse
This is correct. Deodexed ROMs can be themed...
BuglessPete said:
Also ask him why superuser.apk is in the xbin folder.
Click to expand...
Click to collapse
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
anomalous3 said:
Good catch on that one Yeah, it surprised me that a lot of the stuff in the captivate doesn't rely on toolbox either. I might even port that over to the Vibrant since I think that toolbox is a stupid vestigial substitute for busybox anyways. Link updated, let me know if it works.
Click to expand...
Click to collapse
updated original post with info
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
AndrewTL said:
See: http://forum.xda-developers.com/showthread.php?t=1402440
Sorry - don't have enough posts to reply directly in the dev tree, but it would seem to me that if all the updates are just zip files, couldn't they be modified to include root? Then the normal update system would handle the installation? You wouldn't need root then.. Just dump it into the "kindleupdates" folder and let it do its thing. It would just install it.
It looks like the install is just running a script.. one of the first things it does is wipe the system folder.. doesn't mean you can't include additional files and copy them in afterwards with the script does it?
Click to expand...
Click to collapse
You need to go through all the lines of code for that and I believe some of them are binary files as well. Possible but will take much time. For now we must wait until someone finds a better solution.
Sent from my Kindle Fire using Tapatalk
signature issues.
6.2.1 experiment?
transfuntioner said:
signature issues.
Click to expand...
Click to collapse
Maybe I don't follow the process.. but I'm guessing no signatures..
not a signed bootloader.. no signatures required...
Get beyond compare and look at the differences between the OTA updates and the zip that Eldarerathis put together.
The ".bin" files are just ".zip" files renamed.
Look at
META-INF/com/google/android/updater-script in the bin files they release.
It is just a script.
And to do the things that it is doing, it has to be getting root permissions while it is running.
I don't know how to recover if it doesn't work, but I half wonder if you were to take the zip that fellow created, change the extension to ".bin" and just dump it into the update folder if the fire would install it for you?
He took out the image files from the script. He's just updating the system tree directly. He doesn't update the bootloader, recovery or backup trees.
For that matter if those contained something nasty, they could probably be pulled from an earlier update.
== cut ===
package_extract_file("recovery.img", "/dev/block/platform/mmci-omap-hs.1/by-name/recovery");
show_progress(0.100000, 10);
package_extract_file("u-boot.bin", "/dev/block/platform/mmci-omap-hs.1/by-name/bootloader");
format("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup");
mount("ext4", "EMMC", "/dev/block/platform/mmci-omap-hs.1/by-name/backup", "/backup");
package_extract_file("backup_userdata.zip", "/backup/backup_userdata.zip");
== cut ===
Please nobody try this idea that doesn't know enough to recover if it doesn't work, because I've not a clue how.
But could someone explain why wouldn't it work?
Worst case the rev might need to be manually edited to bump it one for the script.
Seems like it might be an easy way to get around headaches with OTA updates.
Andrew,
Are you having issues with getting into recovery so that you can test this? The Devolopers have a copy of TWRP 2 working perfectly on the device so you can get a clean backup of the OS before you test.
You sound like you may know what to do to fix the issue and I just want to help you get a good recovery in case it doesn't pan out or for testing.
~enjoy.
Actually I'm just afraid of messing up what I have working now.
I've got TWRP 2 running with the 6.2.1 image.
I'm setting these up as gifts. I spent a good 12 hours yesterday fighting the darn things. Guess I'm getting gun shy. Had a lot of issues with adb. Kudos to the new utility and setting the second ports up. I'm learning.
The OTA install wipes the system directory. It's in the script.
I was tempted to just comment that line out and see if it would leave the rest alone.
If I brick the thing its going to be painful for me to sort out.
I also didn't want to risk losing root. I also haven't tried loading an older OTA version.
At the time, I couldn't ask the fellow that developed the rooted 6.2.1 zip the question in his thread as I didn't have enough posts.
I'm going to be out of pocket for quite some time. I'm not going to have time to spend like this again for at least a few days.
But I was checking the zip he made versus the .bin/.zip files that the OTA releases using beyond compare. I wanted to see what files had actually changed.
That's when I found that script. It is manipulating permissions directly. It has to be running at a root level. I don't see anything like a signature on it, so why couldn't their own update system be used to tweak their own updates to allow for root?
I don't think I have seen any mention of this idea yet. Sorry if I missed it...
In a recent thread about the 6.2.2 update and people wanting to prevent it, I thought I read that someone saw the file show up in the update directory. I'm assuming this means the same 'kindleupdates' directory you could manually drop the update into -- but if not, the idea is the same. Why not just take some step to prevent access to this directory?
The exact step to take would depend on how smart the developers were about dealing with problems in the update process
The easiest step would be to chmod 555 it. But of course if the update process is running as root it is under no requirement to honor those permissions! (My experience in the unix world tells me that about half the time, programs running as root do honor the permissions even though technically root overrides them).
Another easy step would be to delete it altogether. But they probably thought of that (if it's /mnt/sdcard/kindleupdates where someone could easily accidentally delete it) and recreate it if it's missing.
One trick that is often done is to replace the directory with a file. Some programmers do not think to check this kind of condition - they see there is something there, but they get an error opening it as a directory, and they just declare it's an error.
A more subtle trick would be to replace the directory with a symlink that points to a read-only directory (such as /system). In this case, they could open it as a directory, and just fail to write there. The programmer probably would not have thought to check whether it's a link vs. a real directory. One possible gotcha is if you point to /system, and /system is r/w, then the update could screw something up under /system. So maybe mount /system r/w, mkdir /system/kindleupdates, remount /system r/o, then link the update dir to /system/kindleupdates.
And finally, I don't know if Android has any kind of loopback filesystem capability, but loopback-mounting something read/only on that directory would certainly fake the OS into thinking there was a directory there; it would definitely be read/only, and I don't think they would ever think to check whether there is actually some filesystem mounted there! (and if there was, all you need is an app that constantly accesses some file you put there, which would make it busy so that it couldn't be unmounted).
The first method won't work because the sdcard partition is fat32 and doesn't accept unix permissions.
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
well, i just deregistered my kindle acount and i'm still in 6.2.1...
b63 said:
it downloads to the /cache folder - this folder is also used for other things like market downloads, logs from twrp and i don't know what else
Click to expand...
Click to collapse
Ah, that makes this less practical. Still, perhaps when the next update comes out I can try a variation on this but it requires the filename to be known.
If the update is downloaded as a single file to /cache, which is named the same as the file you can manually grab, then someone who hasn't gotten 6.2.2 (and is not averse to this failing) can try this in a root shell:
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin
mkdir /cache/update-kindle-6.2.2_D01E_3205220.bin/blah
The purpose here is to put something unremovable in the way of the file it wants to download. Most likely if the update sees something with the existing name there it would probably want to blow it away (after determining it's incomplete) - and since any update there would normally be a regular file, they probably would do nothing more complicated than a simple unlink syscall to delete it before re-downloading. However, since it's a directory with something in it, that unlink will fail. In actuality, making the subdirectory (second command above) should be unnecessary because the unlink should not work for directories; there's a special rmdir syscall for them.
btw. there are a lot of threads about this from the 6.2.1 update
make a short search for "prevent ota update" - you'll have a lot to read ...
Click to expand...
Click to collapse
I did read a lot of that last time and I don't think I actually saw a definitively successful method. If there is one it should be stickied
My interest in this is a little different from most of you guys - I have very limited satellite internet and I don't like these unscheduled 185-meg downloads so I want to be able to update only when I want mostly to control that. This kind of means looking for the least-intrusive way to accomplish this.
/cache/update-kindle-6.2.2_D01E_3205220.bin is exactly where it downloads
if you find a way to even prevent the download, that would be greatly appreciated
Unfortunately I already got the update so I can't try it this time.
at least you could try your method with a dummy file of an other name and try to overwrite it with adb - if you can't overwrite it there's a good chance
I think I'm about the only one who prevented 6.2.1. I did it by constantly checking the cache folder. Found the update by chance and deleted it before it updated. Waited over a week for it to come back. Never did. An app that watched the cache folder for the updates and then moved/deleted them would work fine
Sent from my SGH-I897 using xda premium
jcase already work a way around this automatic OTA update, so when FIREMOD is ready to replace burrito I think we will have no more problem with this OTA issue. (you can find jcase announcement in the kindle developer section)
Heres what I have done to prevent this.
1) Droidwall (white list only the apps you want to allow internet access)
2) Removed "otacerts.zip" from /system/etc/security/otacerts.zip.
3) I removed "OTASilentInstall.apk" /system/app
4) Installed this 6.2.2 based Rom http://forum.xda-developers.com/showthread.php?t=1439916
Hopefully this eliminates the OTA. I had my Fire rooted on 6.2.1 with twrp and it OTA'd on its own, broke root and twrp. So I rerooted with burritoroot2 and installed CWM based recovery.
Thanks to Koshu and all contributors for the CM9 port. It is amazing. I am finally using the tablet on a daily basis.
One app that I would like to work with the CM9 port is MyScript Stylus Mobile.
I have restored the app using Titanium Backup from one of my nandroid backups. The app restored without a problem. But everytime I try to run it (use it as an input method), I get the following error message:
Compatibility error. This version of MyScript Stylus if not compatible with this device.
So my question: Is there something that I can change in CM9 that would trick the app in to thinking that this is the stock Lenovo ROM? For example, could it be as simple as changing the device id in build.prop?
I can provide a logcat if that would help someone figure out what exactly the app is trying to verify.
Thanks.
I pulled the build.prop off my nandroid backup and compared it to the current build.prop. Based on that comparison here are the list of items that are different:
ro.build.id
ro.build.display.id
ro.build.version.incremental
ro.build.version.sdk
ro.build.version.release
ro.build.date
ro.build.date.utc
ro.build.type
ro.build.user
ro.build.host
ro.build.tags
ro.product.model
ro.product.brand
ro.product.name
ro.product.device
ro.product.manufacturer
ro.build.product
ro.build.description
ro.build.fingerprint
**And this was not in the original build.prop
ro.cm.device=thinkpadtablet
Can someone help me identify what I can change without having any negative side effects?
For example, which ones are merely identifiers that have no deeper connection to the OS.
Of course, I am assuming that the MyScript Stylus app is just looking for some simple information (such as ro.product.manufacturer) as verification. So, if I change it back to the original the app will work.
Thanks.
Modifying the build.prop as far as I know is safe. In my case I've completely swapped out the whole build.prop when trying to get an incompatible game to work. I simply replaced the build.prop with that of a galaxy tab 10.1. I have also done this before on my galaxy s2. Its called spoofing the build.prop lol.
Anyway the bottom line is that its completely safe to modify your build.prop as it has no boot functions, so it won't brick your device. Just backup ur current build.prop and then replace it with the one from the original thinkpad stock rom.
The only issue you may have is if you have apps that depend on recognizing your current build.prop but since you're on a cm9 port I doubt that. So its safe. But backup as you may need to replace the build.prop when flashing a rom or update.
The build.prop is somewhere in the system folder (can't remember exact path but will check for u)
Overall, doing anything to your build.prop is safe and reversible but if you still want to just edit lines in it, it's still safe but I don't know what lines to edit to make that app work.
Thanks for the reply.
Unfortunately, it didn't work out. I replaced all the values for the items in build.prop that I mentioned above using the info from the original Lenovo build.prop. However, the tablet got stuck in a bootloop after rebooting. The Lenovo logo comes up, but the image that comes immediately after that just keeps cycling.
I also wasn't able to push the backup build.prop file through adb due to permission issues. This was unexpected as the tablet is rooted (obviously).
So I just restored a previous backup using CWM.
Due to what happened, it seems like the boot sequence does verify something from the build.prop file. It seems like I am stuck until I figure out (with someone's help) what exactly the app is trying to verify - hopefully it isn't something that is also verified during boot.
Thanks, again, for the help.
Any other suggestions?
Like I said, swap out the build.prop file. Its possible that while editing the values, you made a mistake. Just copy the stock build.prop and use to root file explorer to replace it. If you are good with adb/terminal then that's a better option as you can use root terminal to replace the file. I'm surprised that you have issues when editing your build.prop because I'm on the cm9 port but using my galaxy tab's build.prop without any issues
Did you try installing it from the market? In the past i had sometimes problems with restoring titanium backups to new roms, but thats app dependent. And could you find anything usefull in the logcat?
darkhandsome18 said:
Like I said, swap out the build.prop file. Its possible that while editing the values, you made a mistake. Just copy the stock build.prop and use to root file explorer to replace it. If you are good with adb/terminal then that's a better option as you can use root terminal to replace the file. I'm surprised that you have issues when editing your build.prop because I'm on the cm9 port but using my galaxy tab's build.prop without any issues
Click to expand...
Click to collapse
Unfortunately swapping the file didn't work either. I got stuck in the same boot loop.
If you don't mind could you send me a link to the Galaxy Tab build.prop that you are using. That may help me identify what I can and can't change. Thanks.
Koshu said:
Did you try installing it from the market? In the past i had sometimes problems with restoring titanium backups to new roms, but thats app dependent. And could you find anything usefull in the logcat?
Click to expand...
Click to collapse
Koshu thanks for the input. I hadn't considered installing it from the market.
The app is only available on the Lenovo App Store - so I installed that and then installed the MyScript Stylus app through the App Store. Unfortunately, that didn't make any difference. I am still getting the exact compatibility error when I try to run the app.
I haven't seen anything obvious in the logcat that would point towards the verification that the app is doing. However, I don't really know what to look for. I will upload the logcat.
Here's the logcat.
What I did while generating the logcat: I opened Dolphin Browser and switched the input method to MyScript Stylus. When the compatibility error came up I just clicked on "Close" four or five times, and then I clicked on "Change IM" and picked the Android keyboard.
SOLVED
It turns out that all that was required was to change the following lines in the build.prop file
ro.product.model=ThinkPad Tablet
ro.product.brand=Lenovo
I decided to try changing only those lines after watching this:
youtube.com/watch?v=cssyIE4maZY
MyScript Stylus is now working perfectly.
Also -in case anyone is interested- after making this change to the build.prop, the MyScript Notes Mobile app is also working (had the same compatibility issues).
Thanks to darkhandsome18 and Koshu for the replies.
On stock ROM, I can not edit the build prop because it just gives me system can not be mounted errors and on custom ROMs (7.1 because I can't use 8.0 due to WiFi calling and volte not working for me) I am able to edit the build prop just fine but then the camera won't launch. After deleting the line and restarting cameras still don't work. What gives?
you have to restore your build.prop permission to rw-r-r
jackydroid68 said:
you have to restore your build.prop permission to rw-r-r
Click to expand...
Click to collapse
Stock it won't let me do that. I prefer stock so I wish I could remember how I fixed the Mount issue. I believe I've done it before.
Are you stock and rooted... or just "stock" and using TWRP to modify the file? If you are using TWRP to modify the file, you will have to change it's permissions with adb in TWRP after you have mounted system read-write in TWRP, like this:
Code:
adb shell
cd system
chmod 644 build.prop
- Source
acejavelin said:
Are you stock and rooted... or just "stock" and using TWRP to modify the file? If you are using TWRP to modify the file, you will have to change it's permissions with adb in TWRP after you have mounted system read-write in TWRP, like this:
- Source
Click to expand...
Click to collapse
I'm stock rooted. However on stock rom, it won't even let me mount the system in TWRP. I check the box and nothing happens.
carnivalrejectq said:
I'm stock rooted. However on stock rom, it won't even let me mount the system in TWRP. I check the box and nothing happens.
Click to expand...
Click to collapse
Since your not really explaining how you are trying to do it, I am going to assume adb (which is easiest)...
Code:
adb shell
su
mount -o rw,remount -t ext4 /system
chmod 644 /system/build.prop
if the mount command doesn't work, try it like this...
mount -o rw,remount /dev/block/dm-0 /system
Then exit and reboot the phone, should be good after that.
I haven't tried rooting my G5 yet, probably never will, but I do know that many newer phones have special security in place and you cannot remount from adb.
I assume you have tried mounting /system RW in ES File Manager or Solid Explorer?
acejavelin said:
Since your not really explaining how you are trying to do it, I am going to assume adb (which is easiest)...
if the mount command doesn't work, try it like this...
mount -o rw,remount /dev/block/dm-0 /system
Then exit and reboot the phone, should be good after that.
I haven't tried rooting my G5 yet, probably never will, but I do know that many newer phones have special security in place and you cannot remount from adb.
I assume you have tried mounting /system RW in ES File Manager or Solid Explorer?
Click to expand...
Click to collapse
Yeah I haven't even tried it through adb yet because my laptop is slow as molasses but I have tried through TWRP and solid explorer. Everything mounts fine on custom roms, just not stock.
I just went through this a few days ago, I was going bonkers. I managed in the end to mount system in TWRP, but it was like a different set of files... build.prop was there, I pulled it, edited, and pushed it back, but reboot into system had a DIFFERENT build.prop. Made no sense. I rebooted back into TWRP, mounted system again, found the build.prop there had my changes. It was like there were two versions of /system, one that TWRP gave me and one that the system used. It was maddening, to say the least. Somewhere around 2 or 3am, I started getting sloppy trying to get to the bottom of all this, and I accidentally deleted my system partition and soft bricked the phone.
Thankfully I found this thread:
https://forum.xda-developers.com/g5-plus/development/rom-twrp-flashable-stock-builds-t3675616
These are stock roms that are flashable in TWRP, but modified in that Dm-verity and force encryption have been disabled in the boot images. With this installed, my phone booted properly again and TWRP had no problem accessing the file system... and thankfully this time around, it was the same /system being mounted as the booted phone, everything actually made sense for a change.
I would strongly recommend flashing that modified stock rom and starting over. Camera2 and everything are running properly and I couldn't be happier.
Dishe said:
I just went through this a few days ago, I was going bonkers. I managed in the end to mount system in TWRP, but it was like a different set of files... build.prop was there, I pulled it, edited, and pushed it back, but reboot into system had a DIFFERENT build.prop. Made no sense. I rebooted back into TWRP, mounted system again, found the build.prop there had my changes. It was like there were two versions of /system, one that TWRP gave me and one that the system used. It was maddening, to say the least. Somewhere around 2 or 3am, I started getting sloppy trying to get to the bottom of all this, and I accidentally deleted my system partition and soft bricked the phone.
Thankfully I found this thread:
https://forum.xda-developers.com/g5-plus/development/rom-twrp-flashable-stock-builds-t3675616
These are stock roms that are flashable in TWRP, but modified in that Dm-verity and force encryption have been disabled in the boot images. With this installed, my phone booted properly again and TWRP had no problem accessing the file system... and thankfully this time around, it was the same /system being mounted as the booted phone, everything actually made sense for a change.
I would strongly recommend flashing that modified stock rom and starting over. Camera2 and everything are running properly and I couldn't be happier.
Click to expand...
Click to collapse
I believe I AM using one of those zips so im not sure how this ended up happening but I'll flash again and see if it helps. Thank you so very much for the reply. Really appreciate it. How's camera2 working for you? You using that modified Google cam with HDR+ or is it just helping the stock camera even more so?
carnivalrejectq said:
I believe I AM using one of those zips so im not sure how this ended up happening but I'll flash again and see if it helps. Thank you so very much for the reply. Really appreciate it. How's camera2 working for you? You using that modified Google cam with HDR+ or is it just helping the stock camera even more so?
Click to expand...
Click to collapse
Stock camera still seems to have sharpening and NR that reduces details. I think it improved some other apps, especially enabling the use of Camera2 on apps that use it (and even allows some apps to record in RAW, which is neat but too much trouble to get working properly). But apps that don't necessarily use Camera2 will still look similar I think, including the stock app.
The Google HDR+ app really makes the hardware here shine, I've got to admit. Its a shame that since I'm running the stock firmware we're stuck with the 32-bit buggy version. It isn't very stable, and the focusing is kind of frustrating when it decides not to cooperate. There's a workaround to use video mode to focus, then switch back to camera mode and lock AE/AF, but even then sometimes I find that on close-focus objects, the focus will shift a bit upon reinit on photo mode before I can lock AF. But when it works... man, it REALLY makes a difference! I went from wanting to return the phone to being rather pleased with it.
Attaching a couple of samples. One of harsh contrasting light by a window, and another in a dark alley outside my office.
Dishe said:
Stock camera still seems to have sharpening and NR that reduces details. I think it improved some other apps, especially enabling the use of Camera2 on apps that use it (and even allows some apps to record in RAW, which is neat but too much trouble to get working properly). But apps that don't necessarily use Camera2 will still look similar I think, including the stock app.
The Google HDR+ app really makes the hardware here shine, I've got to admit. Its a shame that since I'm running the stock firmware we're stuck with the 32-bit buggy version. It isn't very stable, and the focusing is kind of frustrating when it decides not to cooperate. There's a workaround to use video mode to focus, then switch back to camera mode and lock AE/AF, but even then sometimes I find that on close-focus objects, the focus will shift a bit upon reinit on photo mode before I can lock AF. But when it works... man, it REALLY makes a difference! I went from wanting to return the phone to being rather pleased with it.
Attaching a couple of samples. One of harsh contrasting light by a window, and another in a dark alley outside my office.
Click to expand...
Click to collapse
Those do look pretty good. I'm gonna flash one of the zips when I can finally get a chance and try and do this build prop edit again. Any idea which camera apps from the play store use the API?
Off the top of my head I do not. There was a link to a modified one here somewhere which supported RAW in DNG format, but I found it unreliable and a major pain to edit and make look like anything on the phone.
Meanwhile, I found this thread about modifying the in-camera processing to reduce the sharpening and noise reduction:
https://forum.xda-developers.com/showpost.php?p=72246474&postcount=9
Flashed the zip in that post to my stock rom and it cleaned up a lot of apps, including the stock photo app. Cam2 api is necessary for google's HDR plus, but if you just want a better image out of the stock apps, I think that flash is what you need.
Dishe said:
Off the top of my head I do not. There was a link to a modified one here somewhere which supported RAW in DNG format, but I found it unreliable and a major pain to edit and make look like anything on the phone.
Meanwhile, I found this thread about modifying the in-camera processing to reduce the sharpening and noise reduction:
https://forum.xda-developers.com/showpost.php?p=72246474&postcount=9
Flashed the zip in that post to my stock rom and it cleaned up a lot of apps, including the stock photo app. Cam2 api is necessary for google's HDR plus, but if you just want a better image out of the stock apps, I think that flash is what you need.
Click to expand...
Click to collapse
I ended up flashing the stock zip from the post you linked and after that the change to build prop for sure worked and now I'm playing around with one of the Google cams so thanks a lot for sure man. I've been wanting to try it for months while still being able to remain stock. Really appreciate it.
carnivalrejectq said:
I ended up flashing the stock zip from the post you linked and after that the change to build prop for sure worked and now I'm playing around with one of the Google cams so thanks a lot for sure man. I've been wanting to try it for months while still being able to remain stock. Really appreciate it.
Click to expand...
Click to collapse
No problem! Glad it helped! I should probably compile some sort of FAQ or something, lots of information spread across too many threads to make sense of it. But just FYI, I'm pretty sure OTA updates won't work anymore now that you've modified the system.