Develop Bugs

[HELP] Apps force closing like crazy

Today I just tried to install some fonts using Root Explorer and all of a sudden I was stuck in boot loops. So I tried to boot into recovery mode and there was an update.zip on my device (probably from when I was originally rooting) which I think the recovery mode ran. After that, I was in clockwork and I flashed a new font.zip file and that still left me in a boot loop state.
I fixed the boot loop by manually changing permissions on DroidSans.ttf and DroidSans-Bold.ttf to match the other fonts and change owner/group to root:root.
This stopped the boot loop but now every time I boot my phone it force closes all my apps that were previously on sd. I'm not sure why this is happening and it might be other apps that are also not on my sd. It is also not showing all of my installed apps and Launcherpro no longer runs and I am stuck with default htc sense launcher. I would prefer to not wipe the entire phone to fix this.
I have tried a different sd card with the same data and I have also tried formatting the sd card and copying my files back on. Still stuck with force close errors. I am not sure what to do at this point. Any help?

Try fix permissions.

I have tried running the fix_permissions script. Didn't seem to work. Unless there's another method you are referring to. I am unable to launch ROM Manager and it seems like all of my apps are 'new' and never launched before from what they show. Including my alarm settings, those are missing too.

Think I'd restore a backup taken prior to all the font changes. You did make a backup, didn't you?
________________________________
Unrevoked forever
SkyRaider Sense 3.5
Radio 2.15.00.09.01

rigman said:
Think I'd restore a backup taken prior to all the font changes. You did make a backup, didn't you?
________________________________
Unrevoked forever
SkyRaider Sense 3.5
Radio 2.15.00.09.01
Click to expand...
Click to collapse
I do have a backup but unfortunately its a little bit old and I would rather fix this if possible. It feels like some folder is missing permissions. Because even stock Google talk crashes and market crashes when I try to view an app but I can search around if I want.
Another route I can go is to backup my data for apps and then install a new Rom as I have been wanting to. This would allow me to fix my problems but I need to know what folders I have to manually backup for saves.

Well some good news. After messing around with permissions on some files on the sdcard I was able to restore my notification sound back and also able to make GTalk work properly. So it looks like there is hope yet.
Where do apps store settings such as configuration, db, etc?

It looks as if my data/data partition is wiped? I'm not sure what happened but I guess that means all my app saves are gone.
Am I right to assume that?

