Related
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
bowtieduece said:
Ran across this thread in the evo section, seeing how we also have htc's flash lite. It made me hopeful of attaining root. Ive tried every card mentioned as being successful on three different systems:-(
http://forum.xda-developers.com/showthread.php?t=718889
Click to expand...
Click to collapse
Even though I didn't really think it would work, I gave it a shot anyway. Naturally, it was unsuccessful. The Eris take FOREVER to load that website, and it never triggers the shell script to ask for a reload, therefore permission is denied for the second part when you reboot with adb shell.
Interesting exploit, though. I wonder if there is some way to modify it for the Eris. Maybe you could contact the devs.
Really, nobody else is interested in this?
MyFixofAndroid said:
Yep that's what I expected. Yea there's gotta be someone here that can do the changes to the EVO files so they work with Eris, and upload the proper files to file sites and have us downloading in no time, so we can get root finally. Yes please anyone here up and willing
Click to expand...
Click to collapse
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
sickbox said:
Toastcfh used to do some work for the Eris someone may want to start there since he provided what looks to be a pretty main part of the EVO root.
Click to expand...
Click to collapse
Thanks for the tip. I sent him a PM. Will report back when I find something.
Anyone with an Eris can help out - rooted or unrooted.
I looked at those scripts last night - what seems like the necessary conditions for the beginning of the exploit (part1) are:
(1) there is a directory read/write/traversal permission security flaw in the data area for flash-lite;
(2) apparently, when flash-lite is running it must have root privilege at a moment when it performs a file "chmod" operation
So, an unprivileged user goes in, and makes a symlink (at the correct moment in time) in flash-lite's data area that points to a mtd partition - moments later, flash-lite "chmods" what it thinks is a file in it's data area, but instead, it is chmod'ing the target of a symlink - the normally protected mtd partition.
This allows use of flash_image to write whatever is wanted to that partition - even as an unprivileged user.
It should be easy enough for someone with Linux/Unix command line scripting experience to test to see if these conditions prevail on the Eris. You don't even need to be root - make your symlink point to something in /data/local if you are worried about something bad happening to a mtd partition. Chmod it initially to 600, and see if it get's changed by flash-lite when (and if) you drop the symlink into place.
I would do it, but I've got to go buy all the parts for ( & build) a new computer (no dev station as of last night ).
bftb0
bftb0 said:
Anyone with an Eris can help out - rooted or unrooted.
bftb0
Click to expand...
Click to collapse
Thank you for the detailed explanation. I'll have a look at the scripts, though it's more about learning new things for me, as this exceeds the current state of my unix knowledge. Hope others with more immediate knowledge of the subject will take a crack at it.
The shell script points to sharedobjects within /data/data/com.android.browser/flashlite, but sharedobjects, nor any folder for that matter, exists within that directory on the Eris. Is there a different place this could point; does the Eris have the same objects stored in a different location?
UPDATE: I'm searching my filesystem on my Eris right now to find it. I will report back later with results.
Also If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
MyFixofAndroid said:
Maybe the "sharedobjects" folder and other missing folders are really on the Eris, one of you should look for them. Use ASTRO or a different file manager and search most of the whole filesystem and see if you can find "sharedobjects" on your Erises.
In the meantime I'll try the same thing. Maybe there's a search engine for the file system of the Eris that you can get in the Android Market, that would do the trick. A file and/or folder search engine.
If we find a sharedobjects folder (and the right one) then we can point the script in the proper direction and have root very soon.
Click to expand...
Click to collapse
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
I checked on my other Eris which is rooted. It seems that these may be the directories that we are looking for. However I don't find anything in an app-cache directory.
# find / -name *flashlite
find / -name *flashlite
/data/data/com.android.browser/flashlite
find: /proc/851: No such file or directory
# find / -name com.android.browser
find / -name com.android.browser
/data/data/com.android.browser
Well this appears to be the deal breaker then. Because non-root users of Eris cannot access /data as non-root, they cannot see anything in app-cache, and therefore cannot root yet, at least with this particular method unless there's another way to do it.
We should think of a way to still exploit Flash Lite on Eris, but use a different folder/folders in the Part? scripts that they point to for the operations of the script. This may be possible to do, however, still unlikely to work, and it is still going to be hard at this point.
But does anyone want to give my modified EVO method but for Eris a try? One of you should, so that we can root this thing and get it over with.
jimbonj said:
From what I see (and this may just be my eris), the directory probably does exist but we can't touch it:
ls -l
...
drwxrwx--x system system 2010-04-15 02:23 data
...
No read or write permissions to the directory using adb or Astro.
I do have permissions for /sdcard/data on my Eris:
d---rwxr-x system sdcard_rw 2010-06-26 13:26 data
but it doesn't contain the referenced folders and I don't think the browser downloads temporary files to the SD card.
Click to expand...
Click to collapse
I dont think we would need read write permissions to begin with to use this root, if we had them to start we would be rooted
Because is he using a exploit in flash lite to write to a restricted folder, hes not just found a folder where the permissions aren't set correctly.
If flash lite can invoke admin access and we can exploit it there should be a way to root this.
I am going to the bar going to get some beers for my friends birthday, when I get home I am going to see if I can modify this into an eris root
Yeah JVWARD!
On your rooting effort, all the better, try modifying it for Eris and let all of us know if you succeed, hope you can, so we can get root too. Keep trying it with different changes until you get it to work.
Thanks.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
You are able to cd directly into /data/data/com.android.browser/ and then ls, so all hope may not be lost yet. The flashlite directory does not show up, I'm guessing because I haven't used my browser yet so I need to try and get to a flash site and see if it is created. I'm having some problems with the touch screen my leak Eris right now that I'm trying to fix right now if anyone else wants to give it a shot.
Click to expand...
Click to collapse
Yes sickbox, by all means, keep trying stuff, and finding that "flashlite" directory etc. till you get it to root. Hope your touchscreen returns to normal, and that you can create the directory that you mentioned in your previous post by using a flash site.
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
hey can someone with a rooted Eris using a an almost 100% stock Rom setup dump there file system and post it. Anyone using a highly customized Rom don't bother.
Sent from my Eris using Tapatalk
lostpilot28 said:
Hey guys, I know this is a tall order, but I want to help. Any chance you could do a "step by step" set of instructions, or at least copy & paste the Evo instructions with the appropriate changes to try this on the Eris? I'm still not rooted, and the SD card Timing root method isn't working for me. I'd like to try something different.
Click to expand...
Click to collapse
Link to the Evo instructions is in the OP. Currently working to see if it's possible on the Eris, so that's a no-go for now.
Stay tuned.
Team,
I've been working with the scripts with the awesome folks on IRC and have currently gotten thus far:
Part1 - http://pastebin.com/FUJWM3zW
Part2 - http://pastebin.com/6h07zrdm
I believe at this point I've screwed up my FlashLite plugin with my testing, so I'm going to try to recover that and keep moving along.
LR
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
I'd appreciate it if someone could give me some assistance. Basically the situation is that I wanted to get VPN working on the A7 which required tun.ko. I cross compiled the kernel and managed to get a tun.ko file and I added it to my device. Installing the module did not work, so I left it.
At some point my A7 shut off, and now it will not boot, it hangs at the ANDROID screen, before getting to the HC animation (dexmod 1.42). I am assuming at this point that my tun.ko is the issue so I created a patch update to remove the modules I had added to see if that would work.
Note: This patch is exactly the same as the ElocityMod 1.4.2 ad-hoc patch, I just changed the script actions and re-bundled.
The script only does this:
delete_recursive SYSTEM:lib/modules
delete SYSTEM:lib/tun.ko
I created the /system/lib/modules dir, so I know it exists, as does the /system/lib/tun.ko. When I try to run the update script I get the following error:
Installing Update
close from_child
E:Error in /sdcard/update.zip
(Status 6[1536])
Installation aborted.
I am trying not to flash back to the 1.4.2 as I have some investment and stupidly did not back-up before I started this venture. Any help would be appreciated.
Brad
As a side note, according to the /proc/config.gz on the tablet (kernel config) the TUN/TAP is compiled into the kernel, but not compiled as a module. For this reason I doubt VPN will work unless the apps can recognize the TUN device instead of failing because the module does not exist.
with specifics to an update script, the script desired should be as follows
Code:
run_program("/sbin/busybox", "mount", "-orw,remount","/system");
delete("/system/lib/tun.ko");
run_program("/sbin/busybox", "mount", "-oro,remount","/system");
you will need to remember to sign your update.zip after creation if you're not familiar with the process. searching on xda should turn up results for 'sign update.zip'.
i'd list the specific files and not do recursive deleting. though if introducing a kernel module caused you problems, i don't think it was merely copying/removing that had an effect, but wouldn't you have had to either issue an 'insmod' command manually or you added a call to that module using insmod added to the init.rc or a bash script. you need to remove that reference too if you did.
if your 'investment' is related to your /data folder (with your stored apps and app settings), you can use my cwm fakeflash recovery to backup and restore your /data contents (installed apps, and system settings) after a factory reset and reloading dexter's rom (using factory recovery).
alternative solutions; maybe if you were doing these kind of experiments you MIGHT have left the usb device setting on (for adb connectivity). if so, try to adb shell into the device to correct your problem by hand; type adb devices from a command prompt for fun to see if the device still lists (it did for me when softbricked once).
domito said:
I'd appreciate it if someone could give me some assistance. Basically the situation is that I wanted to get VPN working on the A7 which required tun.ko. I cross compiled the kernel and managed to get a tun.ko file and I added it to my device. Installing the module did not work, so I left it.
At some point my A7 shut off, and now it will not boot, it hangs at the ANDROID screen, before getting to the HC animation (dexmod 1.42). I am assuming at this point that my tun.ko is the issue so I created a patch update to remove the modules I had added to see if that would work.
Note: This patch is exactly the same as the ElocityMod 1.4.2 ad-hoc patch, I just changed the script actions and re-bundled.
The script only does this:
delete_recursive SYSTEM:lib/modules
delete SYSTEM:lib/tun.ko
I created the /system/lib/modules dir, so I know it exists, as does the /system/lib/tun.ko. When I try to run the update script I get the following error:
Installing Update
close from_child
E:Error in /sdcard/update.zip
(Status 6[1536])
Installation aborted.
I am trying not to flash back to the 1.4.2 as I have some investment and stupidly did not back-up before I started this venture. Any help would be appreciated.
Brad
As a side note, according to the /proc/config.gz on the tablet (kernel config) the TUN/TAP is compiled into the kernel, but not compiled as a module. For this reason I doubt VPN will work unless the apps can recognize the TUN device instead of failing because the module does not exist.
Click to expand...
Click to collapse
..alternatively alternatively i also did a update.zip of the latest factory rom that may assist with your issue, if the above solutions do not work. assuming your 'investment' isn't in the /system folder, it can format your /system folder and reinstall the /system files from the factory firmware with all correct permissions. a little examination of my update.zip could be used as a template for creating a similar one for dexter's rom, for these particular times when you'd like to re-do your /system folder and leave the rest of your partitions and data intact.
locatable, roundabout, from my twitter. same name as here.
oh. you could just write a script to execute a bash script (file.sh) thats got simple copy commands to copy your 'investment' to sdcard (/sdcard in recovery). that might be the simplest non creative approach that would allow you to continue on with a normal factory reset and reload of dexter's rom.
using bash scripts might also aid you in doing what you want without having to know or experiment with proper scripting syntax.
..oh, AND you could just edit dexter's rom update.zip to only install the system.img, and remove the rest of the files for installation, and DON"T do a factory reset..
that could help with restoring your system filesystem while leaving the rest of your data intact. didn't occur until this morning, that might be you EASIEST of the multiple suggestions listed.
Thanks for the response!
bestialbub said:
with specifics to an update script, the script desired should be as follows
Code:
run_program("/sbin/busybox", "mount", "-orw,remount","/system");
delete("/system/lib/tun.ko");
run_program("/sbin/busybox", "mount", "-oro,remount","/system");
Click to expand...
Click to collapse
This was actually what I did for my first try, with the same result.
bestialbub said:
you will need to remember to sign your update.zip after creation if you're not familiar with the process. searching on xda should turn up results for 'sign update.zip'.
Click to expand...
Click to collapse
I did not do this, I was not sure I had to.
bestialbub said:
i'd list the specific files and not do recursive deleting. though if introducing a kernel module caused you problems, i don't think it was merely copying/removing that had an effect, but wouldn't you have had to either issue an 'insmod' command manually or you added a call to that module using insmod added to the init.rc or a bash script. you need to remove that reference too if you did.
Click to expand...
Click to collapse
I did insmod it as well as modprobe, it gave me an error which was likely because (as I found later) the TUN is compiled into the kernel, which means a module could not possibly load.
bestialbub said:
if your 'investment' is related to your /data folder (with your stored apps and app settings), you can use my cwm fakeflash recovery to backup and restore your /data contents (installed apps, and system settings) after a factory reset and reloading dexter's rom (using factory recovery).
Click to expand...
Click to collapse
I'll have to take a look at that, I was no aware it existed.
bestialbub said:
alternative solutions; maybe if you were doing these kind of experiments you MIGHT have left the usb device setting on (for adb connectivity). if so, try to adb shell into the device to correct your problem by hand; type adb devices from a command prompt for fun to see if the device still lists (it did for me when softbricked once).
Click to expand...
Click to collapse
The issue with the A7 is that it's got USB host only which means I cannot connect it to my PC and adb it. This was a known issue before I bought the A7.
bestialbub said:
..alternatively alternatively i also did a update.zip of the latest factory rom that may assist with your issue, if the above solutions do not work. assuming your 'investment' isn't in the /system folder, it can format your /system folder and reinstall the /system files from the factory firmware with all correct permissions. a little examination of my update.zip could be used as a template for creating a similar one for dexter's rom, for these particular times when you'd like to re-do your /system folder and leave the rest of your partitions and data intact.
locatable, roundabout, from my twitter. same name as here.
oh. you could just write a script to execute a bash script (file.sh) thats got simple copy commands to copy your 'investment' to sdcard (/sdcard in recovery). that might be the simplest non creative approach that would allow you to continue on with a normal factory reset and reload of dexter's rom.
using bash scripts might also aid you in doing what you want without having to know or experiment with proper scripting syntax.
..oh, AND you could just edit dexter's rom update.zip to only install the system.img, and remove the rest of the files for installation, and DON"T do a factory reset..
that could help with restoring your system filesystem while leaving the rest of your data intact. didn't occur until this morning, that might be you EASIEST of the multiple suggestions listed.
Click to expand...
Click to collapse
In the end I went more heavy handed than all that and it worked out fine. I did this before I saw your response otherwise I would have tried to finesse it some more just for the fun of it.
I re-flashed with dexmod 1.41 but I did not reset or wipe anything first. Applying this over top got me booted again with all my apps. 1 quick 1.42 update (and annoying root FB upgrade) and I am back to pre-fail conditions. I backed up my stuff too.
Thanks again for all the useful tips. This type of event has happened a few times and my gut says I am getting some corruption on the NVRAM or something. Only time will tell.
adb connectivity works fine, the solution is buried in one of 5stronginos threads, maybe the cwm recovery one. google for USB_OTG.APK i think, its posted on xda w a download link.
..i also prepackage it in my firmware repack.. findable from my twitter.
Sent from my X10i using Tapatalk
bestialbub said:
adb connectivity works fine, the solution is buried in one of 5stronginos threads, maybe the cwm recovery one. google for USB_OTG.APK i think, its posted on xda w a download link.
..i also prepackage it in my firmware repack.. findable from my twitter.
Sent from my X10i using Tapatalk
Click to expand...
Click to collapse
I found this one, which looks right.
http://forum.xda-developers.com/showpost.php?p=12813894&postcount=36
I'll give it a shot. Thanks for the info.
DISCLAIMER: YOU AGREE TO TAKE FULL RESPONSIBILITY FOR YOUR DEVICE IF YOU PROCEED.
The original thread (http://forum.xda-developers.com/moto-g/general/mod-save-data-space-cache-partition-t2942765) was getting to cluttered up with development and testing so I decided to start a new thread with the "finished" product. The original thread will be renamed to Q&A/Development. We might even ask for the old thread to be closed down. (up to @Bert98, the thread's creator.)
Moto G's internal eMMC card has a ~600Mb partition called /cache, which is not used since the apps' cache is stored in /data, so the latter fills up and the first one stays empty.
Owning a 8Gb model, having 600Mb not available for storage really bugged me, because my phone's memory (/data partition) was always full because it's a 5.7Gb space shared between apps and microSD files.
Now, it may not work for you if:
a) you have A LOT of apps installed.
And by "a lot", I mean more than 90-100 apps, but if you have a 8Gb model, you probably don't
b) you're running ART (this is default in lollipop and newer)
Since ART uses a lot more space than dalvik, the space in the /cache partition probably won't be enough. When I was running ART, it used 1Gb more than dalvik.
Original post by @Bert98
Click to expand...
Click to collapse
This was tested on my moto g 16GB which is running RetailUS_4.4.4 kitkat with CWM recovery. The custom ROM procedure was tested on the same phone but with cm11 Nightly installed.
Prerequisites:
1. You must have "adb root" functioning. If you don't head to this thread: http://forum.xda-developers.com/showthread.php?t=1687590 and there is a free download link at the bottom of the post.
Download and install the apk on your phone. Open up adbd insecure (the new app) and grant it superuser rights PERMANENTLY. Check the box that says "enable insecure binary" and make sure to check the box
that says "enable at boot."
2. You must have a recovery that can accept adb shell commands.
3. Root Access Duh?!
4. A windows machine capable of running batch files.
5. A decent text editor, notepad will work but notepad++ is strongly recommended. (Only needed if you are using STOCK ROM procedure)
Please, please make a nandroid backup before you continue!!!!
Stock ROM procedure:
Read the directions very carefully and then read them again, before continuing.
1. Download the cachemover_v1.3.zip from: LINK REMOVED DUE TO SCRIPT ISSUES.
2. Extract the contents.
3. Connect device to PC and navigate to the extracted folder.
4. Double click/Run the cachemover_Stock.bat
5. Follow the onscreen instructions until you get to the part where it says to edit a file.
6. About halfway through the script it will pull a file called "init.qcom.post_boot.sh" to the folder.
7. Open it with a TEXT editor and navigate to about line 487 (Might be different for 8gb model). Look here for a better understanding: https://www.dropbox.com/s/jr5lyl5s5i2jtpg/where to paste code.PNG?dl=0
8. Start a new line and paste this code in the file: (Refer to the image above for help)
Code:
chmod 655 /cache
chmod 655 /cache/dalvik-cache
chmod 655 /cache/dalvik-cache/*
9. Make sure to save the file in the same folder as the cachemover_Stock.bat
10. Press any key to continue on the script and let it do its thing.
11. It will reboot several times and land you on the home screen/lock screen.
12. If the script hangs after a reboot, you need to unlock the device to reestablish a connection with your computer.
13. There might be one or two force closes but once you close the notifications they will not come back.
Custom ROM procedure:
USE THIS FOR ROMS THAT DO NOT REMOUNT OR CHANGE PERMISSIONS OF /CACHE ON BOOT
1. Download the cachemover_v1.3.zip from: https://www.dropbox.com/s/bzj34g4q1s61ojz/cachemover_v1.3.zip?dl=0
2. Extract the contents.
3. Connect device to PC and navigate to the extracted folder.
4. Double click/Run the cachemover.bat
5. Follow the onscreen instructions.
If anything goes wrong:
Go to recovery, wipe cache, then wipe dalvik-cache and reboot. This should get your device back to how it was.
(If you used STOCK ROM procedure)
The script made a backup of the "init.qcom.post_boot.sh" file to /sdcard/init_backup
You can restore the shell script to /system/etc/ via shell commands or by using a root browser. To restore permissions:
Code:
chmod 740 /system/etc/init.qcom.post_boot.sh
chown root:root /system/etc/init.qcom.post_boot.sh
Custom ROM procedure already has a restore script!
I am currently working on an auto restore script for stock and that will be relased soon, hopefully! :good:
Changelog:
v1.0 - First stable release. Does not work on STOCK ROM.
v1.1 - Added a restore script.
v1.3 - Added support for STOCK ROM. There are still a few bugs.
How it works?!?!
Coming soon...
Huge thanks to @Bert98 and @dd043
Hit the thanks button if it worked! I went through about 50 factory resets, and reflashed the ROM about 25 times, and put about 10 hours of work into this script! Really motivates me for future projects. :laugh:
Thanks for your help man and effort.
I encountered a problem, everything works up until my device boots in CWM to fix permissions, then just sits there doing not alot I don't even see the option in my CWM.
Any ideas? cheers
Sent from my XT1032 using XDA Free mobile app
When it reboots to cwm unplug the cable and replug it, if it hangs just type these commands manually from a command window.
chmod 655 /cache
chmod 655 /cache/dalvik-cache
chmod 655 /cache/dalvik-cache/*
reboot
If this does not work you may ned to go into mounts & storage in the cwm menu and click mount /cache. Then try the commands again.
I'm having some issues on stock.
I thought 0655 fixed everything but no, I can't install any app after moving the dalvik-cache to /cache. I tried chmoding 0777 on the new cache folder, on /cache itself, to no avail.
Code:
E/dexopt cannot open '/data/dalvik-cache/[email protected]' for output
Anyone can confirm it's not only my device? And/or can help find a fix?
Also does someone knows how to execute commands on a particular init step? Real init.rc scripts can do:
Code:
on post-fs-data
mount -o bind /cache/dalvik /data/dalvik-cache
It there was a way to achieve the same from post_boot/init.d we could mount -o bind /cache/dalvik /data/dalvik-cache and all permissions issues would disappear as well as the need for symlink.
You have a typo in the threads title. Just a heads up.
Vuciz said:
You have a typo in the threads title. Just a heads up.
Click to expand...
Click to collapse
Thanks for letting me know!
dd043 said:
I'm having some issues on stock.
I thought 0655 fixed everything but no, I can't install any app after moving the dalvik-cache to /cache. I tried chmoding 0777 on the new cache folder, on /cache itself, to no avail.
Code:
E/dexopt cannot open '/data/dalvik-cache/[email protected]' for output
Anyone can confirm it's not only my device? And/or can help find a fix?
Also does someone knows how to execute commands on a particular init step? Real init.rc scripts can do:
Code:
on post-fs-data
mount -o bind /cache/dalvik /data/dalvik-cache
It there was a way to achieve the same from post_boot/init.d we could mount -o bind /cache/dalvik /data/dalvik-cache and all permissions issues would disappear as well as the need for symlink.
Click to expand...
Click to collapse
Let me try and do that right now... Ill get back to you if it does!
My script works on stock btw... But the mount way seems a bit easier and might cause less errors than my way.
Try it please.
skyguy126 said:
Let me try and do that right now... Ill get back to you if it does!
My script works on stock btw... But the mount way seems a bit easier and might cause less errors than my way.
Try it please.
Click to expand...
Click to collapse
Yes I've tried your script, all went well but the result is the same. The script itself works nicely btw
Applications present before moving cache work perfectly, but I can't install anything new. I suspect it might be my device but before wiping everything I'd prefer feedback from others :fingers-crossed:.
I cannot install new apps as well. The mount command you showed me has the same effect too. I honestly don't know anymore, the sym link did not allow the install of new apps nor did the mount command you sent me. Correct me if I am wrong.
Edit: Going through all the init files on my phone to see which one remounts /cache at boot.
Why does the init.rc get overwritten at boot. Is it because the kernel (boot.img) is the one that copies it over? I have found by changing the perms/locations in this file and init.target.rc you can achieve what this mod is trying to acomplish.
I don't see the mount cache command in CWM strange
I've managed to get back to normal, thanks for everyone's help though, I will keep and eye on the thread
Sent from my XT1032 using XDA Free mobile app
non-windows version?
Thanks for this tool. It's a great idea and our Motos really need it.
However, I have a problem - I do not own a windows license (os x and ubuntu user) and I would prefer not to spend $120 just to use it for this script. Pirating is out of the question for me.
I was wondering if there is any chance of having this script written for linux and/or mac. If impossible, is there a LEGAL way of running windows in a virtual machine? Something like a trial or similar?
If you know how just convert it to shell script for osx and Linux. I give you permission to do this but you may not take credit or rehost your creation.
Ok so I have the kernel extracted and we could modify and flash that, but I believe that it's not really necessary. There are a lot of risks to flashing kernels and I am not willing to take it. So is there a way we can modify dalvik so it creates it's cache in /cache instead.
skyguy126 said:
Why does the init.rc get overwritten at boot. Is it because the kernel (boot.img) is the one that copies it over? I have found by changing the perms/locations in this file and init.target.rc you can achieve what this mod is trying to acomplish.
Click to expand...
Click to collapse
Yes the init.rc is in the boot ramdisk. I don't think it would be worth the trouble to rebuild a boot.img. The moto g is fairly unbrickable but it's quite a lot of work to setup an environment to rebuild an image :/.
Too bad for the mount command, I was sure it was working but maybe I had changed something else and don't quite remember the steps to reproduce
We could possibly implement a shell script toggler for when we need to install new apps, but I'm afraid it'd become annoying fairly quickly: I noticed the issue initially because google play services decided to update itself, failed, and broke all google apps. As far as I know this autoupate can't be disabled.
Thanks for trying!
dd043 said:
Yes the init.rc is in the boot ramdisk. I don't think it would be worth the trouble to rebuild a boot.img. The moto g is fairly unbrickable but it's quite a lot of work to setup an environment to rebuild an image :/.
Too bad for the mount command, I was sure it was working but maybe I had changed something else and don't quite remember the steps to reproduce
We could possibly implement a shell script toggler for when we need to install new apps, but I'm afraid it'd become annoying fairly quickly: I noticed the issue initially because google play services decided to update itself, failed, and broke all google apps. As far as I know this autoupate can't be disabled.
Thanks for trying!
Click to expand...
Click to collapse
How about making a simple apk that toggles this feature. Something like when you click the icon it doesn't even open but gives a little notification of success. Something like that. I myself am not experienced with apks but I can put together a shell script for the apk.
skyguy126 said:
Ok so I have the kernel extracted and we could modify and flash that, but I believe that it's not really necessary. There are a lot of risks to flashing kernels and I am not willing to take it. So is there a way we can modify dalvik so it creates it's cache in /cache instead.
Click to expand...
Click to collapse
Patching dalvik itself sounds promising. It can probably be done with in a batch script with a command line hex editor.
The path is defined in frameworks/base/cmds/installd/installd.h
Code:
#define DALVIK_CACHE_PREFIX "/data/dalvik-cache/"
Not sure if there is another mention in the source tree.
But there's nothing to say we wouldn't face the same issue, the error message in the logcat is pretty generic
dd043 said:
Patching dalvik itself sounds promising. It can probably be done with in a batch script with a command line hex editor.
The path is defined in frameworks/base/cmds/installd/installd.h
Code:
#define DALVIK_CACHE_PREFIX "/data/dalvik-cache/"
Not sure if there is another mention in the source tree.
But there's nothing to say we wouldn't face the same issue, the error message in the logcat is pretty generic
Click to expand...
Click to collapse
Ill try it. I don't mind doing a bunch of resets because I am using my moto g as a test bench anyway. My daily driver is the OnePlus One
dd043 said:
Patching dalvik itself sounds promising. It can probably be done with in a batch script with a command line hex editor.
The path is defined in frameworks/base/cmds/installd/installd.h
Code:
#define DALVIK_CACHE_PREFIX "/data/dalvik-cache/"
Not sure if there is another mention in the source tree.
But there's nothing to say we wouldn't face the same issue, the error message in the logcat is pretty generic
Click to expand...
Click to collapse
EDIT: Unfortunately it didn't work. I don't know if I modified the installd file correctly. The program I used is HxD.
Is there a way we can force dalvik to start after the directories are created. And change dalvik to create it in /cache.
tl;dr: I tried to hack the SystemUI.apk file to get rid of the s-finder notification bar, I needed to deodex the apk to do this. I did that (first time ever), but then I didn't know what to do with the .odex.art.xz file, so I removed the whole arm/ folder from the SystemUI directory, and just left my modified SystemUI.apk file in there. After clearing the cache and dalvik, the SystemUI app kept crashing and I had to restore from backup. What do I do with the arm directory, and is that even the problem, or should I not even try to do this?
I have a sprint Galaxy S4 (jfltespr; SPH-L720) that I just upgraded to lollipop via the regular system update, now have Android 5.0.1, baseband L720VPUGOD2, kernel 3.4.0. My phone is rooted with BusyBox installed. I used to use CyanogenMod (for a long time), but the stability was low for me, particularly when travelling internationally and changing SIMs: I would frequently lose GPS completely (see http://forum.xda-developers.com/galaxy-s4-sprint/help/gps-cyanogen-mod-install-t3009245/), requiring me to flash the stock ROM again. So I reverted to stock, and used xposed. Unfortunately, following the upgrade to 5.0.1, xposed now requires flashing a zip and is in super-alpha, and so I am nervous about using it. The only thing I really want a custom ROM or xposed for is to get rid of bloat. I have managed with just Titanium to get rid of the most annoying apps, but I am still stuck with that stupid 'S-Finder'/'Quick Connect' bar. I can get rid of it by switching my device name to jfltevzr or jflteatt in build.prop, but then I lose other features, such as the ability to change to the GSM network.
So, I tried to hack the SystemUI apk according to the instructions here and here. Essentially my plan was: download SystemUI.apk, edit the PhoneStarusBar.smali, and profit.
I have never done this before, so I rapidly ran into the issue that I needed to deodex the apk. I followed this guide and everything seemed to go smoothly, except that the PhoneStatuBar.smali file had different code from the tutorial. In the tutorial I had to change
Code:
if-nez v8, ;cond_0
to
Code:
if-nex v8, :cond_5
but in my file it seemed that the syntax was similar, but the labels were different, so I ended up changing
Code:
if-nez v8, ;cond_15
to
Code:
if-nex v8, :cond_c0
I created the classes.dex file and packaged it into the apk with the command
Code:
7za u -tzip SemcVideo.apk classes.dex
However, I was confused about what to do with the new apk. In my system, the original apk lives in /system/priv-app/SystemUI/SystemUI.apk, and next to the apk is an arm directory with an odex.xz file (which I deodexed) and an art.odex.xz file that I have no idea what to do with. Since I didn't know what to do, I just deleted the whole arm directory, put the modified (deodexed) SystemUI.apk file in /system/priv-app/SystemUI/, cleared the cache and dalvik cache, and rebooted. After about 20 minutes of rebuilding the cache for all of my apps, the phone started, but it had the dreaded 'SystemUI is not responding, do you want to restart it' message. I ended up having to restore a backup and wipe the cache again.
So, my question is: what do I do with that arm directory? Is that what broke it, or is the problem that I just screwed up the PhoneStatusBar.smali file? I don't really know what I am doing as I don't know java that well, but I would like to get this to work.
Alternatively, do you guys think that maybe the Google Play Edition ROM might be more stable that CyanogenMod, or that I should just try to flash to xposed alpha even though it is so 'unstable'? It looks to me like the GPE ROM might be more stable than CM, but I have no idea. I know that it hasn't been patched for StageFright yet, even though CM has.
Finally, I should specify that I am not an Android hacker, I have a full time job in science research and I volunteer a lot. My top priority for my phone is stability and reliability, and I don't want to spend too many hours on this. Secondary concerns for me are not having to deal with all of Samsung's bloatware and increasing my battery life.
Thanks in advance for all of your help, and apologies if I am posting in the wrong place.
MikeDacre said:
tl;dr: I tried to hack the SystemUI.apk file to get rid of the s-finder notification bar, I needed to deodex the apk to do this. I did that (first time ever), but then I didn't know what to do with the .odex.art.xz file, so I removed the whole arm/ folder from the SystemUI directory, and just left my modified SystemUI.apk file in there. After clearing the cache and dalvik, the SystemUI app kept crashing and I had to restore from backup. What do I do with the arm directory, and is that even the problem, or should I not even try to do this?
I have a sprint Galaxy S4 (jfltespr; SPH-L720) that I just upgraded to lollipop via the regular system update, now have Android 5.0.1, baseband L720VPUGOD2, kernel 3.4.0. My phone is rooted with BusyBox installed. I used to use CyanogenMod (for a long time), but the stability was low for me, particularly when travelling internationally and changing SIMs: I would frequently lose GPS completely (see http://forum.xda-developers.com/galaxy-s4-sprint/help/gps-cyanogen-mod-install-t3009245/), requiring me to flash the stock ROM again. So I reverted to stock, and used xposed. Unfortunately, following the upgrade to 5.0.1, xposed now requires flashing a zip and is in super-alpha, and so I am nervous about using it. The only thing I really want a custom ROM or xposed for is to get rid of bloat. I have managed with just Titanium to get rid of the most annoying apps, but I am still stuck with that stupid 'S-Finder'/'Quick Connect' bar. I can get rid of it by switching my device name to jfltevzr or jflteatt in build.prop, but then I lose other features, such as the ability to change to the GSM network.
So, I tried to hack the SystemUI apk according to the instructions here and here. Essentially my plan was: download SystemUI.apk, edit the PhoneStarusBar.smali, and profit.
I have never done this before, so I rapidly ran into the issue that I needed to deodex the apk. I followed this guide and everything seemed to go smoothly, except that the PhoneStatuBar.smali file had different code from the tutorial. In the tutorial I had to change
Code:
if-nez v8, ;cond_0
to
Code:
if-nex v8, :cond_5
but in my file it seemed that the syntax was similar, but the labels were different, so I ended up changing
Code:
if-nez v8, ;cond_15
to
Code:
if-nex v8, :cond_c0
I created the classes.dex file and packaged it into the apk with the command
Code:
7za u -tzip SemcVideo.apk classes.dex
However, I was confused about what to do with the new apk. In my system, the original apk lives in /system/priv-app/SystemUI/SystemUI.apk, and next to the apk is an arm directory with an odex.xz file (which I deodexed) and an art.odex.xz file that I have no idea what to do with. Since I didn't know what to do, I just deleted the whole arm directory, put the modified (deodexed) SystemUI.apk file in /system/priv-app/SystemUI/, cleared the cache and dalvik cache, and rebooted. After about 20 minutes of rebuilding the cache for all of my apps, the phone started, but it had the dreaded 'SystemUI is not responding, do you want to restart it' message. I ended up having to restore a backup and wipe the cache again.
So, my question is: what do I do with that arm directory? Is that what broke it, or is the problem that I just screwed up the PhoneStatusBar.smali file? I don't really know what I am doing as I don't know java that well, but I would like to get this to work.
Alternatively, do you guys think that maybe the Google Play Edition ROM might be more stable that CyanogenMod, or that I should just try to flash to xposed alpha even though it is so 'unstable'? It looks to me like the GPE ROM might be more stable than CM, but I have no idea. I know that it hasn't been patched for StageFright yet, even though CM has.
Finally, I should specify that I am not an Android hacker, I have a full time job in science research and I volunteer a lot. My top priority for my phone is stability and reliability, and I don't want to spend too many hours on this. Secondary concerns for me are not having to deal with all of Samsung's bloatware and increasing my battery life.
Thanks in advance for all of your help, and apologies if I am posting in the wrong place.
Click to expand...
Click to collapse
Just go into res/values/dimens.xml once you have it decompiled and change every line with SFinder or QuickConnect to "0.0dip" using Notepad++ then recompile the apk and remove the SF and QC apks... It's a lot easier that way. Xposed works fine but you have to use the Samsung specific one. There is a link in my Wicked X thread.
{
"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"
}
bilgerryan said:
Just go into res/values/dimens.xml once you have it decompiled and change every line with SFinder or QuickConnect to "0.0dip" using Notepad++ then recompile the apk and remove the SF and QC apks... It's a lot easier that way. Xposed works fine but you have to use the Samsung specific one. There is a link in my Wicked X thread.
Click to expand...
Click to collapse
Thanks so much bilgerryan, I am doing that now. I have another dumb question: what is the best way to copy back the new apk? Is it fine for me to use adb to do it from the recovery? I would just delete the original (after backing up) and then copy my modified version in.
Also, (sorry for the multi-post), do I need to wipe both the Cache and the Dalvik Cache partitions after making the switch?
MikeDacre said:
Thanks so much bilgerryan, I am doing that now. I have another dumb question: what is the best way to copy back the new apk? Is it fine for me to use adb to do it from the recovery? I would just delete the original (after backing up) and then copy my modified version in.
Click to expand...
Click to collapse
You have to set permissions to 0644 after you copy it over.. I use root browser. Long press on the file, press Permissions and then make it look like the screenshot. Or you can just use my ROM (second screenshot), it is already removed plus a bunch of other fun stuff... Wicked X v10.6 in Android Development section.
bilgerryan said:
You have to set permissions to 0644 after you copy it over.. I use root browser. Long press on the file, press Permissions and then make it look like the screenshot. Or you can just use my ROM (second screenshot), it is already removed plus a bunch of other fun stuff... Wicked X v10.6 in Android Development section.
Click to expand...
Click to collapse
Great, thanks. I will give your ROM a try in the future, but right now I want to figure out how to do this I just tried it copying back my modified apk and wiping the cache and dalvik, but after it booted, there was no systemui
I just changed the permissions to 644 now, they were 777 before, so that may have been the problem.
Do I need to wipe the cache and dalvik every time? It takes a really long time to boot after that.
Thanks again!
MikeDacre said:
Great, thanks. I will give your ROM a try in the future, but right now I want to figure out how to do this I just tried it copying back my modified apk and wiping the cache and dalvik, but after it booted, there was no systemui
I just changed the permissions to 644 now, they were 777 before, so that may have been the problem.
Do I need to wipe the cache and dalvik every time? It takes a really long time to boot after that.
Thanks again!
Click to expand...
Click to collapse
No, you only need to do that when completely removing a system app. A record is enough. I haven't worked with odex in a long time, I can't remember if there is anything extra you need to do.
bilgerryan said:
No, you only need to do that when completely removing a system app. A record is enough. I haven't worked with odex in a long time, I can't remember if there is anything extra you need to do.
Click to expand...
Click to collapse
OK, unfortunately after making the changes, there is no SystemUI; all I have is my launcher (SmartLauncher) with a black background and no notification bar. After restarting I have the same issue. By putting back the old SystemUI.apk I fix the problem.
Here is what I tried:
Copy the SystemUI.apk file from /system/priv-app/SystemUI/SystemUI.apk
Copy the frameworks from /system/frameworks/twframework-res.apk and /system/framework/framework-res.apk
Install all frameworks:
Code:
apktool if framework-res.apk
apktool if twframework-res.apk
apktool if SystemUI.apk
Decompile the apk:
Code:
apktool d SystemUI.apk
Edit res/values/dimens.xml with vim. Here is the patch of my edits:
Code:
--- /tmp/vqMxlsi/3 2015-08-19 18:23:07.346653666 -0700
+++ /tmp/vqMxlsi/4 2015-08-19 18:23:07.369986999 -0700
@@ -832,8 +832,8 @@
<dimen name="finder_connect_button_padding_top">11.0dip</dimen>
<dimen name="finder_connect_button_height">35.0dip</dimen>
<dimen name="finder_connect_layout_height">57.0dip</dimen>
- <dimen name="tw_quick_panel_sfinder_qconnect_button_text_size">16.0dip</dimen>
- <dimen name="tw_quick_panel_sfinder_qconnect_drawable_padding">5.0dip</dimen>
+ <dimen name="tw_quick_panel_sfinder_qconnect_button_text_size">0.0dip</dimen>
+ <dimen name="tw_quick_panel_sfinder_qconnect_drawable_padding">0.0dip</dimen>
<dimen name="notificatoin_big_picture_height">176.0dip</dimen>
<dimen name="rssi_battery_gap">3.0dip</dimen>
<dimen name="battery_icon_width">10.0dip</dimen>
Recompile the apk:
Code:
apktool b SystemUI
Zipalign the apk:
Code:
zipalign -v 4 SystemUI/dist/SystemUI.apk final/SystemUI.apk
Copy the new apk to my external sd
Connect with adb and do the following:
Code:
mount -o remount,rw /system
cd /system/priv-app/SystemUI
cp SystemUI.apk /storage/extSdCard/Backup/SystemUI.apk
rm SystemUI.apk
cp /storage/extSdCare/SystemUI.apk .
chmod 644 SystemUI.apk
reboot
Is there something else I am missing? It seems that after my edits, SystemUI.apk just doesn't launch at all. There isn't even an error message. But all I changed are those two lines. The problem is the same with or without the zipalign step. Doing essentially the same procedure above to restore the old SystemUI.apk brings everything back to normal, so I don't think it is a permissions issue. Wiping the cache and dalvik and restarting makes no difference, I have the same problem. Restarting a couple of times also does not resolve the problem.
Any ideas?
MikeDacre said:
OK, unfortunately after making the changes, there is no SystemUI; all I have is my launcher (SmartLauncher) with a black background and no notification bar. After restarting I have the same issue. By putting back the old SystemUI.apk I fix the problem.
Here is what I tried:
Copy the SystemUI.apk file from /system/priv-app/SystemUI/SystemUI.apk
Copy the frameworks from /system/frameworks/twframework-res.apk and /system/framework/framework-res.apk
Install all frameworks:
Code:
apktool if framework-res.apk
apktool if twframework-res.apk
apktool if SystemUI.apk
Decompile the apk:
Code:
apktool d SystemUI.apk
Edit res/values/dimens.xml with vim. Here is the patch of my edits:
Code:
--- /tmp/vqMxlsi/3 2015-08-19 18:23:07.346653666 -0700
+++ /tmp/vqMxlsi/4 2015-08-19 18:23:07.369986999 -0700
@@ -832,8 +832,8 @@
<dimen name="finder_connect_button_padding_top">11.0dip</dimen>
<dimen name="finder_connect_button_height">35.0dip</dimen>
<dimen name="finder_connect_layout_height">57.0dip</dimen>
- <dimen name="tw_quick_panel_sfinder_qconnect_button_text_size">16.0dip</dimen>
- <dimen name="tw_quick_panel_sfinder_qconnect_drawable_padding">5.0dip</dimen>
+ <dimen name="tw_quick_panel_sfinder_qconnect_button_text_size">0.0dip</dimen>
+ <dimen name="tw_quick_panel_sfinder_qconnect_drawable_padding">0.0dip</dimen>
<dimen name="notificatoin_big_picture_height">176.0dip</dimen>
<dimen name="rssi_battery_gap">3.0dip</dimen>
<dimen name="battery_icon_width">10.0dip</dimen>
Recompile the apk:
Code:
apktool b SystemUI
Zipalign the apk:
Code:
zipalign -v 4 SystemUI/dist/SystemUI.apk final/SystemUI.apk
Copy the new apk to my external sd
Connect with adb and do the following:
Code:
mount -o remount,rw /system
cd /system/priv-app/SystemUI
cp SystemUI.apk /storage/extSdCard/Backup/SystemUI.apk
rm SystemUI.apk
cp /storage/extSdCare/SystemUI.apk .
chmod 644 SystemUI.apk
reboot
Is there something else I am missing? It seems that after my edits, SystemUI.apk just doesn't launch at all. There isn't even an error message. But all I changed are those two lines. The problem is the same with or without the zipalign step. Doing essentially the same procedure above to restore the old SystemUI.apk brings everything back to normal, so I don't think it is a permissions issue. Wiping the cache and dalvik and restarting makes no difference, I have the same problem. Restarting a couple of times also does not resolve the problem.
Any ideas?
Click to expand...
Click to collapse
It's because it's odexed. That is why almost every ROM you see is deodexed except stock ROMs.
bilgerryan said:
It's because it's odexed. That is why almost every ROM you see is deodexed except stock ROMs.
Click to expand...
Click to collapse
Do you think it is possible for me to deodex it? I did that before after editing the smali as described above, but I didn't know what to do with the arm/ directory and so I just deleted it, and that didn't work (Got a SystemUI has crashed message).
MikeDacre said:
Do you think it is possible for me to deodex it? I did that before after editing the smali as described above, but I didn't know what to do with the arm/ directory and so I just deleted it, and that didn't work (Got a SystemUI has crashed message).
Click to expand...
Click to collapse
You would have to deodex the entire ROM.
bilgerryan said:
You would have to deodex the entire ROM.
Click to expand...
Click to collapse
Ah! I understand. Sorry for all of these super basic beginner questions. OK, so I am thinking about deodexing the system ROM now, I realize that I could just install an already made custom ROM, but I would like to try this.
As this is my first time trying this, could you clarify if this will work:
Download this tool: http://androidforums.com/threads/tool-linux-batch-lollipop-deodex-v1-9-8-9-15.931146/
Copy /system/app, /system/priv-app, and /system/framework to my computer
Run the 'deodex_lollipop' tool
Create a very simple flashable zip using the sample here: http://www.droidviews.com/create-flashable-zips-cwmtwrp-recovery/ with the contents of the deodexed /system folder I just created
Flash that in TWRP
Then make the edits I mentioned above to the SystemUI.apk
Will that work? Or is it likely to be very difficult?
If it does work, are there downsides to doing it? Not getting future updates, running slower, etc, or should it be basically the same as before except with the s-finder toolbar gone?
Thanks so much for all of your help, this is really great. :good:
MikeDacre said:
Ah! I understand. Sorry for all of these super basic beginner questions. OK, so I am thinking about deodexing the system ROM now, I realize that I could just install an already made custom ROM, but I would like to try this.
As this is my first time trying this, could you clarify if this will work:
Download this tool: http://androidforums.com/threads/tool-linux-batch-lollipop-deodex-v1-9-8-9-15.931146/
Copy /system/app, /system/priv-app, and /system/framework to my computer
Run the 'deodex_lollipop' tool
Create a very simple flashable zip using the sample here: http://www.droidviews.com/create-flashable-zips-cwmtwrp-recovery/ with the contents of the deodexed /system folder I just created
Flash that in TWRP
Then make the edits I mentioned above to the SystemUI.apk
Will that work? Or is it likely to be very difficult?
If it does work, are there downsides to doing it? Not getting future updates, running slower, etc, or should it be basically the same as before except with the s-finder toolbar gone?
Thanks so much for all of your help, this is really great. :good:
Click to expand...
Click to collapse
It should work but line with everything on here requires a lot of trial and error. If it sounds like something you want to try then go ahead.