[Script]New "Low Storage" Notification fix - Galaxy S I9000 General

Here we go !
Starting point is from CyanogenMod Captivate forum and some improvement were added here and there. Credits are recalled and came from this thread : [SCRIPT][CM7/9] /datadata/ low storage notification lagless fix - init.d script.
Background :
CyanogenMod (CM) based roms on our I9000 (and brothers) uses a small and fast flash chip to store application datas. This make the rom smooth and sweet ... This chip is mounted as /datadata and is about 170Mo.
With a lot of apps (or apps storing lots of stuff there) we faced a "Low storage" notification and our phone becomes laggy.
The first idea was to move this /datadata to /data (about 2Go) whose have a lot of free space. This works but the phone became laggy.
Then some others devs think about moving back to /datadata frequently accessed files (sqlite database and xml preferences files). First as scripts part then as flashed zip file. The phone becames smoother but not like a "vanilla" CM rom. This is the 1103 datafix in thread linked previously.
An xda user suggested to let on /data only library files and move back all other stuff to /datadata. These lib files are only accessed (when used by users) in read mode so the ext4 /data partition is efficient in this way and phone becomes smoother as "vanilla" CM roms. This is the 2903 datafix I made and post in previously linked xda thread.
But with this latest datafix, applications cache are stored in /datadata and recent Google apps (like Chrome) fulfilled it quickly : the "Low storage" notification is back !
Next solution :
Like 2903 datafix, only libraries ("lib" and "libs" subdirectories) stay on /data by default.
BUT unlike it you could choose which apps will also store their cache in /data. And this is REVERSIBLE : if one of selected app becomes laggy you could move back its cache onto /datadata
How to use it :
Make a nandroid backup
Just grab the zip file and flash it in recovery
At reboot, it will revert previous datafix (if there is one) and apply this one. So first boot could take more time (5 minutes max) than "normal" boot.
It also creates a "datafix" directory in /data/local with two files : "move_cache.txt" and "skip_apps.txt".
Just edit the first file (root needed) to add apps whose cache will go back to /data at next boot :
Code:
com.android.chrome
org.mozilla.firefox_beta
will put Google Chrome and Firefox Beta cache on /data. All others apps cache will go to /datadata.
If you want Firefox cache to go back on /datadata, just remove its line in the file and reboot.
In the "skip_apps.txt" file, just put apps you want to fully stay on /data/data. If apps was previously moved to /datadata by the datafix it won't apply; you have to add its name in "skip_apps.txt" file after installing it and before rebooting the phone. On the other hand, if you remove the apps name from "skip_apps.txt" file all but libraries will be moved to /datadata at next reboot.
Requirements :
Samsung Galaxy S based phone (GT-I9000, Vibrant, Fascinate, Captivate, etc.)
CM based rom (including CM7/9, MIUI and maybe ao(k)sp etc.)
Kernel that supports init.d scripts (latest CM9 nightly support it)
Busybox installed
A fresh nandroid backup
FAQ :
Q : There is 2 zip files, who's the good one ?
A : It depends of your kernel. With stock CM9 kernel use the Datafix20120521. With others like Devil etc., use the SDatafi20120521. The only difference is between the script name : 30datafix or S30datafix. Some recent kernels add a "S" before the init.d script name. Why ? No idea !!!
Q : Will this wipe my phone ?
A : No, it should not delete any data on your phone. But as it's not tested with every phone xda user have it's a good idea to have a fresh nandroid backup
Q : Do I need to reflash the zip file ? When ?
A : The datafix will be erased each time you upgrade/change your rom (including Nightly Builds) or your kernel (many of them "clean" the init.d directory). But if you don't install lots of apps after upgrading you don't really need to install the datafix again : without full wipe, a nandroid restore or an Odin full installation te datafix will stay on.
Q : Is there something to do when backuping my apps ?
A : Nandroid should work without specific option; Titanium Backup users should tick the Preferences > Troubleshooting settings > Follow all symbolic links option. I don't use other backup apps ...
Q : Can I use this on Samsung based rom ?
A : No ! And it's irrelevant cause Samsung roms don't have the "Low storage" issue !
Q : I'm using Slim ICS rom, do I need some busybox fixer etc. ?
A : I don't use SlimICS but all commands in my script call busybox directly so it should work. Let me know if there is still a problem with this !
Q : Why do you change naming of the zip file ?
A : Cause I want ! And it's listed directly in chronological order in terminal (or recovery) in this way.
Q : How can I know which apps use most space on /datadata :
A : Just run as root (in adb or terminal) :
Code:
du -s /datadata/*|sort -n
Downloads :
Box : https://www.box.com/s/6783d86f3840c02db911
Dropbox : https://www.dropbox.com/sh/rwibb0r0fhhyvh6/KaoBoC1BtB
Please don't mirror this.
I put the shell script in attachement here. Just grab it on your sdcard, remove the ".txt" extension and you could run it using Scripter or equivalent (root needed). Please post here if something gone wrong when using it.
Donations :
As I spent some time (and coffee) for this (and april datafix for those following previous xda thread) I think about a donation button. Give me your advise on that please ...
Link for donations
But just a little "Thanks, it works great !" would be great !

Reserved.
(ten chars)

Thanks for this. I kept wondering why I would run out of storage all the time. Well, now I know and you fixed it!
Sent from my GT-P7510 using XDA Premium HD app

awesome using chrome was causing me FC every once in a while

Hi,
Nice work.
Something I don't understand - how should I choose which apps I have their cache go to the /data partition? Apps that I frequently access? Apps that take a lot of space?

Wendigogo I've previously had an old datafix posted that moved all the files to /data/data and I've only had issues when Chrome filled the cache so Ive ran your script but now /datadata is filled and everything is FC Chrome's cache seems to be in /data/data though
any ideas?

Er.. is my datadata folder meant to be empty after applying this patch ? Phone is definitely slower.. forgot to do a nandroid too argh.
As per the other fixes.. doubt this is reversible ?
Sent from my GT-I9000 using Tapatalk 2

Wendigogo said:
Q : Can I use this on Samsung based rom ?
A : No ! And it's irrelevant cause Samsung roms don't have the "Low storage" issue !
Click to expand...
Click to collapse
Just a stupid question.
Why Samsung Roms dont need it ?
How works the solution of Samsung?
Thanks!

Very good script. Whats your future plans for this?
It would be really good if this was made into an app that let u select the apps cache you want on /data or /datadata rather than having to edit a text document.
Sent from my GT-I9000 using XDA

I've flashed this and now my /datadata partition is empty...
Enviado desde mi GT-I9000 usando Tapatalk 2

Something went wrong for me too
I wasn't previously using datafix,flashed it and checked my /datadata a very little time after reboot that was 128Mb free.Seemed a lot of free space comparing to the only-libs 2903 version.For the same initial configuration/apps installed i usually get about 88Mb of free space after flashing 2903.
Just a little while later i noticed a datadata folder in /datadata and free space was now 66Mb...I reboot and /datadata ended full.
Note:Users of Devil or MnIcs get after each boot a user.log (+ a .bak of the previous boot) that describe among others things init.d process,it could help to paste it here

Seems to work for me... but can someone tell me what the following folders are for and if I need them or if they're remnants of some past datafix?
/data/data.new
/data/data2
Thanks.

TheeWolf said:
Hi,
Nice work.
Something I don't understand - how should I choose which apps I have their cache go to the /data partition? Apps that I frequently access? Apps that take a lot of space?
Click to expand...
Click to collapse
None would be the best choice.
Moving their cache out of /datadata can potentially make them laggy. However, some apps have massive caches (Flipboard, Chrome, Google Music, etc.); as such, these apps are unusable unless you do move their cache (or unless you have very few apps installed).

I wonder why so many people are having troubles. I'll give the script a try soon. It looks good! Thanks for your monumental contribution, Wendigogo.

Wendigogo said:
Donations :
As I spent some time (and coffee) for this (and april datafix for those following previous xda thread) I think about a donation button. Give me your advise on that please ...
But just a little "Thanks, it works great !" would be great !
Click to expand...
Click to collapse
My vote is that you SHOULD put up a donation button, I am happy to contribute to your coffee fund (so long as you don't drink Starbuck's ;-) But since you're French, you surely have better taste than that!)

After upgrade to ver.0521 from 0329, I have the following problems:
1. There is a data.new folder, I wonder if it can be removed.
2. new installed apps haven't been moved to datadata
3. removed apps haven't been removed from datadata
I'm on cm9 0520 with devil 0.56 kernel, busybox updated to 1.20.
By the way, the scripts run well under scripts manager.

curl66 said:
Just a stupid question.
Why Samsung Roms dont need it ?
How works the solution of Samsung?
Thanks!
Click to expand...
Click to collapse
I GUESS it is easy to manage across all devices for the cm team without having to write specific code for different devices.

basily said:
Seems to work for me... but can someone tell me what the following folders are for and if I need them or if they're remnants of some past datafix?
/data/data.new
/data/data2
Thanks.
Click to expand...
Click to collapse
+1. Why do we need those folders to be kept in data? But when I tried to delete data.new I got FC's for all of my apps. Seems that data.new has replaced data/data folder.
And one more. I wanted to move com.android.email to data/data completely and edited skip_apps.txt. But when I check datadata folder with Disk Usage app - com.android.email still remains there.
What have I done wrong?
Sent from my SGH-I897 using xda premium

I find that 0521 version uses busybox for copy /move /mkdir operation, which is different from old versions.

After 3 reboots /datadata is still empty...
Enviado desde mi GT-I9000 usando Tapatalk 2

Related

[PATCH][26-Mar-11] Bugfix patch v3 for Dexter's 1.3 ROM (stock221v13-bugfix-3)

Note: I consider this obsolete and recommend rusmod
Bugfix v3
Here's the latest bugfix for Dexter's 1.3 aka stock221v13. This includes everything from Bugfix v2 and adds:
Extended power menu that adds "Reboot" and "Recovery" (see thumbnail below for a screenshot)
Include conservative governor (c19932, nadlabak)
Tweak to improve SD card read performance (reverendkjr)
DO NOT APPLY THIS TO XAVWANTED'S OR KHALPOWERS ROMS
The extended power menu requires extensive modifications to the framework. This patch includes Dexter's 1.3 framework. Don't hose your phone! I can help port the menu to the other ROMs, but this can and will bork your stuff if you're not running stock221v3 (+bugfix updates are OK).
Instructions:
Read all the instructions
Save stock221v3-bugfix-3.zip to OpenRecovery/updates/stock221v3-bugfix-3.zip
Boot to OpenRecovery
OR menu > nandroid > backup > system > backup selected
OR menu > nandroid > restore > stock221v13 > system > restore selected
OR menu > apply update > stock221v3-bugfix-3.zip
OR menu > wipe dalvik cache
OR menu > reboot system
Download:
http://www.multiupload.com/MTCIACFSJN
More details:
https://github.com/downloads/Mioze7Ae/XT720-patch
Experimental patches for bugfix v3
Experimental patches are minimally tested.
Metamorph compatibility fix
Volume-down boot to enter fastboot
Bugfix v2
Summary:
Graphics/OpenGL performance tweak (xavwanted)
Media library tweaks (xavwanted)
memhack (khalpowers) moves dalvik-cache to either /cache or /sd-ext
By default moves dalvik-cache to /cache
Will use /sd-ext/dalvik-cache instead if it exists (see also "User control of /sd-ext" below)
minfree memory parameters tweaked
Parameters from AutoKiller Memory Optimizer database
http://andrs.w3pla.net/autokiller/list/currentType/378
http://andrs.w3pla.net/autokiller/list/currentType/591
Fix milestone overclock persistence
Autodetects ext2/3 (kousik)
ext2/3 partition is checked and possibly repaired on boot
Disable automatic apps2ext. Native Froyo App2SD is not affected.
See also "User control of /sd-ext" below
apps2ext used to be called app2sd before native Froyo App2SD (apps2fat) existed. Confusing!
Add support for Link2SD
See also "User control of /sd-ext" below
Adds Maps.apk and updates YouTube.apk
User control of /sd-ext through manual creation of directories
/sd-ext/app (move /data/app to /sd-ext [apps2ext])
/sd-ext/dalvik-cache (move /data/dalvik-cache to /sd-ext)
/sd-ext/app-private (move /data/app-private to /sd-ext)
/sd-ext/link2sd (enable Link2SD 1.5.1 support)
apps2ext has priority over link2sd and overrides! It doesn't make sense to use both!
Replaces /system/oc with modular scripts in /system/etc/init.c
See the README on github for more details. https://github.com/Mioze7Ae/XT720-patch
Installation
Download and copy stock221v13-bugfix-2_signed.zip to the /sdcard/OpenRecovery/updates directory
Reboot into OpenRecovery
"Nandroid > Restore" Dexter's stock221v13 system (restoring boot not necessary)*
"Apply update" and select stock221v13-bugfix-2_signed.zip
Wipe data / factory reset*
*Advanced users: If you've been running Dexter's 1.3 (stock221v13) with the previous stock221v13-bugfix-1.zip, then it should be possible to apply bugfix-2 cleanly over stock221v13-bugfix-1.zip without first restoring system if you haven't made incompatible customizations to /system. You can also probably just clear the dalvik-cache instead of wiping, but I recommend doing that manually if you've moved it to sd-ext.
Download
http://www.multiupload.com/E7NJ9H2F9C
https://github.com/downloads/Mioze7Ae/XT720-patch/stock221v13-bugfix-2_signed.zip
Experimental patches for bugfix v2
Experimental patches are minimally tested.
Conservative governor suggested by c19932 module from nadlabak (included in bugfix-3)
reserved
this post intentionally left not blank
Disable automatic apps2ext. Native Froyo App2SD is affected.
Click to expand...
Click to collapse
Do you mean unaffected or is Froyo Native Apps2SD not working?
3rdstring said:
Do you mean unaffected or is Froyo Native Apps2SD not working?
Click to expand...
Click to collapse
Yes. You are correct native Apps2SD is NOT affected by disabling the automatic apps2ext. Thanks for catching that quickly!
tried to apply over last 1.3 bugfix patch.... "installation aborted".
I have installed it over the first bugfix. It works perfekly! Where i can see if it applied?
Whats is the diffrent between app2ext an link2sd?
c_urbanek said:
tried to apply over last 1.3 bugfix patch.... "installation aborted".
Click to expand...
Click to collapse
It's kind of a Hail Mary. It did work in my testing and I just tried it again with success. One thing is the new patch is signed so it could also be that your zip got corrupted in download. I've gotten installation aborted messages when the zip was corrupt, but there are probably other ways for it to fail. The md5sum should be
Code:
a93cfa1d6ea73a4ee8ff6ec4afc72baa stock221v13-bugfix-2_signed.zip
smoki3 said:
I have installed it over the first bugfix. It works perfekly! Where i can see if it applied?
Whats is the diffrent between app2ext an link2sd?
Click to expand...
Click to collapse
If you can see a /system/etc/init.d/00_memfree file on your phone, the update was applied.
App2ext moves all apps to the ext partition. Link2SD lets you do it selectively. This isn't a tremendous gain on Froyo, because we have the native move to SD. One difference is that using app2ext apps will be available while the sdcard is being accessed over USB. Also widgets should work for app2ext. At one point I unscientifically convinced myself that app2ext was faster at loading apps than the native move. That said, I'm not currently using either app2ext or link2sd except when testing. I did a big app purge recently and combined with the memhack I'm not running out of space (yet )
Okay the patch works very good! I have more memory now and it seems like it is very fast now! Great work
Thanks for this new update.
I have installed the patch stock221v13-bugfix-1, means that the new patch stock221v13-bugfix-2_signed what I can get to the Updates folder and apply it without restoring the data from the factory?
Means that the Dalvik-cache will automatically be going to SD?
Still need to partition the SD?
What about applications that are currently in the SD, which were moved to app2sd?
Thanks!
Tavinsky said:
Thanks for this new update.
I have installed the patch stock221v13-bugfix-1, means that the new patch stock221v13-bugfix-2_signed what I can get to the Updates folder and apply it without restoring the data from the factory?
Means that the Dalvik-cache will automatically be going to SD?
Still need to partition the SD?
What about applications that are currently in the SD, which were moved to app2sd?
Thanks!
Click to expand...
Click to collapse
By default, what bugfix-2 does is move dalvik-cache to a different partition inside the phone, not to the SD card. /data and /cache are two different internal partitions. /data is what the phone GUI calls "Internal memory", but both are internal.
Why do this?
Eclair 2.1 wasn't designed for JIT so dalvik-cache didn't exist. New in froyo 2.2, JIT creates a lot of data in /data/dalvik-cache (at least 50mb, often 70-80mb). To accommodate for this increased use of /data in the Korean Motoroi froyo, Motorola adjusted the partitions to take 50mb from /cache and 20mb from /system to grow /data by 70mb. Dexter's 1.3 is built off of the 2.1 kernel and partitions and we can't change Motorola's partitioning (because of locked bootloader). So we end up losing space from /data. What we can do is put dalvik-cache on /cache (the one Motorola shrank) instead. That's what the update does.
Moving dalvik-cache to sd-ext is different. If you did not do that while running bugfix-1 (believe me you would know if you did), then you should be able to just apply bugfix-2, select wipe dalvik and reboot (the first boot after wiping dalvik is always slow). It should find your apps. There is a small chance you will have to wipe data / factory reset. I cannot guarantee it will work in all circumstances but it's worth a try. Take a nandroid backup of system, data, cache before applying bugfix-2 just to be safe.
If you did move dalvik-cache to sd-ext, then OpenRecovery doesn't know how to wipe dalvik-cache correctly, so you'd have to do that manually. If you set up dalvik-cache on sd-ext, then you probably already know how ways to do that.
It should not affect any apps that are on SD.
If I was really clever I would figure out how to make the update clear dalvik-cache on install... hmmmm.
By default, what bugfix-2 does is move dalvik-cache to a different partition inside the phone, not to the SD card. /data and /cache are two different internal partitions. /data is what the phone GUI calls "Internal memory", but both are internal.
Why do this?
Eclair 2.1 wasn't designed for JIT so dalvik-cache didn't exist. New in froyo 2.2, JIT creates a lot of data in /data/dalvik-cache (at least 50mb, often 70-80mb). To accommodate for this increased use of /data in the Korean Motoroi froyo, Motorola adjusted the partitions to take 50mb from /cache and 20mb from /system to grow /data by 70mb. Dexter's 1.3 is built off of the 2.1 kernel and partitions and we can't change Motorola's partitioning (because of locked bootloader). So we end up losing space from /data. What we can do is put dalvik-cache on /cache (the one Motorola shrank) instead. That's what the update does.
Moving dalvik-cache to sd-ext is different. If you did not do that while running bugfix-1 (believe me you would know if you did), then you should be able to just apply bugfix-2, select wipe dalvik and reboot (the first boot after wiping dalvik is always slow). It should find your apps. There is a small chance you will have to wipe data / factory reset. I cannot guarantee it will work in all circumstances but it's worth a try. Take a nandroid backup of system, data, cache before applying bugfix-2 just to be safe.
It should not affect any apps that are on SD.
Click to expand...
Click to collapse
Thanks for your prompt reply, I have the question of how to move the dalvik-cache, you told me that "Would you believe me know if you did", then I'm sure they did not. Then, after applying the new patch, how should I move that dalvik-cache?.
Just to make sure, when making a backup nandroid, I mark all partitions, excluding Basband software, linux bootloader, logo and device tree? If something fails, with this new backup can restore the phone as it was after applying the ROM of Dexter's, and the data and preferences?
Tavinsky said:
Thanks for your prompt reply, I have the question of how to move the dalvik-cache, you told me that "Would you believe me know if you did", then I'm sure they did not. Then, after applying the new patch, how should I move that dalvik-cache?.
Click to expand...
Click to collapse
It should move automatically. You don't have to do anything
Tavinsky said:
Just to make sure, when making a backup nandroid, I mark all partitions, excluding Basband software, linux bootloader, logo and device tree? If something fails, with this new backup can restore the phone as it was after applying the ROM of Dexter's, and the data and preferences?
Click to expand...
Click to collapse
That sounds right. I can't remember exactly which ones can't be backed up. To undo trying the patch you need to restore System, Data, Cache (maybe), SD Data (possibly, if you have one). It doesn't hurt to get more. Just read the nandroid output carefully to make sure no errors happened.
I did not apply your patch because I am not really running out of storage memory on my phone and seems like that's the main focus of this patch. Just want to drop by and say thank you for your work and the clear description of the changelog, instead of the typical "optimal performance" and "faster system and more internal memory" that other posters do
While I appreciate the work and contribution by all members, I surely hope they will also post a more clarified changelog like yours
c19932 said:
I did not apply your patch because I am not really running out of storage memory on my phone and seems like that's the main focus of this patch. Just want to drop by and say thank you for your work and the clear description of the changelog, instead of the typical "optimal performance" and "faster system and more internal memory" that other posters do
While I appreciate the work and contribution by all members, I surely hope they will also post a more clarified changelog like yours
Click to expand...
Click to collapse
Thanks. Maybe I should break the changelog into subsystems. That might make it easier to scan.
The main non-memory improvements over bugfix-1 is xav's egl.cfg which really does help speed up the interface considerably and is the secret sauce of the recent themed ROMs here. We discussed it on the main thread just after bugfix-1 was released and a lot of us adopted it, but it seemed too experimental to push out as a default at the time. I've been running it since then without a problem and forgot that not everyone has it. Since khal and xav have been including it in all their ROMs, I decided it was probably time.
I also get a little annoyed at having to dig out these basic improvements from mostly theme and app-choice packages, but it does hone my understanding of android . I try to not push these things immediately out of respect to khal and xav. There was enough complaining yesterday about how to remove a theme get a "fast" stock ROM, that I decided it was probably time. There really hasn't been too much innovation lately between the ROMs, it's mostly been theming. It's sad xav's selling his phone.
The big problem still remains RAM use. Tweaking the minfree parameters seems more of a band-aid than a fix. That seems to be universal across all the froyo ROMs. Something isn't right. Maybe now that the Milestone froyo is finally released we can get to the heart of the problem.
* /sd-ext/app (move /data/app to /sd-ext [apps2ext])
* /sd-ext/dalvik-cache (move /data/dalvik-cache to /sd-ext)
* /sd-ext/app-private (move /data/app-private to /sd-ext)
* /sd-ext/link2sd (enable Link2SD 1.5.1 support)
* apps2ext has priority over link2sd and overrides! It doesn't make sense to use both!
Mioze7Ae again i love you ...you truly inspire me... sorry to ask such a basic question but i thought that in /sd-ext the forlder should be named *example* dalvik_cach and not dalvik-cach i see you changed all the _ for - is that on pourpose?
hello Mioze7Ae:
I have upgraded the stock221v13-bugfix-2_signed.zip.Upgraded before tock221v13-bugfix-1.zip.This had little impact, right? The upgrade will also be saving it? Always charge the battery power ah
hellmonger said:
Mioze7Ae again i love you ...you truly inspire me... sorry to ask such a basic question but i thought that in /sd-ext the forlder should be named *example* dalvik_cach and not dalvik-cach i see you changed all the _ for - is that on pourpose?
Click to expand...
Click to collapse
It must be /sd-ext/dalvik-cache not /sd-ext/dalvik_cache. If you use the _ the boot scripts will ignore it. See line 37 in
https://github.com/Mioze7Ae/XT720-patch/blob/master/src/system/etc/init.c/10_sdext
Maybe I accidentally hit a shift somewhere previously and didn't proofread carefully. Sorry for any confusion.
fwals said:
hello Mioze7Ae:
I have upgraded the stock221v13-bugfix-2_signed.zip.Upgraded before tock221v13-bugfix-1.zip.This had little impact, right? The upgrade will also be saving it? Always charge the battery power ah
Click to expand...
Click to collapse
I think you are asking: Is it OK to apply stock221v13-bugfix-2_signed.zip on top of stock221v13-bugfix-1.zip? I'm 95% confident it is OK.
Mioze7Ae said:
It must be /sd-ext/dalvik-cache not /sd-ext/dalvik_cache. If you use the _ the boot scripts will ignore it. See line 37 in
https://github.com/Mioze7Ae/XT720-patch/blob/master/src/system/etc/init.c/10_sdext
Maybe I accidentally hit a shift somewhere previously and didn't proofread carefully. Sorry for any confusion.
Click to expand...
Click to collapse
No no sorry to bother you you trully rock!!!!!!!

[SCRIPT] No-lag solution to CM7/9 "low memory" notifications (STEP BY STEP,FIXED TB)

[SCRIPT] No-lag solution to CM7/9 "low memory" notifications (STEP BY STEP,FIXED TB)
23/01/12 - Now with Titanium Backup support!
The Titanium Backup team is awesome. I contacted them and within 3 days they had a working fix. To make sure that titanium backup works properly all you need to do is download the latest version from the market, go into 'preferences' and select 'follow all symbolic links' in the 'Troubleshooting' section at the bottom. That's it. Now you'll be able to backup normally and then restore your apps in any other rom. Neat!
Click to expand...
Click to collapse
Okay, I've found a rather excellent solution to the low storage problem that plagues the CM7 and CM9 roms - without causing the lagginess of the ".nodatadata" approach. It's not my work but was posted by drefnel on the Cyanogenmod forum. It's very smart: instead of moving the whole of /datadata (fast yaffs2) to /data (slower ext4) and so introducing lag it keeps most apps' non-performance critical data on /data and moves performance critical sqlite databases and xml preference files to the fast /datadata.
Installing this fix is a two step process:
Phase 1 - some prep, takes around 10 minutes to complete. Only has to be done once.
Phase 2 - running the script whenever you've installed new apps and used them once or twice. this just involves hitting a shortcut on your home screen. boom!
The original guide can be found here we need to make a few alterations and I've done a step-by-step below:
Step by step guide
I take no responsibility if using these instructions messes up your phone. They worked for me and you should always be able to restore using the clockworkmod backup. But you can't say you haven't been warned.
Make sure you're running CM7 or TeamHacksung's CM9 or Onecosmic ICS.
This will NOT work on encrypted phones.
DO A NANDROID BACKUP BEFORE YOU BEGIN.
Phase 1 - (if you've already used the ".nodatadata" method then start at step 4)
1. Download Terminal Emulator
2. Open terminal emulator and then enter each of the following followed by return:
su
touch /datadata/.nodatadata
3. Reboot (this might take a while as the OS will be making changes to your filesystem).
4. Open terminal emulator and then enter each of the following followed by return:
su
rm /data/data/.nodatadata
5. Reboot into recovery, go to "mounts & storage" and then select "format datadata". Reboot normally.
6. Go to the market and download GScript Lite. Open it and close it again - this should create a folder called "gscript" in your sdcard. Unzip the file attached in this post and place the script in it in that folder.
7. Open up GScript Lite, press menu and add script. Click load file, select the script file, make sure that "needs SU" is selected and click save.
8. Run the script by tapping it. You should see GScript report its progress and finally the script should finish. Press close and gscript will crash out (can't have it all ).
Phase 2
Add a shortcut to this script on your desktop.
CM7 - long-press and hold a blank area of your home screen, select 'add shortcut', and then select 'gscript lite'. select the script you've just added.
CM9 - go into your app drawer, select the 'widgets' tab, find 'gscript lite', press and hold it and move it onto your home screen. select the script you've just added.
You should use the shortcut after you've installed new apps and used them a few times. There's no harm in not using the script for a while, all that will happen is that app may become a bit laggy until you use the script to move its data to /datadata.
That's it. Congratualtions!
You can flash new CM roms and the script will carry on working fine, but if you wipe data in recovery then you'll have to start from the beginning
You won't be able to easily go back to the original configuration or use the ".nodatadata" method (you'll need to Titanium Backup, wipe everything and then restore), but you'll never miss them.
Good luck
I hope this helps people out. We should find a way of better automating the steps to make it more noob friendly and maybe Team Hacksung and One Cosmic could incorporate it into their ROMs. (Essentially the script needs to be run periodically to make sure that the performance critical /data/data elements of new apps are copied across to /datadata - apart from that it's not too different from the ".nodatadata" approach).
Personally using the much simpler .nodatadata approach, i found that after a rom (cm9) install, most lag goes away after using it for a few hours, although I have heard the speed of the flash memory is not equal on all devices... so could be laggy for some regardles of usage.
Yup I've tried both and the script approach is definitely much quicker in my case. I'm going to see if I can simplify this procedure somewhat.
Sorry for being a noob.. I am not sure how to apply the script to my Android device... Should I use Terminal Emulator on my Galaxy S and type the script in there? Would you mind to guide me through the process? Thanks a lot
Now with a step-by-step guide.
Man you are awesome! Thanks for your guide!
Wouldn't it be an idea tu use scriptmanager (free or pro) instead of gscript? it can run scripts on boot.
Maybe later, when the standard kernel for cm9 will support init.d, it can be an init.d script?
And oh, I will put a link to this thread in the wiki, you can edit the wiki yourself also if you ask for acces.
seem like there is no one try on OneCosmic, and im going it a shot!
will report later~
Zatta said:
Wouldn't it be an idea tu use scriptmanager (free or pro) instead of gscript? it can run scripts on boot.
Maybe later, when the standard kernel for cm9 will support init.d, it can be an init.d script?
And oh, I will put a link to this thread in the wiki, you can edit the wiki yourself also if you ask for acces.
Click to expand...
Click to collapse
Good points. The reason I chose GScript was its user friendliness and simplicity. There are define advantages in running this script at boot. (I'd much prefer to have things run automatically before the GUI appears (as in init.d) rather than clog up GUI boottime as Script Manager would require.)
The phenomenal uptime I get with Android means that I don't reboot very often. Ideally we'd want something that monitored the data/data folder and ran the script on the appearance of new folders. I'm not sure how you'd automate that without resorting to Tasker. Maybe init.d is the best we can do when it's supported. In the meantime a GScript shortcut on the desktop that I hit once every couple of days feels like the best option so far!
Sent from my GT-I9000 using XDA App
Code124Y said:
seem like there is no one try on OneCosmic, and im going it a shot!
will report later~
Click to expand...
Click to collapse
Tested on OneCosmic and it working good for all but picture/gallery gone...
what i mean is it scan no photo nor any image on my phone~
using gallery+ giving me the same view(nothing in gallery)
but other then this 2 gallery, im try with quickpic also and yup it show pic~
but i want the original picture gallery from the 4.0.3... any help?
There are more advantages in scriptmanager. You are not bound to a specific location on the scared for example, with gscript it has to be in /sdcsrd/gscript folder. And you can make a widget with this script in it, making it a one-click operation but I believe that is a paid feature (and gscript can do something similar, no?)
On the other hand, it is as you say, a bit more complicated.
Also making it a init.d isn't a full solution. Every update from the ROM will wipe the /system/etc/init.d so the script needs to be reinstalled.
Maybe a cwm-flashable would be needed than, everybody here can flash. In that case also the initial commands could be run during flashing.
Taptalked u see
Zatta said:
...Maybe a cwm-flashable would be needed than, everybody here can flash. In that case also the initial commands could be run during flash
Click to expand...
Click to collapse
Yup, a flashable zip which runs initial commands and then appends on an init.d script seems like the way to go. Once the CM9 kernel supports I'll learn how to make these (essentially lazy, me)
BTW, making a one click operation from GScript is easy. Just add the GScript shortcut to your home screen and it will prompt you which script you want to run on click (remember that shortcuts are now grouped with widgets in ICS)
Sent by airmail.
Code124Y said:
Tested on OneCosmic and it working good for all but picture/gallery gone...
what i mean is it scan no photo nor any image on my phone~
using gallery+ giving me the same view(nothing in gallery)
but other then this 2 gallery, im try with quickpic also and yup it show pic~
but i want the original picture gallery from the 4.0.3... any help?
Click to expand...
Click to collapse
Have you tried clearing the data for the gallery app? Worth a shot.
Sent by airmail.
revthanki said:
Have you tried clearing the data for the gallery app? Worth a shot.
Sent by airmail.
Click to expand...
Click to collapse
not needed already, becoz reboot seem to be fixed...
Samsung galaxy S GT-I9000 miui.us latest rom
I just have a question popped up in my mind, after applying this script,when I update my teamhacksung ROM in the future(i.e the future build15), will it causes any problem / break my phone?
leolee0209 said:
I just have a question popped up in my mind, after applying this script,when I update my teamhacksung ROM in the future(i.e the future build15), will it causes any problem / break my phone?
Click to expand...
Click to collapse
Absolutely shouldn't, as long as pawitp doesn't ask you to wipe data. If he does then you'll have to start again
Flash away!
Sent by airmail.
People, beware that this will break your TitaniumBackup, I was tested myself
Funnnny said:
People, beware that this will break your TitaniumBackup, I was tested myself
Click to expand...
Click to collapse
How do you mean? A bit more detail please. It really shouldn't, as Titanium Backup does respect symbolic links...
Sent by carrier pigeon.
mispost
10 char
Originally Posted by Funnnny<br />
People, beware that this will break your TitaniumBackup, I was tested myself
Click to expand...
Click to collapse
<br />
<br />
How do you mean? A bit more detail please. It really shouldn't, as Titanium Backup does respect symbolic links...<br />
<br />
<br />
Sent by carrier pigeon.
Click to expand...
Click to collapse
When I backup, wipe and restore, titaniumbackup just restore the symlink, not the actual data
Sent from my GT-I9000 using Tapatalk

[How-To] Re-Odex a Rom

Why this tutorial?
I made this tutorial for the galaxy 3, but then some user reported me that it worked on another phone, so I post this thread here again.
I wanted a good odexed rom, but there isn't any here. So I tried to make my own odexed rom, but it wasn't so good. So I read something about re-odexing and tried it out. I modified it a little bit and I don't know all about re-odexing, so if someone know something better, pls post it here in the thread for everyone. English is also not my mother language, but I hope you'll understand me
What is a odexed and a deodexed rom?
When you look at a stock rom in the folder /system/app, you will see files with the ending .odex and the apks doesn't contains classes.dex files. When you look at a deodexed rom, you'll see that there are no .odex files and the apks contains classes.dex files. Basically every apk contains a classes.dex files. Then the dalvik virtual machine generates a dalvik cache based of the classes.dex file. When you load a app, it will be loaded from the the dalvik cache, not from the apk. Samsung built the odexed rom using a tool called dexopt-wrapper. This tool generates .odex files based from the classes.dex, that means it does the same job like the dalvik vm. The .odex files were pushed in the /system. The files are the replacement for the dalvik cache. Like I wrote above, apps are loading from the dalvik cache, not from apk or classes.dex file, so classes.dex are not needed anymore, so they are deleted in odexed roms. Deodexing using xUltimate means regenerating a classes.dex based from the .odex file, merging it into the apk and deleting .odex.
What are the advantages and disadvantages from a deodexed rom?
Advantages:
-All needed things are in one apk, so modding/theming is (better) possible
-Needs less space on /system
Disavantages:
-Needs more space on /data
-Is not so stable than a odexed rom
-Slower on first boot(because a odexed rom has already execute ready .odex files, a deodexed rom needs to generate dalvik cache)
What do I need to re-odex?
-A rooted phone
-A full NANDroid Backup
-More than 30 mb free space on /system
-ADB drivers for Option 1
-Titanium Backup Pro for Option 2
How can I re-odex a Rom?
There are 2 Options to do it, but only the first does a full re-odex.
Before doing anything make sure that you have a full NANDroid Backup because you'll propably get into a bootloop and I cant guarantee that it works on your device/rom.
Option 1 using dexopt-wrapper:
I used first the script from puppet13th, but I got into a bootloop. So Ive done some changes and tried it until it worked
Some users told me that you can re-odex the rom without being in CWM, so you can may skip Step 2, but you could get into a bootloop without Step 2, but you can try it out, there is no risk with a NANDroid backup
Step 1: Configure the script for your device:
The attached script is made for the galaxy 3, so you have to configure the script for your device. If you done it, pls upload it and post it here for other users.
Download the zip(link below) for your system and unzip it. Then go to the folder "odex" and then open there the file/script "odex" with your favourite text editor(I suggest Notepad++).
You only have to replace the $BOOTCLASSPATH. You can find the valid $BOOTCLASSPATH in /init.rc. Enter your $BOOTCLASSPATH after "BOOTCLASSPATH=" for example so(beginning from Line 8):
Code:
BOOTCLASSPATH=replace_this_with_your_bootclasspath
cd /system/framework
for filename replace_this_with_your_bootclasspath
In the line
Code:
for filename replace_this_with_your_bootclasspath
you must replace the ":" character between framework files with a space.
Step 2(optional): Reboot your phone into cwm recovery and get adb access there
For best results you should re-odex in the recovery menu. Some users told me that it also works in a running system, so you can also try it in a running system, but you must mount /system rw before.
So if you want to re-odex in the recovery menu, reboot into recovery and make sure you have adb access.
Step 3: Ensure /system & /data is mounted, Connect your phone and run reodex script
Make sure that /system and /data is mounted in rw mode(in recovery: go to mount & storages, in a running system:use root explorer) and connect your phone with your computer.
You already downloaded the re-odex script in step 1. Your computer will push it over adb with the needed binaries to your phone. The script will create odex files, will delete classe.dex from the apk/jar, will rezipalign your apks and will delete the dalvik cache.
For windows users: double click on odex.cmd
For linux users: open a terminal and navigate to the folder which contains the unzipped attachment and run
Code:
chmod +x reodex.sh
./reodex.sh
After its finished, simply reboot and enjoy your fully re-odexed rom.
Step 4 (optional) convert /data:
I dont know if there is a better option, but after a re-odex with Option 1, my phone didnt showed the right free space on /data. So I converted /data to a other filesystem and back and then it showed the right free space.
So check your free space and if its wrong, convert your filesystem if you kernel support that.
Option 2 using Titanium Backup Pro:
You need to have Titanium Backup pro for re-odexing.
Step 1:
Select Menu -> More -> integrate sys dalvik into rom and wait until its finished. Then you should have more space on /data. I had when I tried it before 105 and after 135 mb free space on /data and 0kb free space after it on /system, so its not all.
You can also undo it. Its good when you want to try out a new theme, so you can undo and redo it using TB Pro.
Simply select Menu -> More -> Undo sys dalvik integration
and you're done.
Option 1 vs. Option 2
-Option 1 does a full re-odex, you have full free space on /data(Option 2 does only re-odex the apps in /system/app, not the framework(/system/framework)
-Option 1 deletes classes.dex from apks and jars(against Option 2), so you have more space free on /system
-You can undo Option 2 fast, so theming/modding is also possible by undo, theme and redo it, you can also undo Option 1, its called deodexing, but its not so fast
Download Links
XDA gaves me only 500 Errors when uploading was done, so I uploaded it to min.us
Re-Odex Script for Windows
Re-Odex Script for Linux(probably doesnt work, I cant reupload because I dont have the file anymore)
Working on...
There are only phones in the list, which were reported as working by users. It can aso work on a phone which isnt in the list.
Samsung Galaxy 3(working with default script)
HTC Amaze 4G(no script attached)
HTC Evo 4G(script here)
Samsung Galaxy S2(script here)
Motorola Atrix(script here)
Nexus S (4G)(script here)
XPeria Ray(script here)
SGS 1 maybe(working script for ICS aokp here and a working script for 2.3.6 (XWJW5) here)
Wildfire S(script here)
Nexus 7(script here)
TF700T & TF300T(script here)
Xperia Ray GB REPACK4PDA_V7(script here)
Acer A510 and Asus Transformer Prime TF201(script here)
Credits
puppet13th for making orginal script
If I helped you, you can press the thanks button under the post.
Thanks very much! I can confirm this works on the HTC EVO 4G. I have attached my odex file. I had to upload it as a ".txt" file, be sure to remove the ".txt" from the "odex.txt" before using
Thanks, I will have a look and try this on my xperia play
Sent from my R800i using xda premium
Thanks a lot. This works on the Atrix.
Odex file attached.
working on Galaxy S II
edited odex file in attachments
Yup mines work on the evo 4G too thanks. Now I have a odex rom. would post the file but swagstr beat me to it. same path as mine.
Nice to see that it's worked without problems on all devices, which tried by users. If I forgot to mention: a g3 rom developer asked me, if he is allowed to publish a rom which was reodexed with my script.
And yes all secs are allowed to publish rom's which are reodexed with my script. You must not add me to the credits, but it would be great if you do it.
Anyway to individually re-odex .apks with this mod?
swagstr said:
Anyway to individually re-odex .apks with this mod?
Click to expand...
Click to collapse
Yes, in my reodex package is a folder odex, theres a binary "dexopt-wrapper": copy this to your phone and give it executeable rights and then run over adb or term-emulator:
Code:
dexopt-wrapper <input.apk> <output.odex> <$BOOTCLASSPATH>
Working on Sony neo v so should work on Xperia 2011 range
Reserved
Sent from my SGH-T989 using xda premium
Works great!
I'll upload my odex file for the Nexus S 4G
Edit: Here's my odex file for the Nexus S 4G (probably the same for Nexus S)
jr_718 said:
Reserved
Sent from my SGH-T989 using xda premium
Click to expand...
Click to collapse
For what reserved?
Hey, is there any way to do this on a PC? Like, place /system/app and /system/framework/ in specified folders then run the odex script and it can odex the apk's and jar's on the desktop?
fergie716 said:
Hey, is there any way to do this on a PC? Like, place /system/app and /system/framework/ in specified folders then run the odex script and it can odex the apk's and jar's on the desktop?
Click to expand...
Click to collapse
You need the android phone to execute dexopt-wrapper binary. But you can do that over adb. You can reodex all over adb and then pull the reodexed files, but you can also do a nandroid backup, reodex your rom and make then
Adb pull /system/app/
Adb pull /system/framework/
After that you have the files on the pc and you can restore your nandroid backup.
TearsDontFalls said:
You need the android phone to execute dexopt-wrapper binary. But you can do that over adb. You can reodex all over adb and then pull the reodexed files, but you can also do a nandroid backup, reodex your rom and make then
Adb pull /system/app/
Adb pull /system/framework/
After that you have the files on the pc and you can restore your nandroid backup.
Click to expand...
Click to collapse
I see.. Yea that makes sense.
Thank you!
Hmm....but its not a good to go option for ROM developers with no device.
Can anyone make bat script to do this without andro phone?(I m not good windows dev )
I mean the same way dsixdas kitchen de-odexes
Sent from my Micromax_A70 using Tapatalk 2 Beta-4
varun.chitre15 said:
Hmm....but its not a good to go option for ROM developers with no device.
Can anyone make bat script to do this without andro phone?(I m not good windows dev )
I mean the same way dsixdas kitchen de-odexes
Sent from my Micromax_A70 using Tapatalk 2 Beta-4
Click to expand...
Click to collapse
Rom developers without device? Okay, it might be possible to do that under linux and im pretty sure that the binarys should work under linux, but windows isnt possible.
TearsDontFalls said:
Rom developers without device? Okay, it might be possible to do that under linux and im pretty sure that the binarys should work under linux, but windows isnt possible.
Click to expand...
Click to collapse
TommyTomatoes had something going on maybe you could borrow his script and improve on it or work together.
Sent from my powered Shooter E3D with Infection of AnthraX Jamz by wolf.
.Elite_The_King. said:
TommyTomatoes had something going on maybe you could borrow his script and improve on it or work together.
Sent from my powered Shooter E3D with Infection of AnthraX Jamz by wolf.
Click to expand...
Click to collapse
Sorry, i dont understood anything. Whats tommytomatoes script about?

[SCRIPT] Simple Dalvik Cache Cleaner

Dalvik cache cleaner is a shell script which clears the Dalvik cache that can be used with Android Terminal Emulator.
Root and busybox is required, if you don't know what root and/or busybox is then do NOT bother using the script.
Place the shell script in the main directory.
With Android Terminal Emulator type:
su
sh /sdcard/Dalvik_cache_cleaner.sh
The process should be close to instant depending on how much files you have in the directory.
Download: http://caftp.3owl.com/Shell_Scripts/Dalvik_cache_cleaner/Dalvik_cache_cleaner.sh
It worked
~~~~~~~~~~~~~~~~~~~~~
Samsung galaxy s2
Rom: Jedi knight 6
kernel: Jedi kernel 2
~~~~~~~~~~~~~~~~~~~~~
And you thought celebrities weren't smart! =P
Is this also intended to run on every boot, ie via init.d
thebrainkafka said:
Is this also intended to run on every boot, ie via init.d
Click to expand...
Click to collapse
No, that would also waste too much time on boot then on a normal boot due to rebuilding the cache everytime.
When you uninstall an application, usually a dalvik cache file is left over wasting space.
But if you want you can use ROM Toolbox from JRUMMY APPS INC. in the Play Store.
There is a Scripter in that application that you can use for such thing but the problem is that when I tryed using the su binary in the shell script, there is an issue where the su binary in the shell script will just cut off the other parts of the script and only the su binary so your answer would be fat chance unfortunately. :/
Sent from my Sony Tablet S using xda premium
Issue fixed.
Is this the same as wiping dv cache through recovery. Also what will be the script for wiping cache? Will it be rm /cache?
Thanx!
The-Droidster said:
Is this the same as wiping dv cache through recovery. Also what will be the script for wiping cache? Will it be rm /cache?
Thanx!
Click to expand...
Click to collapse
Yes and the code is:
#!/system/bin/sh
rm /data/dalvik-cache/*
reboot
Click to expand...
Click to collapse
I'm not sure if /cache/ is really dalvik cache, on devices with OTA update support the OTA zip's will be stored their with other stuff but if you want I can give you the code for that.
On linux (That also means android) use 'chmod 755' for the permissions for the shell script.
I have tried adding 'su' but that fails has the terminal only executes the su binary so the rest of the script does not get executed.
Using the 'echo' binary to say out what it is doing is a fail has the terminal does not go anywhere due to the echo binary getting executed but it will not display output in the terminal anyway making the script not being executable.
Sent from my Sony Tablet S using xda premium
Man I am full with ideas.
I can create a shell script to do:
[OTA]
Remove OTA Update zip in cache
Copy OTA Update zip from cache to SDCard
[Files and Folders]
Remove LOST.DIR (That is just a useless folder )
Wipe SD Card
Wipe Zip files (useful for custom roms on your SD which you don't want anymore)
Well soon I should get more ideas so the OTA shell scripts will not be possible unless I get a rootable device with OTA functionallity (I do have a Sony Tablet S but I forgot to root it but I went and installed the firmware update without noticing) so it would be the Nexus 4 I would test it on in March.
The thing is that more shell scripts I create more pages I have to add to my website to give information about it, how to use it and the download link which can take around 10 Minutes just by editing the code, make backup and then upload via FTP.
Sent from my Sony Tablet S using xda premium
New shell scripts available which should be available tomorrow and if not a few days.
They are:
Aptoide Cleaner - I found out that the xml files are adding numbers to their file extensions so I built a script which can remove that problem real fast.
Take Out Bin - Removes all or at least most useless directories like LOST.DIR and LazyList, they are just a few.
ExtSD and USB Cleaner - Same has 'Take Out Bin' but it does it on the external SD Card while on USB, LOST.DIR will be erased has that should not be there.
-OLDER PROJECTS-
Dalvik Cache Cleaner - Read the first post.
Andro.Shell.Crash - This is good for developers has this does crash/lag/freeze the OS which can help a root exploit get in, of course there is different effects depending on the hardware and software, if the device is fast and has good hardware then it is possible that it may just lag and/or freeze but for older devices with older hardware can just crash.
NOTICE: The older projects are already out and available to download on my website.
I will be creating a forum about these shell scripts but I am not sure about the Aptoide one for many reasons.
I know that I am not suppose to be talking about this on a thread which has a different purpose but yeah, just an update.
EDIT: I uploaded and programmed the webpages from my tablet using WM FTP Client and DroidEdit Pro so that was a bit too early but all well, new thread(s) should come in tomorrow depending what will happen tomorrow (It is 03:30AM so it would count has today anyway).
Anyone can please guide me how to remove this script???
Thank you in advance
romelcool said:
Anyone can please guide me how to remove this script???
Thank you in advance
Click to expand...
Click to collapse
You just delete the shell script, you only use it in the Terminal Emulator so once you run it, it will wipe the dalvik cache so it will not do such thing in every boot.
Sent from my Nexus 4
Man I think you should create a script which are:
Auto clean of cache || Optimize App || Kill Media Process
If it's possible to you to create script with the list below that will be awesome ! ..
what is the code for auto cleaning cache every 30 minutes ? ..
and also auto optimize application every 24 hours ? ..
kill media process ?
I hope you could help me with this .. Thanks !
CoolApps said:
Download: http://caftp.3owl.com/Shell_Scripts/Dalvik_cache_cleaner/Dalvik_cache_cleaner.sh
Click to expand...
Click to collapse
Gone!
jidanni said:
Gone!
Click to expand...
Click to collapse
That's because I switched sites between 2012 - 2015. This thread was very inactive so I missed it out and didn't update the link with the new one.
The current server I use for it has some files that I'm aware of that are more often downloaded by users which means I ended up removing the shell scripts along with others that don't need to be there. I made a backup of everything before, by the way.
I don't feel that there's a need restore the file and plus, this thread's old.
Because of the sudden bumps of a thread that currently serves no purpose, something should be done about it to avoid further confusions.
Sent from my Nexus 4 using Tapatalk
Can you please tell me what your script did.
I made my own script that does
su -c 'find /data/data/*/cache/* -delete'
This one line saved me from installing multi-megabyte apps that do the same thing.
Is there anything more I should add to my script?
Now I can finally have enough room so Google Play can update apps again!
Thread closed at OP's request.

[Q] Android is upgrading every startup

Everytime I turned on my phone or if it rebooted, I always get:
Android is upgrading
-----------------------------
Starting Apps.
I am on stock ROM, TWRP recovery, Faux kernel. I think this happens after I wiped dalvik/cache in the recovery. Any idea how to stop it? It's nothing very major though as it only takes a few seconds.
are you using any sound/volume mods? or any other flashable mods? i think awesomebeats dies this, at least others have complained about it wiping the dalvik after every reboot.
cdon2109 said:
Everytime I turned on my phone or if it rebooted, I always get:
Android is upgrading
-----------------------------
Starting Apps.
I am on stock ROM, TWRP recovery, Faux kernel. I think this happens after I wiped dalvik/cache in the recovery. Any idea how to stop it? It's nothing very major though as it only takes a few seconds.
Click to expand...
Click to collapse
That's normal if you've wiped the Dalvik cache, and no you can't stop it.
Edit: so wait, this is happening even when you reboot normally after not wiping any caches or flashing a kernel?
CMNein said:
That's normal if you've wiped the Dalvik cache, and no you can't stop it.
Edit: so wait, this is happening even when you reboot normally after not wiping any caches or flashing a kernel?
Click to expand...
Click to collapse
yes.. and it updates apps after delvic wipe.. but in my case whenever i restart I see the "Android is upgrading" box for about 3-5 sec.. no update app progress bar.. and when I wipe delvic this upgrading apps takes like a min or so with my 150+ apps.. but this "Android is upgrading" dialogue box appears only for 3-5 sec..
I am using PA 3.99 with franco kernel.. once booted every thing inside is running smoothly and no fc's...
Same here. No odex files in app folder. No wipe, no cache clearing. Plain reboot. And Android is upgrading message on every boot. (Starting apps)
No optimizing apps message though.
Sent from my Nexus 4
Wouldn't it be related to "zipalign apk on each boot" parameter ? or an other init script put in place by a dirty flash (no /system or /data format) or a kernel... ?
Seems likely. Could you explain in detail kindly?
Sent from my Nexus 4
anandbibek said:
Seems likely. Could you explain in detail kindly?
Sent from my Nexus 4
Click to expand...
Click to collapse
Have a look in the files located in this folder for example (maybe there's another location for init scripts) :
- /system/etc/init.d/
- /system/addon.d/
and open each one, to see what are the tasks contained
benbugohit said:
Have a look in the files located in this folder for example (maybe there's another location for init scripts) :
- /system/etc/init.d/
- /system/addon.d/
and open each one, to see what are the tasks contained
Click to expand...
Click to collapse
Removed the scripts present in init.d folder and then booted with empty folder, but message still present.
Checked the addon.d folder, but those scripts are only for backing up gapps etc.
Not sure where else to try. Please advise.
Thanks.
anandbibek said:
Removed the scripts present in init.d folder and then booted with empty folder, but message still present.
Checked the addon.d folder, but those scripts are only for backing up gapps etc.
Not sure where else to try. Please advise.
Thanks.
Click to expand...
Click to collapse
Did you try to re-flash your (stock) ROM (and the kernel after 2 reboots) with wiping only /cache and dalvik-cache ? with latest 2.6.2.0 TWRP ?
happens to me too
Sent from my Nexus 4
I've seen people get this with stuff like V6 Supercharger by Zepplinrox and similar scripts.
Edit : @Dungeon47: thanks for this information that users can't provide...
HeyyMyNameIs said:
happens to me too
Sent from my Nexus 4
Click to expand...
Click to collapse
A pity that so much details are missing : what did you do before it happened ?
What's your set up ? rom, kernel ? after having update your rom ? kernel ? apps ? which versions ?
Did you try to revert to a clean install after having backup up your apps+datas ?
benbugohit said:
Edit : @Dungeon47: thanks for this information that users can't provide...
A pity that so much details are missing : what did you do before it happened ?
What's your set up ? rom, kernel ? after having update your rom ? kernel ? apps ? which versions ?
Did you try to revert to a clean install after having backup up your apps+datas ?
Click to expand...
Click to collapse
im sorry, just wanted the OP to know that he is not the only one with this "problem" by the way im rooted stock rom and kernel, some apps start up when i boot like nova launcher, lucky patcher sidebar and udn. But i am not looking for a fix for this as this does not take that long and i just said that to let the OP know that he is not alone with this "problem"
Sent from my Nexus 4
Ok guys,
Here's the solution. Don't flame me for talking about unholy stuffs. I'm posting this only because it is the cause of the problem.
If you are using LP or such tools to create .odex files of some app in /app folder. It won't cause any boot msg.
But after you dirty flash a ROM, that .odex files somehow gets backdated and causes the UPGRADING msg.
Fix is, delete the odex files, and re create them if needed. Once after every dirty flash.
Sent from my Nexus 4
I have found fix for this error, it is mainly due to odex files which are created by lucky patcher so deleting these files using lucky patcher itself will surely remove this error with 50 percent success rate. Here's the fix; open lucky patcher, there in lower left section you can see Toolbox, click that Toolbox then select 4th last option i.e Remove all odex files.Thats it android will reboot on itself and vola no android is upgrading. .
Check out attachment for help.
:good:Hits Thanks If I helped u:good:

Categories

Resources