I used this application NotEnoughSpace made by a xda member and using it to symlink some of my apps from data partition to a new area on emmc seems to work. However when I try to restore back to my data partition, it doesn't work.
So this leads me to believe that the permissions on my data partition are off and I need to change the permissions, owner, and group for the data partition and all files inside it. The command would be:
Code:
chmod 664 data/*
chown root:root data/*
And run this while outside of the main data folder. As long as the right owner/group is root:root.
Can someone confirm?

[Q] Desire GSM / CM7.1 / App2SD / Market issues

Hi all.
I've been running CM7.1 on my Desire GSM for a couple of weeks without any issues. Tonight I tried partitioning my SD card to get more app space and I seem to have come unstuck.
Here's the process I used...
Full nandroid backup using ClockworkMod recovery
Wipe data & cache, install CM7.1 stable and GApps from zip on SD
After first run, reboot into recovery
Partition SD card from ClockworkMod Recovery menu - partition size 1024 MB, swap size 0 MB
Reboot & attempt to access Market
At this point I get a host of errors - Google Talk begins to complain that it can't login to my account (never used Google Talk so this is the first time it's even come to my attention), and anything I try to download from the Market gives me a "[app name] could not be downloaded due to an error" message.
At this point I copied the .apk file I had backed up for Titanium Backup to my SD card and attempted to install manually - the install claimed to work, but Titanium Backup was not then available from my app drawer, as though it hadn't been installed at all.
My suspicion is that somehow I've cocked up the partitioning and the system is unable to read or write sd-ext. But I can't see that I've done anything wrong - though I'm new to all this, so there's every chance that I've missed something obvious.
Right now I'm restoring from my last Nandroid backup since, well, I need my phone and this can wait for the time being.
Any help that anyone can offer is appreciated.
Miz.

Flash this DarkTremor A2SD Script - http://box.net/files#/files/0/f/121132533/1/f_981313987
Then install A2SD Gui from market and set everything you like.

Cheers. Can't access that script though - "The item you are trying to access has either been deleted or is unavailable to you."
Will install A2SDGUI next chance I get.

A2SD Gui will not work without the script.
Try this link: http://www.box.net/shared/y9m9qap51mekqvl2kk29

Thanks, will give it a shot and report back on the results.

Worked like a charm. Thanks for the info, all looking great now - including oodles of app space.
Miz.
Sent from my HTC Desire using XDA App

Please use the Q&A Forum for questions Thanks
Moving to Q&A

Much appreciated, but we're done now.

[Q] Busybox messed up

Currently I can't any of the busybox installers to reinstall it, they
all report not able to get root immediately after superuser says
it has root privs.
Can I push the busybox executable to /system/xbin manually?
Would I do better to just reflash the rom, over the existing one,
(running install-script will put back busybox and and symlinks).
help

Are you able to get su permission for other apps still?
You can push it manualy to /system/bin or /system/xbin, just make sure to set the correct permissions owner and group. rwxr-x-r-x and root for owner and group.

[Resolved] I ended up restarting with a wipe and new rom install
It was just to complicated due to so many basic functions
being in the busybox binary.
I did a TiBu of my apps and system data and exported people data
to a vcf. Wiped and re-installed the rom, restored my export of the
people data, restored my apps+data and system data. rebooted,
installed a ext4 compatible kernel, rebooted, installed the ext4 no
data limit (/data/data to /data), rebooted, installed the ext4 kernel
again, (as the ext4 zip puts its own), rebooted, installed the UOT
Kitchen Circle Battery, installed the zip to fix recticle & recurring
warning box, rebooted, setup people group for full page people
widget, rebooted to recovery to run a new nandroid after all the
patching was done.
*sigh*
Tedious, but everything is working as I'd planned .

[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?

[Q] KitKANG 4.4 by spezi77 - how to remove INT2EXT4 script properly?

Hi all,
i was testing this ROM and it works pretty well for a pre-alpha release. Actually there is a known issue (Settings / Apps / Properties -> FC) that is driving me nuts... I really need to open the Properties to move certain apps to "internal".
There are a couple of apps natively installing parts on SD card, for example Final Fantasy 4 or the XDA developers app. For whatever weird reason when the phone is rebooting these apps are completely disappearing and need to be reinstalled from the Playstore. This is happening to all apps which are "on SD card" in Settings / Apps.
So far i could not figure out why these apps are disappearing, but i believe the Properties FC is related to the INT2EXT4 script. I tried removing the script from init.d folder in the zip file to use Mounts2SD from Playstore instead. Did a full wipe and reinstalled, but then everything was force closing at setup wizard sceen.
Is it possible to remove the INT2EXT4 script from this ROM without crippling it completely? If yes, what is the procedure to remove it properly?
Any help would be appreciated.

Thanks for opening up a Q&A thread.
To remove INT2EXT and make a full restore of A2SD, you have to
1. remove 40int2ext from system/init.d/
2. copy the following files from any JB rom with A2SD support:
- system/init.d/03sdcard
- system/init.d/10apps2sd
- system/bin/a2sd
Click to expand...
Click to collapse
I hope this will solve your problem.

Another thing to check, how did you partition your sd card? Should be done with 4EXT recovery or gparted only (not minitool)
Backup and repartition your sd card if it's not done with those methods. One FAT32 partition, one 1.5-2GB max ext4 partition, no need for swap even though I think it says in OP.
To get around apps installing partially on sd card you could try a couple of things instead of replacing the script as it should work:
- Use titanium backup, long press an app and to move them to 'internal' to move to sd-ext, gets around having to navigate app settings
- I believe the ROM comes bundled with Xposed? Find a module called Modaco Toolkit, has a system option to 'Disable Forward Lock' which should prevent auto installation of apps to SD card (it works for me on Nexus devices preventing apps installing to virtual /mnt/asec sdcard partition, not tested with a real SD card but I believe the principle is the same, try it). If this method works, it's cleaner as apps should always get installed to 'internal' (sd-ext) in the first place.

spezi77 said:
Thanks for opening up a Q&A thread.
To remove INT2EXT you have only to remove it from system/init.d/
But you will have to copy 03sdcard into system/init.d/ folder. This script comes along with a2sd and is responsible for mounting the sd-ext.
I hope this will solve your problem. If not you should insert the following files for a full restore of a2sd:
- system/init.d/03sdcard
- system/init.d/10apps2sd
- system/bin/a2sd
Click to expand...
Click to collapse
Thanks for the quick response.
Tried your suggestion without success. As soon as I remove INT2EXT from init.d in the zip file ROM is going crazy force closing everything after fresh installation. Very strange... Restoring A2SD didnt help either. Is it only me or is it reproducible for other users?

eddiehk6 said:
Another thing to check, how did you partition your sd card? Should be done with 4EXT recovery or gparted only (not minitool)
Backup and repartition your sd card if it's not done with those methods. One FAT32 partition, one 1.5-2GB max ext4 partition, no need for swap even though I think it says in OP.
To get around apps installing partially on sd card you could try a couple of things instead of replacing the script as it should work:
- Use titanium backup, long press an app and to move them to 'internal' to move to sd-ext, gets around having to navigate app settings
- I believe the ROM comes bundled with Xposed? Find a module called Modaco Toolkit, has a system option to 'Disable Forward Lock' which should prevent auto installation of apps to SD card (it works for me on Nexus devices preventing apps installing to virtual /mnt/asec sdcard partition, not tested with a real SD card but I believe the principle is the same, try it). If this method works, it's cleaner as apps should always get installed to 'internal' (sd-ext) in the first place.
Click to expand...
Click to collapse
1 GB sd-ext partition created with 4EXT, no swap. Had bad experience with minitool and even gparted so I always use 4EXT for partitioning. Works fine for every other JB or ICS ROM.
***facepalm*** YES OF COURSE TB!! - that's the workaround, shame on me... Sometimes you don't see the wood for the trees...
BTW with Xposed and Gravity / Modaco toolkit Final Fantasy 4 refused to start, I had to remove both modules to get it working again.
Thanks a lot for driving me to the right direction, I'm fine with the workaround for now.

Siluxsept said:
Thanks for the quick response.
Tried your suggestion without success. As soon as I remove INT2EXT from init.d in the zip file ROM is going crazy force closing everything after fresh installation. Very strange... Restoring A2SD didnt help either. Is it only me or is it reproducible for other users?
Click to expand...
Click to collapse
Did you make those changes directly on your device? If yes, I suppose to modify the .zip instead and then flash it after doing a full wipe.

spezi77 said:
Did you make those changes directly on your device? If yes, I suppose to modify the .zip instead and then flash it after doing a full wipe.
Click to expand...
Click to collapse
No I did not change anything at OS level - that's the weird thing, i always adjust the zip file and flash it after full wipe.

Siluxsept said:
No I did not change anything at OS level - that's the weird thing, i always adjust the zip file and flash it after full wipe.
Click to expand...
Click to collapse
Tested one more time with a fresh download. As soon as I remove int2ext from zip file and flash it after full wipe all apps are force closing at setup wizard screen.

Siluxsept said:
Tested one more time with a fresh download. As soon as I remove int2ext from zip file and flash it after full wipe all apps are force closing at setup wizard screen.
Click to expand...
Click to collapse
That's really strange. However, thanks for your feedback. For the next version, I will create two variants of the rom (a2sd/int2ext).