Hi there! I'm trying to modify my build.prop to set my DPI to 400, but i can't seem to make the change stick. I've searched for a solution for days, reset my phone a few times - the few solutions i found haven't actually worked. Here's some info:
Device: HTC One International(m7ul)
Recovery: CWM Recovery v6.0.3.2
ROM: HD Revolution Google Edition 4.1 (with all performance tweaks selected in AROMA installer, including build.prop tweaks)
Root: SuperSU
Solutions attempted:
-Setting RW before changing the file and setting it as RO afterwards, both through file manager and shell. File resets regardless.
-Modifying existing build.prop in ROM archive. Refused access.
-Creating a zip with the modified build.prop, installing it through CWM. CWM refused to install the file
-hamsteyrs Google Play DPI Fix tool. Required renaming of com.vendor1.apk to Phonesky.apk and running the tool instantly afterwards, as the application would rename itself back(in the end, i had to make it a flashable zip which created both a Phonesky.apk and a com.vendor, and outright broke my DPI in applications, ranging from different values at random)
I'm outright stumped by this, as nothing seems to be doing what i want it to.
Related
Back a year ago I rooted my nexus one phone, but the thing is I uninstalled a few stock apps. I had no idea that my updates would be a pain.
What I found out is that each new google update does a ton of asserts on files that it expects to be there. I had a problem with google books when I tried to update from 2.3.3 to 2.3.4, but someone on this forum hack a cracked version that allowed me to do so.
Now the annoying problem is back again, and this time, it's saying something about assert_failed: apply patch check ("system/app/EmailGoogle.apk...
I tried to find an EmailGoogle.apk out there, and I was able to find it, but if I was to use it, it wouldn't connect at all, then it would crash. I also placed it in system/app folder, and still same problem.
Is there a way for me to hack the update.zip so I can tell it to ignore these assertions?
AHH! I figured it out!
After much searching for updating scripts, I found out that there is indeed a file that tells your phone how to perform a patch update.
This involved me rebooting the phone 7 times (with about 5 times prior with previous experimentation)
Okay what I had were the following items
-Dropbox
-Root Explorer
-Laptop
Initially I got the error after running anon ra recovery, but I lost it when I accidently updated 2.3.4 again (I stupidly named my files as update.zip, update1.zip, update2.zip). Actually, I lost root (the phone still had the unlocked thing on it, but it was fooled). So I used this website (to root my phone again):
http://chensun.net/android-development/root-nexus-one-with-android-2-3-3-gingerbread/8/
So to get the specific error
1.you shut down your phone
2. reboot by pressing power button and down volume and hold it
3. Select recovery by navigating using the down volume, and select it by pressing power button.
4. After it reboots again, scroll down using your trackball and select Flash zip from sdcard
5. make sure you toggle signature verification to disable
6. select your update.zip
thats how you get your error
to fix:
1. So I took the signed zip file, and uploaded it to my dropbox
2. I opened the file using winrar (DO NOT UNZIP THIS FILE TO EDIT) the reason you do not want to unzip is because if you zip it up again you lose the signature, and your phone won't find the script
3. I used winrar to navigate to the following:
META-INF-->com-->google-->android
4. Open update-script using notepad
5. crtl-f on each package-name searching through the file:
emailgoogle.apk
GenieWidget.apk
Mms.apk
Talk.apk
Twitter.apk
VoiceDialer.apk
(ugh.. I forgot I uninstalled all those)
they existed twice. Once to assert to make sure the file exists, and the second to apply the patch
You have to remove both, you can keep the progress bar command there, that's just to update the progress of your update on your screen
example
;assert(apply_patch_check("/system/app/Twitter.apk", "48dcef1792760138acb1c10e2a2341dfbee69258", "e3e34aa0a72d0eaf76d80a06828bd14ea8450d34"))
apply_patch("/system/app/Twitter.apk", "-",
48dcef1792760138acb1c10e2a2341dfbee69258, 1596937,
e3e34aa0a72d0eaf76d80a06828bd14ea8450d34, package_extract_file("patch/system/app/Twitter.apk.p"));
so after repeating this over and over, it finally updated
anyways, going to sleep
Unzip the file on your phone with eStrongs file manager.
Edit the update script (eStrongs again).
Rezip (eStrongs again).
Sign with ZipSigner, or toggle signature verification in recovery.
Flash.
Note, if you use the "flash zip from SD" option, you don't need to name the file "update.zip"
thanks danger-rat, seen your posts many times before, I saved lots of your comments in my evernote
I already knew about renaming update.zip, I just got into a dumb naming habit, the last 5 tries I just kept the name as it was
my root explorer (file manager) by speed software does what eStrongs does, I can edit, zip, tar, unmount folders, set permissions etc, maybe you should check it out
but i've learned two new things about your post
never heard of zipsigner, and eStrongs
thanks for showing the quicker way of doing this, the dropbox thing was a bit of a hassle, but I love editting this on my computer rather than my phone using the trackball touchpad combo :-|
I'm wondering why a solution wasn't even there when I was looking for answers around the web? I searched for hours too. I'm also glad I didn't brick my phone!
Yeah, I use Root Explorer a lot. I prefer the interface on eStrongs and love the LAN capabilities and Dropbox interface, but Root Explorer is much better when you need root permission.
Hi All
I'm running the stock Jelly Bean (4.1.2) on my Note which is rooted.
I changed the LCD density by editing the build.prop after reading changing it to 213 would make it like the Nexus 7 interface. However, I'm now in a boot loop.
I have a copy of the original build.prop but I can't adb push it to my Note because I get a permissino denied error. If I try to adb root it tells me I can't do it on production builds and remount tells me the operation is not permitted.
Any chance this can be sorted without me having to flash the ROM again?
thanks in advance
EDIT: I originally flashed the ROM with Mobile Odin Pro and injected root. I don't really want to flash the ROM again as I'd lose root. I have the backup build.prop on my hard drive and also on the external CD card in my Note. Can I use adb shell / su / mount to copy it over?
I dont know about adb, there is cwm flashable zip thought in which you can put the buildprop you want to flash.
Best to use romtoolbox for changing dpi, that one is pretty safe. if you have two entries in buildprop chsnge both to desired density.
baz77 said:
I dont know about adb, there is cwm flashable zip thought in which you can put the buildprop you want to flash.
Best to use romtoolbox for changing dpi, that one is pretty safe. if you have two entries in buildprop chsnge both to desired density.
Click to expand...
Click to collapse
Thanks for the info, but I' have stock recovery so wouldn't be able to flash that, would I?
Is another option making my own update.zip and having my restored build.prop in there?
then you are probably right with adb. Not sure if it requires root.
I know of no other way myself, cant help you there, short of what you said reflashing entire rom
download PhilZ Touch 3.0 Recovery and AROMA Filemanager and place it on external SD
CWM touch Philz http://forum.xda-developers.com/showthread.php?t=1927097
Aroma File manager
http://forum.xda-developers.com/showthread.php?t=1646108
Use this PhilZ Touch 3.0 Recovery to be flashed from stock recovery then flash the Aroma file manager. now you will have a recovery file manager. now replace the build.prop with the backed up one, fix permissions and reboot.
Good luck
Thanks Nokia, I'll have to remember that one
Oh well. i had done the mistake of changing the build.prop using root explorer and the phone never booted up.. so ...
I want to use the rom MaximusHD 52 but with some apps from MaximusHD 53, which has newer versions of the system apps
I have tried copying directly from the maximus53 zip some app, from system/priv-app/...and paste to my root folder in phone, then set permissions, and rebooted
It worked, the app is updated, but I have another 20 apps, and it´s tedious to make the process with each one
I want to make a zip to do it by flashing in twrp....Any help please?
(deleting everything in the original zip but the priv-app/* folders doesnt work, it gives fail at flash
Hey Folks!
I'm working on my newest Project called "Fluence HD Patch".
Basicly it will just add the content from my Fluence HD ROM to any excisting/flashed ROM, but now the Problem...
The Content which i add always to my ROMs forces a Bootloop after flashing as Stand alone. Included in a ROM there is no Problem. Changed the Updater Script a lot of times, but no success yet...
Hope anyone can help me!? This **** brakes my Neck!
Thanks in advance!
Did you edit it with something other than Notepad++
Miustone said:
Hey Folks!
I'm working on my newest Project called "Fluence HD Patch".
Basicly it will just add the content from my Fluence HD ROM to any excisting/flashed ROM, but now the Problem...
The Content which i add always to my ROMs forces a Bootloop after flashing as Stand alone. Included in a ROM there is no Problem. Changed the Updater Script a lot of times, but no success yet...
Hope anyone can help me!? This **** brakes my Neck!
Thanks in advance!
Click to expand...
Click to collapse
If experiencing a bootloop, does restoring the original build.prop and setting 0644 permissions through TWRP's File Manager allow the device to fully boot? If yes, then it must be an entry or a permissions issue. My next step in that case would be to flash the Fluence Patch to force the bootloop, boot to TWRP, mount System, set permissions to 0644 for the patched build.prop, and reboot. If the bootloop persists then there is certainly something inside causing it. Is there a single entry added that you didn't incorporate in one of your previous roms?
Also, the only other changes from flashing the patch is a build.prop backup and a tweak.prop on /sdcard, right? The next step in this scenario I would do after experiencing that second bootloop after ensuring the patched build.prop had 0644 permissions would be deleting both of those files that were added to /sdcard through TWRP's File Manager, assuming I had made my own copy of the original build.prop on /sdcard before the very first flash of the patch. If that doesn't allow the device to boot then there is something in the patched build.prop.
Edit*
After reading your Fluence Patch thread it is clear you are talking about the Full Patch causing the bootloop issue and not the one in the thread at the moment. I'll take a look if you want to send me a copy. The META-INF folder and any script(s) used during installation might be enough but not positive. :good:
ronaldheld said:
Did you edit it with something other than Notepad++
Click to expand...
Click to collapse
Nope, I'm using only Notepad++ ? The Zip flashs also successful...
guitardedhero said:
If experiencing a bootloop, does restoring the original build.prop and setting 0644 permissions through TWRP's File Manager allow the device to fully boot? If yes, then it must be an entry or a permissions issue. My next step in that case would be to flash the Fluence Patch to force the bootloop, boot to TWRP, mount System, set permissions to 0644 for the patched build.prop, and reboot. If the bootloop persists then there is certainly something inside causing it. Is there a single entry added that you didn't incorporate in one of your previous roms?
Also, the only other changes from flashing the patch is a build.prop backup and a tweak.prop on /sdcard, right? The next step in this scenario I would do after experiencing that second bootloop after ensuring the patched build.prop had 0644 permissions would be deleting both of those files that were added to /sdcard through TWRP's File Manager, assuming I had made my own copy of the original build.prop on /sdcard before the very first flash of the patch. If that doesn't allow the device to boot then there is something in the patched build.prop.
Edit*
After reading your Fluence Patch thread it is clear you are talking about the Full Patch causing the bootloop issue and not the one in the thread at the moment. I'll take a look if you want to send me a copy. The META-INF folder and any script(s) used during installation might be enough but not positive. :good:
Click to expand...
Click to collapse
Thanks for the Reply Man! As you suggested right in Your edit, the build.prop is just fine for now... I will upload the patch content after waking up completely... Was a hard night ?
Your help is much appreciated! Thanks again! :angel:
The custom rom I am using on my device for some reason doesn't have logcat. After a bit of digging up in the root folder, I found out that it was missing logd file which should be present under /system/bin and is necessary for logcat to work. Already tried to copy it from the official rom of my device (I extracted it from system.img) but pasting it manually (tried both a root explorer and adb) in /system/bin won't do anything as any changes made to /system/bin get reverted back automtically after reboot.
So I thought of a method about hooking Runtime.loadLibrary with xposed and redirecting it to logd on my internal storage when it's requested. Isn't that possible ?
Otherwise, do you suggest any other solution?
Do you think I should move the file with twrp if this doesn't work ? (I am avoiding the use of it because it's still unstable for my device and bootlooped a few times.).
Or should I edit the custom rom's system.img and repack it (I'm afraid if it's size changes my device won't boot)
I will be very grateful if someone helps me out
if you copy a file you must set right permissions and ownership