Develop Bugs

[23/09/12][Scripts][CM10] App Mover Suite 0.5 (low /data space fix)

WITH THE NEW CM10 PARTITION LAYOUT THIS SET OF SCRIPTS HAS NO USE ANYMORE, USE IT ONLY IF YOU KNOW WHAT YOU ARE DOING AND YOU ARE SURE YOU NEED THIS.
WHY?
Many people have complained that the new Cyanogenmod 10 partition layout reserved too little space for user application and their data. While I don't find this to be a great deal (having 100+ installed apps usually means many of them are not even used) the solution to the problem is pretty simple, so I've created this tool suite.
FAQ
WHAT DOES THOSE SCRIPTS DO?
Automatic Edition
0.4 AppMover Enabler.zip
When you flash this file if necessary your apk files will be moved to system and a new script will be put in addon.d, this will backup and restore automatically your apps every time you update your rom
This require the rom support, you can check it out HERE if your rom support this function.
0.4 AppMover Disabler.zip
This file will revert everything disabling the automatic backup and restore system and moving apps back to /data. If there is not enough space in /data the script will exit with an error without removing anything.
Developer Edition
0.3dDeveloperEdition.zip
This file contains a modified updater-script and a shell script so that when installing a rom patched with them it will move, backup and restore apks files according to necessity: if the apps are already been moved to /system it will backup them, update the rom and restore the apps; if the apps are still in /data it will update the rom and then move the apps to /system/user_app
Compact Edition
AppToggler.zip
This files moves /data/app to /system/user_app or moves them back to /data/app if you already activated this. If there is not enough space to move the files the script just revert back to a safe condition. You can check the results of the operation in /sdcard/AppMover.txt.
Since the apk files are written only during application installation/updates this should have little to none performance impact while freeing about 70% of the space in /data.
You should use this script just once to move your apk files to the bigger, slower /system partition. Use it again if you want to move them back to the faster /data partition
BackupAndRestore.zip
This files create a backup of /system/user_app to /sdcard/AppBackup.tar. If /system/user_app doesn't exists but there is /sdcard/AppBackup.tar the script assumes you have just updated your rom and restores the backup.
You should use this script before and after every rom update since the CM10 update script formats the /system partition wich now contains your apk files
Normal Edition (Discontinued)
AppMover.zip
This script moves /data/app (the folder where downloaded apk are stored) to a new directory in system (/system/user_app) and then create a symlink to that directory.
AppReverter.zip
This script moves back app to /data/app and deletes /system/user_app.
WARNING: Flash this file only if you are sure there is enough space in /data for all the apps! If not you will end with a full /data partition (and relative forcecloses) and you will lose some apps
AppBackup.zip
This script will backup all your app files in an archive in /sdcard
WARNING: Make sure you have enough space in /sdcard for all your apps.
AppRestore.zip
This script will restore the apps from the archive in /sdcard
HOW TO USE:
Automatic Edition
If you want to move your apps to /system just flash AppMover Enabler.zip, this will take care of moving the apk files and preserve them during rom updates
WARNING: During rom updates ensure you have enough space in /emmc and/or /sdcard for the backup of your apk files, if not you will lose all your apps. Ensure your rom is supported (you can check it here). Consider that rom updates will now take longer, even 3 or 4 times what it used to be depending on how many apps you have installed.
If you want to move your apps back to /data flash AppMover Disabler.zip, this will also disable the backup and restore function. If there is not enough space in /data the script will exit with an error before doing anything.
Developer Edition
Replace the rom files with the one in the archive and then flash the rom normally. Make sure you have backupapps.sh in the root of the rom archive and that updater-script is correctly replaced in /META-INF/com/google/android
Compact Edition
To move your apps to /system you have to flash AppToggler.zip. This should be the first and only time you flash this file since now the fix is applied to a directory level. Newer apps will be installed directly to /system/user_app.
BEFORE flashing/updating your rom you will have to run BackupAndRestore.zip and AFTER flashing the rom you will have to run BackupAndRestore.zip again, not doing so will remove all the apps from your phone since at every update /system dir gets formatted.
If you want to move back all your apps to /data you can just flash AppToggler.zip again.
Normal Edition (Discontinued)
To move your apps to /system you have to flash AppMover.zip. This should be the first and only time you flash this file since now the fix is applied to a directory level. Newer apps will be installed directly to /system/user_app.
BEFORE flashing/updating your rom you will have to run AppBackup.zip and AFTER flashing the rom you will have to run AppRestore.zip, not doing so will remove all the apps from your phone since at every update /system dir gets formatted. Note that AppBackup.zip and AppRestore.zip will work both with /system/user_app and with /data/app, so you can use this two file for backup and restore apps (but not their data) in any rom/occasion.
If you want to move back all your apps to /data you can flash AppRevert.zip
If you done everything good and you get a bootloop try to fix permissions in CWR
If the phone works fine but reboots when you try to install new application it is probably because the OS can't write on /system/user_app for some reason.
Try those steps and report if any of those solves the problem:
Open the terminal or use adb shell and type
Code:
su
mount -o rw,remount /system
and/or
Code:
su
chmod 0777 /data/app
chown 1000:1000 /data/app
In alternative you can try this:
feroxxx said:
[...]
i have problem with reboot issue but solved it wipe cache,dalvik,fix permission and remove google play app's update.no reboot now.
[...]
Click to expand...
Click to collapse
Try to keep in mind that this scripts completely moves /data/app to /system partition. This normally is not a problem, however if you flash something in CWR that needs to read/write something in /data/app (like fixing permissions) make sure to mount /system partition manually
This script should have little to no impact on your rom performance but you may notice some performance loss installing/updating apps.
You may use this script in your rom (integrating the backup/restore into the installation script of a rom would make life simpler for everyone) or improve it, I just ask you to give me some credit.
DISCLAIMER:
This script may contain bugs and is far from perfect. Read instruction twice and make a full nandroid backup before flashing anything, since human errors could be pretty devastating. Anyhow in case of problems I will try to help and improve the scripts but I won't be responsible for any damage to your phone or data, including -but not limited- to: bootloops, app or data loss, alien invasion and thermonuclear war.
==================================================
DOWNLOAD LINK
==================================================​
CHANGELOG:
23th September 2012
V 0.5 (All versions) - Updated init.d script, renamed again as S99SystemApps to make it work on devil kernel. Now the script renames init.d scripts that doesn't start with S#. Is still possible that some scripts get executed after mine, but should be pretty rare.
V 0.5 Automatic Edition - Modified so that in case of problems the phone will reboot before deleting anything, thanks to Silentbob999 for the idea.
19th September 2012
V 0.4.2 Compact Edition - Fixed a typoes in AppToggler and BackupAndRestore.
V 0.4.2 Automatic Edition - Fixed the error you get if you try to flash the Enabler this just after formatting data (didn't test it, but it should work).
V 0.4.1 Init.d Updater - Published a flashabile file to update the init.d script so that you can use the updated one without having to toggle apps or extract it manually from the archive.
V 0.4.1 Compact Edition - Little update to AppToggler so that even if exits on error it still updates the init.d script
V 0.4.1 (All Versions) - Updated init.d script, added some fixes for problem no norma user should ever experience
17th September 2012
V 0.4 Automatic Edition - Automatic version published
V 0.4 Developer and Compact Edition - Renamed /etc/init.d/S99SystemApps in /etc/init.d/z99SystemApps, this will make less likely that some script gets executed after it and sets back /system to read only
14th September 2012
V 0.3.2 (both) - Hotfix, looks like the hotfix applied to init.d did the trick, same correction applied to remaining scripts
13th September 2012
V 0.3.1 (both) - Hotfix, seems that on some phones /system is mounted as read only. Modified init.d script to remount /system in RW if needed
V 0.3 developer edition - Almost rewritten from scratch, now there should be no problems if flashing from gingerbread and if any problem occurs the script should stop before deleting anything. Completely rewritten log system. Temporary apk backup will now be placed in /data /emmc or /sdcard, according to where there is enough space. Added file in init.d that helps preventing corruptions, hopefully system reboots when new applications are installed are gone.
V 0.3 compact edition - Added a lot of space checks. The backup is now saved on /emmc, if there is not enough space there is saved on /sdcard. If there is not enough space anywhere script will now exit with error. Completely rewritten log system. Added file in init.d that helps preventing corruptions, hopefully system reboots when new applications are installed are gone.
Normal Edition - Dropped unless I get enough requests to work on it, is almost equivalent to the compact version and having to work and test 3 version instead of 2 is just time consuming.
5th September 2012
V 0.2.5 developer edition - New version to replace CM10 stock update script, intended to be used by developers in their rom
30th August 2012
V 0.1c compact edition - Initial compact edition Release
V 0.2.5 - Fixed the error where app folder was restored in /system/user_app for good
25th August 2012
V 0.2 - Fixed an error in AppBackup.zip that could lead to follow recursively the symlink of the app directory (again and again and again..)
22th August 2012
V 0.1 - Initial Release

Sounds good. Thanks.
It would be better if we can choose the apps to be removed. Thus an app is needed, I think.

what's the difference with titanium backup?

dongfangri said:
Sounds good. Thanks.
It would be better if we can choose the apps to be removed. Thus an app is needed, I think.
Click to expand...
Click to collapse
You are right, but yhea... without an app would be pretty hard to setup the script. Maybe I could make so that moving apps with root explorer to another dir will trigger a script in init.d to create the symlink, but I think it doesn't make much sense since the performance loss of apk on /system is near to 0 (CM9 and all the rom before that had apks on the partition we now use for /system)
forziere said:
what's the difference with titanium backup?
Click to expand...
Click to collapse
It's not intended to be a backing up tool (even if at some degree works for app backup/restore) but just to move ALL apks in /system where there is a lot of unused free space. You can do it pretty easily by hand if you know some basic linux commands but is still more complex/time consuming than using an automated script like this

Hey, thanks, it's that I was loonking for, works great on MIUIV4 Jelly Bean by Andy Thomson !

Great idea
If i will flash the cm10, i will use your scripts

It's a great idea, but then the app work very well from system/user_app?

esticbo said:
It's a great idea, but then the app work very well from system/user_app?
Click to expand...
Click to collapse
I've published this set of scripts also to get some feedback. Personally I can't find any problem nor performance differences (except the fact that before I had 40mb free in /data and now there are 300) between having apk in /data or in /system but I guess different people with different phones may have different perceptions and results.
By the way my phone is pretty old and it lagged a lot before Pawitp introduced the new memory layout, so I guess I have the old, slower, memory. Fact is I read somewhere (on the CM10 thread I think) that old memory is slow just in writing operations and apk files are written just during installation/update.
As soon as I get some more feedback, I will update the OP with this informations, but before this I have to know if the script can create problems or slowdowns of any sort.

This sounds like a really good idea. Does this do the equivalent of Wendigogo's script by moving the lib files to the slower partition only? Or does it move more than just the lib files?

Vertron said:
This sounds like a really good idea. Does this do the equivalent of Wendigogo's script by moving the lib files to the slower partition only? Or does it move more than just the lib files?
Click to expand...
Click to collapse
It's /data/app that is moved so it's only apks.

Updated with a bugfix to the AppBackup.zip file, if anyone is using this is way better to update

Vertron said:
This sounds like a really good idea. Does this do the equivalent of Wendigogo's script by moving the lib files to the slower partition only? Or does it move more than just the lib files?
Click to expand...
Click to collapse
It's not like "my" datafix because CM move all /data to the speedy partition (and increase its size to 420Mo).
I've made something equivalent on my phone to move apk (on /data/app) to the /system partition. And I brake my CM when upgrading it cause installation process format /system and I forgot to backup my apks.
The best solution was to create a specific /data partition and use the speedy partition for /datadata (as in CM9/7) but pawitp's don't want to do that cause the partition layout will be SGS specific and CM is NOT an SGS rom...
For now this is the best solution ( do you backup users:groups a specific rights for each app?).
Bad news for those having lots of big apps...
Envoyé depuis mon GT-I9000 avec Tapatalk

Wendigogo said:
It's not like "my" datafix because CM move all /data to the speedy partition (and increase its size to 420Mo).
I've made something equivalent on my phone to move apk (on /data/app) to the /system partition. And I brake my CM when upgrading it cause installation process format /system and I forgot to backup my apks.
The best solution was to create a specific /data partition and use the speedy partition for /datadata (as in CM9/7) but pawitp's don't want to do that cause the partition layout will be SGS specific and CM is NOT an SGS rom...
For now this is the best solution ( do you backup users:groups a specific rights for each app?).
Bad news for those having lots of big apps...
Envoyé depuis mon GT-I9000 avec Tapatalk
Click to expand...
Click to collapse
DerTeufel1980 is using a different partition for his Helly Bean rom that has a /data and /datadata partition, so your datafix script should work for his rom at least.
Hopefully other roms will use DerTeufel1980's layout instead as they don't have the same limitations as CM10.

Happy to report this fix has been working perfectly for me on CM10. Thanks so much!

Kino87 said:
WHY?
Many people have complained that the new Cyanogenmod 10 partition layout reserved too little space for user application and their data. While I don't find this to be a great deal (having 100+ installed apps usually means many of them are not even used) the solution to the problem is pretty simple, so I've created this tool suite.
WHAT DOES THOSE SCRIPTS DO?
AppMover.zip
This script moves /data/app (the folder where downloaded apk are stored) to a new directory in system (/system/user_app) and then create a symlink to that directory.
AppReverter.zip
This script moves back app to /data/app and deletes /system/user_app.
WARNING: Flash this file only if you are sure there is enough space in /data for all the apps! If not you will end with a full /data partition (and relative forcecloses) and you will lose some apps
AppBackup.zip
This script will backup all your app files in an archive in /sdcard
WARNING: Make sure you have enough space in /sdcard for all your apps.
AppRestore.zip
This script will restore the apps from the archive in /sdcard
HOW TO USE:
To move your apps to /system you have to flash AppMover.zip. This should be the first and only time you flash this file since now the fix is applied to a directory level. Newer apps will be installed directly to /system/user_app.
BEFORE flashing/updating your rom you will have to run AppBackup.zip and AFTER flashing the rom you will have to run AppRestore.zip, not doing so will remove all the apps from your phone since at every update /system dir gets formatted. Note that AppBackup.zip and AppRestore.zip will work both with /system/user_app and with /data/app, so you can use this two file for backup and restore apps (but not their data) in any rom/occasion.
If you want to move back all your apps to /data you can flash AppRevert.zip
If you done everything good and you get a bootloop try to fix permissions in CWR
This script should have little to no impact on your rom performance but you may notice some performance loss installing/updating apps.
You may use this script in your rom (integrating the backup/restore into the installation script of a rom would make life simpler for everyone) or improve it, I just ask you to give me some credit.
DISCLAIMER:
This script may contain bugs and is far from perfect. Read instruction twice and make a full nandroid backup before flashing anything, since human errors could be pretty devastating. Anyhow in case of problems I will try to help and improve the scripts but I won't be responsible for any damage to your phone or data, including -but not limited- to: bootloops, app or data loss, alien invasion and thermonuclear war.
==================================================
DOWNLOAD LINK
==================================================​
CHANGELOG:
V 0.2 - Fixed an error in AppBackup.zip that could lead to follow recursively the symlink of the app directory (again and again and again..)
V 0.1 - Initial Release
Click to expand...
Click to collapse
Errors found in AppRestore.zip. The script moves the fold /data/app into /system/user_app. It should be all apks in /data/app, isn't it?

zhuzf said:
Errors found in AppRestore.zip. The script moves the fold /data/app into /system/user_app. It should be all apks in /data/app, isn't it?
Click to expand...
Click to collapse
Depends, AppRestore.zip is used to restore the backup created with AppBackup.zip.
AppBackup.zip creates a .tar file that includes the path from the root (so if you have your apps in /data/app you will have those two directorys in the .tar, otherwise you will have /system/user_app). At the restore time the .tar is simply extracted to the root.
Maybe you are confusing AppRestore (used to restore backups) with AppRevert (used to move back apps in /data/app), but still... it does what it should do (I think).
Soon I will release a 0.3 version that aggregate AppMover and AppReverter in a single package that toggles the place where apps are stored and aggregate AppBackup and AppRestore so that if it finds /system/user_app it will create a backup and if it doesn't find it it will restore it (bringing down the number of zips from 4 to 2, but the operations you have to do remains the same). Less chances to human errors and more to script bugs, so if something happens you can blame it on me
Right now I'm thinking to a complete rework with a couple of alternatives since I think this suite is a little bit impractical:
- create something that changes the partition layout splitting /system in a 512mb partition for /system and a 1536mb partition for /data/app... Still I'd prefear to find some alternative since this solution could create pretty big problems if something goes wrong and it won't have native support in the roms/kernels (wich means you would still have to flash a file every time you update the rom to tell it how to manage the partitions and I'm not really shure what would happen when the CM updater script tries to format system and it finds is smaller than intendend, so it may be impossible to do).
- Create an alternative update script that replaces the one in the CM10 zip and does what I wrote above (you would have to modify the CM10 zip every time, but it would be as simple as drag and drop one file in it).
- As alternative to the the repartitioning create an image file of an ext4 partition and mount it runtime (like we did with One Click Lagfix a couple of years ago). It should be easy to customize the zip so that you can chose where to create this file and how big it has be so that you can place it in /system but also in /sdcard or in /emmc. Still... you will have to flash something that teaches how to handle it to the rom every time you update it and if you put in /system you will still have to backup and restore it every damn time (so I guess is pretty useless).
To be honest I don't think that altering the partition layout without official support in the rom is a practical solution since I think negative aspects are way bigger than positive ones but I still think this solution is quite annoying if you update your rom often as I do, so if anyone has suggestions they are welcome.
By the way while I can see the actual rom partitioning has some serius limitations but I understand the reasons behind Pawitp decisions and I hope we won't get different partition layouts on different roms (that will just be a mess e we will end up with different version of kernels ad patches.. We need no more fragmentation than we already have with our device being 2 years old and having roms starting from 2.1 to the actual 4.1.1)

Kino87 said:
- create something that changes the partition layout splitting /system in a 512mb partition for /system and a 1536mb partition for /data/app... Still I'd prefear to find some alternative since this solution could create pretty big problems if something goes wrong and it won't have native support in the roms/kernels (wich means you would still have to flash a file every time you update the rom to tell it how to manage the partitions and I'm not really shure what would happen when the CM updater script tries to format system and it finds is smaller than intendend, so it may be impossible to do).
- Create an alternative update script that replaces the one in the CM10 zip and does what I wrote above (you would have to modify the CM10 zip every time, but it would be as simple as drag and drop one file in it)
Click to expand...
Click to collapse
That looks like the best solution imo. Changing the update script on each rom before you update it. I assume this will work on all roms, not just CM10?
I assume that will make the partition layout similar to DerTeufel1980's new layout?

I thought of a hopefully good idea that would allow you to update nightly roms. If it is possible and someone is willing to develop it.
For this to work you'll have to create an ext4 partition on an external sdcard of about 700mb.
Basically there will be 4 scripts, 1 of them to move /data/app to /system/app with a symlink. One for simply moving it back to /data/app if wanted. Then the other 2 scripts is to move /app to the sdcard partition when you want to update a nightly.
So my idea is; you install the rom for the first time, then run the 1st script to move /data/app to /system/app.
If you want to update the rom. Run a second script which moves /system/app to the external sdcard partition. Then flash the nightly rom as normal. Then install a 3rd script which moves /app from the external sdcard partition back to system/app.
The 4th script is to simply move everything back to /data/app if wanted.
The only downside to this is losing some space from your external sdcard. But it's worth it imo for having alot more storage space and having the ability to update nightly roms.
Do you think this is a feasible idea, or will updating the rom break the symlink?

Vertron said:
I thought of a hopefully good idea that would allow you to update nightly roms. If it is possible and someone is willing to develop it.
For this to work you'll have to create an ext4 partition on an external sdcard of about 700mb.
Basically there will be 4 scripts, 1 of them to move /data/app to /system/app with a symlink. One for simply moving it back to /data/app if wanted. Then the other 2 scripts is to move /app to the sdcard partition when you want to update a nightly.
So my idea is; you install the rom for the first time, then run the 1st script to move /data/app to /system/app.
If you want to update the rom. Run a second script which moves /system/app to the external sdcard partition. Then flash the nightly rom as normal. Then install a 3rd script which moves /app from the external sdcard partition back to system/app.
The 4th script is to simply move everything back to /data/app if wanted.
The only downside to this is losing some space from your external sdcard. But it's worth it imo for having alot more storage space and having the ability to update nightly roms.
Do you think this is a feasible idea, or will updating the rom break the symlink?
Click to expand...
Click to collapse
This is how it works already.. well.. almost.
The Backup and Restore scripts do exactly what you want to do on an external partition (the only difference is that they don't copy the apk on an ext4 partition but they store them in a tar archive on /sdcard that preserve users and permissions regardless of the filesystem in use).
Would make a little more sense to use directly an ext4 partition on the sdcard or external sdcard since it would avoid you the trouble to backup your apps every time you update the rom (but then you will still have to flash a file at every update that tells to mount this external partition) but even then... I'm not fond of altering the partition layout at all even if doing it on /sdcard or /emmc would make it pretty easy to restore in case of problems.
By the way: I've finished the compact version of the suite (0.1c) and fixed a couple of bugs in the old version. Is actually online BUT IS NOT TESTED IN ANY WAY. Don't use it until I update the OP and even then do a nandroid backup before using it, it may be pretty buggy.
Hopefully if there are no bugs in a couple of hours of test I will report back

If your apps are backed up by using AppBackup.zip and you flash a updated rom, do you have to flash AppRestore.zip before the device boots with the new rom or can you let it boot then turn it off and run the script in recovery after?

[solved] Andriod upgrading everytime when restarts

Today im Updated 4.3 JB in my Xperia M Dual using SUS...
update was completed successfully...
but everytime when i switch on my mobile it showing,
Andriod is upgrading...
Starting Applications...
What is this?? this is really happen in all mobile or is this any error??
if it is a problem then, how to fix this problem...
Help me experts.....

Try resetting it with SUS and see if it works.

IIRC, this means android is making new dalvik cache for the apps or the one it has on the phone is old version.
This could indicate problem at \cache\
Try a file explorer. post screenshot of what you see.

theperson333 said:
IIRC, this means android is making new dalvik cache for the apps or the one it has on the phone is old version.
This could indicate problem at \cache\
Try a file explorer. post screenshot of what you see.
Click to expand...
Click to collapse
Bro, there is no folder like /cache in my internal and external card...
Pls tell me, the correct path, i will show you immediately...
But, remember one thing my mobile is a rooted one before doing 4.3 update.. Is that the reason for this problem???
Give ans bro..

Try resetting your dalvik-cache... Use a file explorer with root access or adb shell and delete the folder dalvik-cache found inside /data (or rm -r -f /data/dalvik-cache from adb shell). Right after that you should reboot your phone (after deleting that folder all apps will start FCing, it's ok). In the next reboot the "Android is upgrading" screen will show and will take some time since it'll regenerate the cache. This should fix your problem.
If even after resetting dalvik-cache the same thing keep occurring, then inside /system/app you may have an .odex file for an .apk that contains classes.dex inside (e.g. you have an .odex for an APK that already is deodexed). It's common to occur when using apps like Lucky Patcher to apply patches or apps like Titanium Backup that allow integrating dalvik cache of apps inside system partition...

mbc07 said:
Try resetting your dalvik-cache... Use a file explorer with root access or adb shell and delete the folder dalvik-cache found inside /data (or rm -r -f /data/dalvik-cache from adb shell). Right after that you should reboot your phone (after deleting that folder all apps will start FCing, it's ok). In the next reboot the "Android is upgrading" screen will show and will take some time since it'll regenerate the cache. This should fix your problem.
If even after resetting dalvik-cache the same thing keep occurring, then inside /system/app you may have an .odex file for an .apk that contains classes.dex inside (e.g. you have an .odex for an APK that already is deodexed). It's common to occur when using apps like Lucky Patcher to apply patches or apps like Titanium Backup that allow integrating dalvik cache of apps inside system partition...
Click to expand...
Click to collapse
Thanks for ur response bro...
my root access is gone after the update..
now i cant able to use titanium backup or file explorer with root access..

ananthtcr said:
Thanks for ur response bro...
my root access is gone after the update..
now i cant able to use titanium backup or file explorer with root access..
Click to expand...
Click to collapse
If you updated without wiping data and cache it's very likely to be the cause of this problem, while you had root access one of those apps may have changed something in dalvik-cache and now that you don't have root access anymore Android keeps trying to "optimize" that app every time the phone boots...

Problem fixed!!!!!
I uninstall some apps which needs root acces and successfully deleted data/cache folder (Which is in hidden state earlier).
Now the Android Upgrading msg not coming..
Thanks Experts!!! You are really Great!!!
Specially thank to theperson333 and mbc07

android is upgrading on boot up
i did the above steps
wiped dalvik cache using cwm recovery
bt still problem persist
on boot up it show android is upgrading...
lemme tell what exactly happened from beginning
im using xperia l(4.2.2) with root access
i installed a keyboard ported from 4.4 to all xperia running jb.(for that i mounted system n flashed the zip using cwm recovery)
n keyboard is working fine bt problem is that
on every boot up
xl shows android is upgrading n takes 5 min to start..
i even searced for. dex app in system bt there is no app with that extension..

corrupted memory?

Hi guys have weird problem with my phone. Sometimes when I want to make nandroid I can see error 255 always on system partition . When I restore system partition I can do nandroid.
Next thing, when I want to delete any system app using titanium backup, after restart app is back again and im not getting free spacer in system partition. Also very often when I restore nandroid system doesn't want to boot, it just stuck on boot logo.
It is happening since last few weeks. What should I do to fix it?
Format all partitions then clean flash of rom?

joloxx9joloxx9 said:
Hi guys have weird problem with my phone. Sometimes when I want to make nandroid I can see error 255 always on system partition . When I restore system partition I can do nandroid.
Next thing, when I want to delete any system app using titanium backup, after restart app is back again and im not getting free spacer in system partition. Also very often when I restore nandroid system doesn't want to boot, it just stuck on boot logo.
It is happening since last few weeks. What should I do to fix it?
Format all partitions then clean flash of rom?
Click to expand...
Click to collapse
That would work if you arent rooted with otg ...the you could image the system and fix it on a Linux box with fsck
Sent from my ONEPLUS A3000 using Tapatalk

uudruid74 said:
That would work if you arent rooted with otg ...the you could image the system and fix it on a Linux box with fsck
Click to expand...
Click to collapse
Could you please tell me How can I fix IT?

joloxx9joloxx9 said:
Could you please tell me How can I fix IT?
Click to expand...
Click to collapse
The method you mentioned will work. Format everything and reload. I wish that recovery systems for Android supported fsck. Actually, if you have busybox installed, even under tmpfs, you might be able to get to a shell to run fsck. I can't try it now, but it worth a shot.
Sent from my ONEPLUS A3000 using Tapatalk

uudruid74 said:
The method you mentioned will work. Format everything and reload. I wish that recovery systems for Android supported fsck. Actually, if you have busybox installed, even under tmpfs, you might be able to get to a shell to run fsck. I can't try it now, but it worth a shot.
Click to expand...
Click to collapse
No Way to run fsck. I will try to format everything later then send files from PC and install fresh system on the phone.

joloxx9joloxx9 said:
No Way to run fsck. I will try to format everything later then send files from PC and install fresh system on the phone.
Click to expand...
Click to collapse
for future reference, there is a "Repair filesystem" option in twrp. It says it runs e2fsck, which works for ext4. It won't hurt an f2fs filesystem, but I don't think it will repair it either. I'm seriously considering switching my /data to ext4 just so I have proper recovery tools.
My OP3T does have fsck.f2fs on the system, which means you can fix your data by opening a Terminal session from TWRP and then running :
Code:
fsck.f2fs /dev/block/dm-0
should fix your data corruption should you see this error again. For ext4, you use e2fsck rather than fsck.f2fs. This is also what you would use on /system (which is /dev/block/sde20 on my phone) should that ever be mounted read/write and get corrupted (pretty low chance even if you do mount it read/write as writes are low frequency and ext4 has a rock solid journal).
WARNING: Device numbers are for my OP3T and may be different on other devices or even on non-US devices.

How to disable bloat wear on Qualcomm variants

So I found a way to disable apps that you can't disable through settings. There is an oem partition containing these apps so Titanium Backup can't locate them to delete, and trying to use a root file browser just freezes the device. You need to boot to twrp, click on mount and mount the oem partition. Next go to file manager and find the oem partition. Since these are not able to be backed up with twrp and they are separate from the system partition, I just renamed the apks with a ~ on the end. This way if the removal causes any issues you can just boot back to twrp and rename them back the way they were. Just be careful what you disable because I'm sure some of them are necessary. I'll play around and try to make a list of what can be disabled and maybe try to make a script to run in recovery to disable them.
Edit: since some users are unable to find the option to mount the /oem partition to debloat, I attached a couple zips to mount and make changes in twrp file manager and unmount afterwards.

Root file browser works, it freezes and all you do is force close the app and re do it and it works.

KyleBryant said:
Root file browser works, it freezes and all you do is force close the app and re do it and it works.
Click to expand...
Click to collapse
Doesn't work like that for me. The phone freezes completely.

amarc78 said:
So I found a way to disable apps that you can't disable through settings. There is an oem partition containing these apps so Titanium Backup can't locate them to delete, and trying to use a root file browser just freezes the device. You need to boot to twrp, click on mount and mount the oem partition. Next go to file manager and find the oem partition. Since these are not able to be backed up with twrp and they are separate from the system partition, I just renamed the apks with a ~ on the end. This way if the removal causes any issues you can just boot back to twrp and rename them back the way they were. Just be careful what you disable because I'm sure some of them are necessary. I'll play around and try to make a list of what can be disabled and maybe try to make a script to run in recovery to disable them.
Click to expand...
Click to collapse
I did find them through the OEM folder, can I just delete this folder through TWRP?

thereallinkieishere said:
I did find them through the OEM folder, can I just delete this folder through TWRP?
Click to expand...
Click to collapse
No! There are a few apps that are needed and you'll have big problems if you do. I would just rename them with a ~ or add .bak so if you have problems you can fiix it easily.
Sent from my LGLS755 using XDA Labs

amarc78 said:
No! There are a few apps that are needed and you'll have big problems if you do. I would just rename them with a ~ or add .bak so if you have problems you can fiix it easily.
Click to expand...
Click to collapse
I mean, that folder just has the apps I don't want...

thereallinkieishere said:
I mean, that folder just has the apps I don't want...
Click to expand...
Click to collapse
Yes. The whole folder with the Amazon apps can go.

amarc78 said:
Yes. The whole folder with the Amazon apps can go.
Click to expand...
Click to collapse
Yeah, that's what I want to get rid of but each time I try the phone freezes. Like, I don't wanna disable them. I want them gone. TWRP doesn't even open the OEM folder and there is no mount option for OEM so it's not like that's an option

thereallinkieishere said:
Yeah, that's what I want to get rid of but each time I try the phone freezes. Like, I don't wanna disable them. I want them gone. TWRP doesn't even open the OEM folder and there is no mount option for OEM so it's not like that's an option
Click to expand...
Click to collapse
Like I said in the first post, you have to mount the OEM folder. Select mount, then check the OEM box then go to file manager.

amarc78 said:
Like I said in the first post, you have to mount the OEM folder. Select mount, then check the OEM box then go to file manager.
Click to expand...
Click to collapse
What TWRP are you using? Mines doesn't have the option to mount OEM

squid2s

If you don't have root or an unlocked bootloader, you can use the Amazon Fire trick (To restore apps you simply factory reset).
-- Connect Device
Enable USB debugging in developers options
Code:
adb shell
-- List Apps
Code:
pm list packages
Alternatively, you can search for packages by name
-- Example
Code:
pm list packages amazon
-- Disable Apps
Code:
pm uninstall -k --user 0 [COLOR="Red"]"package name"[/COLOR]

If you want to disable the "No Sim Found" notification (its not hidable on Verizon ones at least) I found that its part of the moto setupwizard.
pm uninstall -k --user 0 com.motorola.setupwizard.phoneservice

I've found at least with Boost/ Sprint, you can do away with the whole oem partition. I removed the oem.prop and all the lines in the build.prop directing it to the oem.prop, and everything seems to work just fine. You just need to install a dialer since the stock Google dialer comes from there. I've also found that removing certain Google system apps causes PlayServices to crash when you do a factory reset, restore a system backup only with no data, or try to make a twrp flashable rom. I'm in the process of figuring out which ones need to remain and what can be removed without problems.

amarc78 said:
So I found a way to disable apps that you can't disable through settings. There is an oem partition containing these apps so Titanium Backup can't locate them to delete, and trying to use a root file browser just freezes the device. You need to boot to twrp, click on mount and mount the oem partition. Next go to file manager and find the oem partition. Since these are not able to be backed up with twrp and they are separate from the system partition, I just renamed the apks with a ~ on the end. This way if the removal causes any issues you can just boot back to twrp and rename them back the way they were. Just be careful what you disable because I'm sure some of them are necessary. I'll play around and try to make a list of what can be disabled and maybe try to make a script to run in recovery to disable them.
Edit: since some users are unable to find the option to mount the /oem partition to debloat, I attached a couple zips to mount and make changes in twrp file manager and unmount afterwards.
Click to expand...
Click to collapse
Confirming this DOES NOT work on the XT1765 Metro PCS version. Started a thread just for that phone as it seems to be the special one in the bunch.

So to clarify...
Boot twrp
Flash mount_oem.zip
Delete/alter file name of unwanted apks
OR
Delete oem partition
Flash unmount_oem.zip
Reboot
IF I delete whole partition, I must install a new dialer.
Any recommendations for new dialer app?
Edit:
IF I just delete individual apks, is boost launcher safe to remove? As in with out installing new dialer.

Thexmastermind said:
So to clarify...
Boot twrp
Flash mount_oem.zip
Delete/alter file name of unwanted apks
OR
Delete oem partition
Flash unmount_oem.zip
Reboot
IF I delete whole partition, I must install a new dialer.
Any recommendations for new dialer app?
Edit:
IF I just delete individual apks, is boost launcher safe to remove? As in with out installing new dialer.
Click to expand...
Click to collapse
He also said he removed oem.prop and all buildprop lines directing to oem.prop. (for deleting oem)

Right on. Would it be possible to redownload& install Google dialer via play store?

Thexmastermind said:
Right on. Would it be possible to redownload& install Google dialer via play store?
Click to expand...
Click to collapse
Don't see why not. Although the one originally included is slightly different.

Play store says phone is uncertified, so I can't download phone from Google. 3rd party works just fine, so do pretty much all other Google apps that I can see. This is just deleting OEM folder, not build.prop lines leading to OEM. I'm still kinda fresh and haven't really done that before, but I've got the firmware I can reflash so I'll try it tonight when I get home. Anything I need to know about build.prop?
Edit: I removed build.prop lines leading to oem. No noticeable difference. I reflashrd stock firmware. Get this: my phone would ring when I was called, but no app would let me answer lol third party dialer would let me make calls but not answer or hangup.

Installing LOS 15.1 on Nexus 4 with open GApps no longer possible??

Hi, what are the storage requirements for the /system partition for LOS 15.1?
I tried upgrading LOS 14.1 + opengapps nano to 15.1 + opengapps nano after the updater notified me of availability.
Initial attempt to upgrade the system ended in failure (made apparent with opengapps installer, not LOS) which I tracked down to the LOS installer completely exhausting the free space on /system - the build.prop file was empty and opengapps refused to install, citing incorrect SDK version.
So next I tried wiping the /system partition and then installing both again - LOS installer finished successfully, but this left free space of only ~120 MiB, not enough for opengapps nano. Is it expected that a fresh install of LOS without opengapps takes ~700MiB?

I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.

st3v3ntehl33t said:
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
Click to expand...
Click to collapse
Sorry, can't quickly try that - already reverted the device to the backup of 14.1 Do you mean you had to delete stock LOS apps to even install the pico opengapps package?
According to description, the diff between pico and nano is Health services and Google search, neither of which is installable from the play store, AFAICT (and would prefer to leave them in). Is there an option for a proper solution, eg. repartitioning the flash so that the system partition is big enough to hold it all? (How big is the system partition on phones factory-shipped with Android 8.1, anyway?)

Yes, that's correct there's not enough space to install gapps with all the factory apps installed. It was asked how this ROM could even go official with lineage when you have to do this work around to get play store functionality but technically having the play store is not a requirement for lineage os. (There's other options). Afaik it's only an issue because of the size of the actual system allocated area (call it a partition if you want) on the Nexus 4 itself. After you get it installed you can install apps to replace the ones you deleted.

Glad I found this post. Thanks for the details, because I was going around in circles trying to figure out what could be wrong.
While GApps are technically not "required", not allowing space for their install - which is likely very common - seems very short-sighted. Furthermore, the Install page offers the option (instructions) of flashing the GApps zip. If they're not going to leave any room for it, they should either document that, or mention that they didn't leave any room for you to do it. And really, the partition should just be sized big enough to allow for it.

st3v3ntehl33t said:
I used pico. Wipe the system area, install the nightly, Mount system, delete system/app/jelly or system/app/email and then install gapps.
Click to expand...
Click to collapse
Thank you, pico actually worked!

To anyone is still not on LOS 15:
Repartitioning is fairly simple (although time-consuming, expect the data transfers to/from PC to take ~90 minutes in total), as the device's storage uses plain GPT as a partitioning scheme. Reposting my answer on stackexchange:
I eventually found this thread, where the author prepared an archive with gdisk and a few other tools.
Requirements:
Computer/VM with adb, fsck.ext4 and resize2fs
This zip file
Overview
The relevant partitions (system and userdata) are 21st and 23rd on the storage. The 22nd partition is just cache, so there's no harm nuking it, and making a new one after data from the other 2 are in place.
The TL;DR version of the procedure is:
boot into recovery, unmount everything
pull the data partition to computer
Code:
[PC] adb pull /dev/block/mmcblk0p23 userdata.img
put gdisk on the phone, and use it to modify the partition table - grow system while retaining its starting sector, shrink userdata by the same amount, and re-create cache between them
Code:
[PC] adb push gdisk /tmp/
[adb-shell] /tmp/gdisk /dev/block/mmcblk0
...
use resize2fs on the phone with the system partition to grow it
use resize2fs on the computer with the userdata partition's image to shrink it to appropriate size
push the modified data image to the phone
Code:
[PC] adb push userdata.img /dev/block/mmcblk0p23
format the cache partition, reboot into system
EDIT: I'm intentionally leaving out the details of what to do with gdisk, as I think using sgdisk's output and a text editor to just change the partition boundaries is the proper way to do this. If you really want and need some hints though:
On the phone, all of the affected partitions started on 8MiB-aligned sectors, and I maintained the alignment after the resize. It also makes specifying the new size to resize2fs straightforward
Partition name in the GPT, and unique GUID should be maintained after resize.

Oh, and regarding LOS-15 installation, the installer will image the system partition with original, 840MiB filesystem, and won't grow it, so subsequent g-apps installation will fail. It's necessary to grow the filesystem manually and then install g-apps.

myxal said:
push the modified data image to the phone
Code:
[PC] adb push userdata.img /dev/block/mmcblk0p23
Click to expand...
Click to collapse
putting aside missing information about how to get and use sgdisk (or gdisk) you're also not saying what modification has to be done to userdata.img and if this modification works with encrypted /data

rotanid said:
putting aside missing information about how to get and use sgdisk (or gdisk) you're also not saying what modification has to be done to userdata.img and if this modification works with encrypted /data
Click to expand...
Click to collapse
The modification referred in point 6 is the shrinking done in point 5. I have no experience with encrypted /data (or knowledge how that is implemented, for that matter), so I don't know what extra steps would be needed in that setup.

myxal said:
The modification referred in point 6 is the shrinking done in point 5. I have no experience with encrypted /data (or knowledge how that is implemented, for that matter), so I don't know what extra steps would be needed in that setup.
Click to expand...
Click to collapse
oh, thanks for the fast reply!
in that case, i think it's not possible to keep the data if it's encrypted, because you can't decrypt it on the PC to be able to shrink it