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?
DISCLAIMER: <insert generic XDA disclaimer here>
Hey guys, first things first. I'm not a programmer/dev or even clever so bear this in mind when trying this.
I wanna share a Tasker with you all that when used in conjunction with PhilZ Touch 4.88.5 Touch Enhanced CWM 6.0.2.9 Recovery and anopen recovery script can allow your phone to perform a NAND backup while you sleep or whenever you want.
Philz has managed to get ors working in his recovery which means that the recovery with be able to perform custom backup jobs once you select them in recovery and run them. Now, READ this aboutopen recovery script to find out about ors because I'm not one for giving fish to men, rather teach them to fish! Read it? Good... moving on...
The ors support is great but having to select them and run them is not so great for me and that is where this trick comes in handy.
What this task does...
It copies an already created (user created) ors script to /cache/recovery, deletes the previously backed up backup folder (if any), reboots into recovery (provided you have 50% battery). Recovery then runs the script, backs up and reboots into the ROM. If at boot, the backup was made, a notification comes up telling you this and the time it was done at and also writes this to a log file in /mnt/sdcard0/clockworkmod.
I'll leave it up to you to figure the tasks out and how they work if you want a better understanding.
Quick tip:
The backup folder is set to clockworkmod>backup BUT the sdcard to which the backup is made is selectable in recovery under: Backup and restore>Misc Nandroid Settings>ORS Backup Target. So in other words you can't define /mnt/sdcard0/SILLY/NOOB as the backup folder, it can only be either /mnt/sdcard0/clockworkmod/backup/*my folder* or /mnt/extsdcard/clockworkmod/backup/*my folder*. This being said, all you need to do is define the *my folder* name under /mnt/*/clockworkmod/backup/*my folder* in the script which could just be /Tasker_Backup Capeesh?
Another thing that I must mention is my reason for creating a openrecoveryscript file and copying it to /cache/recovery rather than just writing a file directly into /cache/recovery is that it seems like either Tasker or Android doesn't like creating a file directly in /cache/recovery but doesn't seem to mind copying a file to the location.
Instructions:
1.You need to create a file on your sdcard called openrecoveryscript.txt in a place you will remember (I put mine in the mnt/sdcard0/clockworkmod)
2.Once you created the file, open it and enter your backup job, the order in which you enter your commands aren't important, any permutation will do (BDASC or ASDBC).
3.When you're done, save the file and REMOVE the ".txt" extension.
4.Import my Tasker profiles (NAND backup and NAND notify) into Tasker and open the task "NAND backup" and edit the path in the 9th and 11th action to the clockworkmod folder on either the local or external sdcard. (depending on the selection that you made under: Backup and restore>Misc Nandroid Settings>ORS Backup Target)
5.Set the time and date that you want the backup happen on.
6.Thats it!
Suggestions:
I would advise against setting the internal sdcard as the backup location because replacing an external sd is far easier than replacing an internal one when it burns out from large amounts of writes in addition to this, I would recommend backing up about once per week (depending on your addiction to flash) to reduce the strain on the sdcard. But this is only my suggestion.
Attached is a zip of the profiles and the ors that I use, just remember to remove the ".txt" from the "openrecoveryscrip.txt" before using it.
DON'T FLASH IT, IT IS NOT A CWM ZIP!!
This is by no means perfect but rather to provide a point of departure in helping others create similar tasks to automate their backups to their preference so please rename, delete and add as much as you like. Maybe post your findings too!
Remember, if you don't understand do the following (in order): search, read, think, SEARCH, READ, THINK, SEARCH!, READ!, THINK! ask.
Good luck
I would like to give credit to
Phil3759 for developing a great recovery that makes the whole party possible.
rootSU for his post which is far more thought out than mine but none the less got me'a thinkin.
Thank you for the guide (my 8 :good: are done today...)
I just add this so people do not browse much:
The file /cache/recovery/openrecoveryscript
Code:
backup SDCR123BAEOM foldername_not_full_path
S System partition
D Data partition
C Cache partition
R Recovery partition
1 Special partition 1
2 Special partition 2
3 Special partition 3
B Boot (kernel) partition
A .android_secure
E sd-ext partition
O Enable backup compression
M Do not create MD5sums
foldername Optional (if not specified, a folder with timestamp is created, so you do not have to delete previous folder)
Currently, 1, 2 and 3 are not supported. I could assign modem and efs to them later, but I do not think it is really useful
I have a backup made with TWRP 2.6.0.0 of boot/data/system that were saved as .ext4.win files by booting into TWRP and doing a backup.
However, when I tried to browse the file using Nandroid Manager 1.4.1, most (but not all) of the app directories in /data/data/{packagename} are missing their actual data. They have a lib dir that's a <link>, but nothing else. However, some apps DO appear to have their normal and expected data. I could understand if NONE of them did... but I'm mystified as to how SOME could have data, but others that I know for a fact store data in /data/data/{packagename} are coming up empty.
I can think of a few possibilities:
* For some bizarre reason, TWRP didn't back up the files for certain apps. Unlikely, unless Illusion 4.2.2 (based on SlimRom/AOSP 4.2) was doing something weird with symlinks that confused it.
* Nandroid Manager 1.4.1 mangled the backup files while uncompressing them. Oh ${deity}, I hope this isn't the case. It never even occurred to me that it might try to uncompress the originals "in-place" and delete the original copy when I ran it and gave it the OK to uncompress them first.
* Nandroid Manager 1.4.1 uncompressed them fine, but for whatever reason can't explore the uncompressed backup properly.
I copied the .ext4.win files to Windows and tried finding something that can explore them, but I'm coming up blank. I tried ext2explore from Sourceforge, but it silently ignores me when I try to browse to the .ext.win file as a filesystem to mount.
Any ideas what to try next, either Android-side (Nandroid Manager 1.4.1 itself is the problem, and hopefully didn't mangle the backups themselves by attempting to uncompress them) or Windows-side?
Update: I have another theory. At the time I did the backup, my phone was bootlooping (it made it up to the converging-diverging RGB spotlight animation, then stayed there forever). To reboot, I had to 3-finger it (power+home+down or up, don't remember which one I used at the time).
I'm wondering whether it might be a case of TWRP backing up the raw image of a dirty ext4 partition that had uncommitted data in the journal, and the recovery tools that I'm using to explore it for individual files are blindly mounting it like an ext2 volume & causing any file written by an actively-running application to show up as "gone" instead of showing the old version.
If that's the case, would treating the .ext4.win file like the output of 'dd', then running an ext4 repair tool on it, be likely to fix it? I'm somewhat familiar with issues like this, but I've never actually had to deal with one head-on, so I'm a total n00b when it comes to the details of mounting a Linux filesystem from a dump file and allowing Linux to fix it as if it were rebooted into a dirty filesystem.
Hello guys!
I want to format everything and give a fresh start on my GNexus. I am finding it very laggy and I think that the problem is on using the same app backup for almost an year. I make the full backup in the recovery and after wiping everything and installing a new rom, I restore everything. I believe that there are many apps in my phone that I don't use anymore and are there as trash that needs to be cleaned...
I know about Titanium Backup, but I'm on ART and I never learned how to use the damn program correctly, so there is much complication to just backup some apps. What I really need is a method for backing up JUST the data (ex: the savedata from the games) and not the apk. So that I can wipe everything in the phone (all the partitions), install the rom and fixes and everything and then intall via google play the apps again and put the backed data in its place again.
I don't know if I made myself clear, maybe I'm just complicating, but if you play or played roms on an emulator, you have the rom and its save. I want to backup the save file, delete the rom and the emulator itself. Then install the emulator again (clean install), donwload the roms (clean ones) and put the old save in the place. :good:
Well, thanks in advance :laugh:
Rayaxe said:
I know about Titanium Backup, but I'm on ART and I never learned how to use the damn program correctly,
Click to expand...
Click to collapse
Titanium works on ART now, as is my understanding. It's not complicated to learn. Just select the app and hit backup, and Bingo Bango, you're done.
Then when you restore, you can select just data.
Piece of cake, ace.
yeah, I finnaly made it, my problem was ART, I didn't notice they updated the app ehehe
thanks
Yeah I personally don't recommend tibu. I've tried it myself and had issues related to Android version at the time and I just see this over and over. The other thing is that there are excellent options available without an app. My favorites for backing up just /data/data/<app_data_dir> are:
Code:
#> cp -a /data/data <backup_location>
OR you can use
Code:
#> adb backup -noapk -all
Type adb in terminal on phone or on computer to see more info for this one, that's basically it though. You can use adb to backup directly onto your phone or computer, very useful when you need some space!!
The most important thing though when you're backing up data is to preserve permissions and be able to set new ones for data if the apk owner "id" changes, e.g. app re-installations. Otherwise you'll run into some pretty bad problems.. not so fun. So definitely use a tar archive for file permissions preservation and some fast lzma lzop compression on top of the tar archive. 'busybox tar' usually has all of these options. A lot of roms' busybox and functions get stubbed and made useless, so I would check out Terminal IDE if you want to go this route. 'Definitely want the full gnu options and consistency. Vanir by itself is also good here, and I use it 24/7 for this reason. It really does have a hemi, they're not kidding.
7175 said:
Yeah I personally don't recommend tibu. I've tried it myself and had issues related to Android version at the time and I just see this over and over. The other thing is that there are excellent options available without an app. My favorites for backing up just /data/data/<app_data_dir> are:
Code:
#> cp -a /data/data <backup_location>
OR you can use
Code:
#> adb backup -noapk -all
Type adb in terminal on phone or on computer to see more info for this one, that's basically it though. You can use adb to backup directly onto your phone or computer, very useful when you need some space!!
The most important thing though when you're backing up data is to preserve permissions and be able to set new ones for data if the apk owner "id" changes, e.g. app re-installations. Otherwise you'll run into some pretty bad problems.. not so fun. So definitely use a tar archive for file permissions preservation and some fast lzma lzop compression on top of the tar archive. 'busybox tar' usually has all of these options. A lot of roms' busybox and functions get stubbed and made useless, so I would check out Terminal IDE if you want to go this route. 'Definitely want the full gnu options and consistency. Vanir by itself is also good here, and I use it 24/7 for this reason. It really does have a hemi, they're not kidding.
Click to expand...
Click to collapse
looking for this method, very nice!
thanks, next time I need to backup I will use this xd
Since we do not have TWRP, our options for backing up and restoring our data is limited. I use Titanium Backup Pro, but recently ran into issues with libmtp when trying to copy the ttbu folder from my sdcard to my computer. So I decided to use adb backup and restore instead. It worked very well, so I decided to write some scripts to make it easier. Now I will share them here.
These scripts were written in Linux and meant to be used in Linux. If you are versed in scipts for windows (.bat), please feel free to use my scripts as a guideline.
You can clone the repo here
android_backup_restore
Before doing anything, I strongly suggested reading the README.md first.
The scripts are a little rough right now, as they are a WIP. But they work just fine.
Hi ! Thanks for the thread. It's possible toi use it on OsX ? I do to convert script for run on terminal ? Or just use shell ? I'm not an expert. Thanks