This is a work-in-progress report. I found a cool way to save internal memory: one can delete native libraries from apks after the apks have been installed. When an apk is installed, the native libraries are put in /data/data/*/lib, and if you delete the lib from the apk file in /data/app, everything works fine. Signatures don't seem to matter here.
This is particularly useful for apps most of whose memory usage is the native libraries.
OK, I've only tried it with one app.
Ooops: Normally, the /data/data/app.name/lib directory gets deleted on reboot to match the shorn apk file.
But this can be prevented by setting /data/data/app.name/lib and /data/data/app.name/lib/* to read only (chmod 555).
In case anybody wants to try with this, here's how you can do it. Of course, you need root.
Download my Android commandline build of zip. Install it in /bin and make it executable (chmod 755 /bin/zip). If you don't want to or can't make /bin writeable, install it in /data/local, and then call it explicitly as /data/local/zip
In the shell, do:
Code:
su
cd /data/data/app.name
(Where of course "app.name" is the name of the app.) Make sure there is something in the lib/ folder, or you won't save any space. Make the libraries read-only:
Code:
chmod 555 lib lib/*
Then delete the libraries from the apk:
Code:
cd /data/app
zip -d app.name*.apk lib lib/*
(You can replace the first * with a -1 or -2 or the like suffix, which gets added by the installer.)
And you're done. The apk is now thinner, and the libraries are still usable as they've already been extracted to /data/data/app.name/lib
If your app was moved to SD using Froyo (or higher?), you will need to do something a little more complicated. After you've made the libraries read-only, you'll need to remount the app directory read-write, and then zip:
Code:
mount -o rw,remount /mnt/asec/app.name*
cd /mnt/asec/app.name*
zip -d pkg.apk lib lib/*
Run the app, then reboot to see if it still works. If not, uninstall and reinstall the app.
You can save pretty serious amounts of memory this way. The libs in some graphics-intensive apps, like games, are most of the apk. I've seen apks that shrink from about 2mb to about 200k or from about 7mb to about 2mb after this procedure. Particularly bloated are apps that include two different versions of the libraries, for different CPUs.
A happy thing is that you can still move the shorn app to SD (at least with my Force2SD--I haven't tried with the OS's own function).
Interestingly, the uninstaller can still delete the app, despite the procedure, which is nice. I don't yet know what happens when you try to upgrade after this.
It would be easy to write an app that does this, or to integrate it into Force2SD. I am not sure I am going to bother.
For further savings, you can remount your sdcard as exec (I have a utility that does that if anybody is interested), move the library from /data/data/app.name/lib to your sdcard and then link to that. I have a script that automates that procedure. I've done it for a few apps that have large libraries (Angry Birds is a nice example).
Another update: This actually works very reliably. I've deleted the libraries from a bunch of apks using the above method, and things continue to work just fine.
is there an app or a script that can do this?
it is really painfull to do this with +100 apps :silly:
What happens when I update the app using play store. Is it works ?
And if it is working, does it download more data than usual to get an upgrade?
Sent from my HTC Desire X using XDA Free mobile app
ashifashraf5 said:
What happens when I update the app using play store. Is it works ?
And if it is working, does it download more data than usual to get an upgrade?
Sent from my HTC Desire X using XDA Free mobile app
Click to expand...
Click to collapse
When you update, this would need to be done again.
I have no idea if this still works on current Android versions anyway.
@arpruss
I'm doing this to my system apps currently. I use an zip explorer and just move the lib files needed to system/lib and deletes the lib folders from Apk. There is no problem of clearing of lib files at start up for this thogh. I Set the permissions to read write.
Sent from my HTC Desire X using XDA Free mobile app
---------- Post added at 05:21 PM ---------- Previous post was at 05:18 PM ----------
I like to know if the updates download more data than the normal case. What I mean is , when we updates app by play store it only download a portion of files. I like to know if this is affected by removing lib files
Sent from my HTC Desire X using XDA Free mobile app
ashifashraf5 said:
@arpruss
I'm doing this to my system apps currently. I use an zip explorer and just move the lib files needed to system/lib and deletes the lib folders from Apk. There is no problem of clearing of lib files at start up for this thogh. I Set the permissions to read write.
Click to expand...
Click to collapse
If you move the lib files to system/lib, the apps won't upgrade properly.
I have some more observations:
- On 2.3, the /data/data/*/lib directory gets cleared on reboot if the apk has had its libraries deleted. It doesn't matter what the permissions on the libraries are.
- On 4.3 and 4.4, things work great, and you don't need to change permissions at all. (I don't have rooted 4.0-4.2 devices for testing.)
- Many apps from the Amazon Appstore have a security check that makes them fail if the apk is modified.
- Moving the library-shorn apk to SD causes the libraries to disappear. I don't think the permissions matter here (but haven't tested).
It would be nice to have data from rooted 4.0, 4.1 and 4.2 devices. I guess I could play around with an emulator.
I am thinking of integrating this functionality into my Force2SD app. I would probably make this functionality available in the free version.
Anyone has tried this with 4.0 ?
benibela said:
Anyone has tried this with 4.0 ?
Click to expand...
Click to collapse
I think I tried something like this with 4.3 or 4.4 and it worked.
Yes, you said that already.
But I need to know it for 4.0.4. My stupid bank has a must-use-app for online banking with 20 MB libs that are only there to prevent it from running on a rooted device. And if it detects a modification, it self-destructs.
Nevermind. I tried it with my own app and it worked. With permission change, did not try without
I have Android 8.1.0, Xiaomi Redmi 5 Plus.
I am modifying the files in "lib" directories (such as /data/data/com.application.name/lib/) of few specified applications.
Rarely the files from the "lib" directory get overwritten with the content from APK archive of these applications. The "lib" gets restored from APK archive sometimes (maybe after 2 weeks or so).
It's important for my project to learn about the problem of Android restoring the "lib" directory.
I would like see what part of Android is responsible for this. I want to know which script or executable file in Android is responsible for restoration of "lib" directory.
Hopefully someone out there knows something about it.
i found a better way to remove lib folder from apk to get more free space https://forum.xda-developers.com/android/general/guide-t4080131
Hello all.
All of my mobile devices are Samsung devices (2 Phones and 2 Tablets) all but one device is rooted, and all are on stock Lollipop ROM. I have went through my phone (Note 3) and removed all the bloatware and have it pretty trim and fit. I want to do the same also for my tablet (Galaxy Tab S). I poured over a bunch of safe to remove type lists and compiled a list of what I could remove and tested things out on my phone. All went well until I got to KNOX and I guess I got a little aggressive (searched for everything with 'knox' in it and deleted what I could), and when I rebooted it got stuck on the boot sequence. No idea why. So I wiped and started over and then used Uninstall ROOT from the Playstore and just deleted the Knox entries that showed up there and that worked better.
Once I was happy that all was working as it should I installed all the normal apps that I use and things have been working perfectly. So I turned my attention to the tablet. I used the list of bloatware from my phone and found, as would be expected, there was much the same with respect to the bloatware just different names.
On my phone, in order to remove the .apk file and the odex files I just deleted the folder since they were in the same place. The odex files were in a sub-folder named 'arm'. I thought with the tablet it would just be easier to use some kind of script run from recovery to delete all the folders and be done with it in a matter of a minute or two if that long instead of doing it manually. To my surprise I found one already made that even used the Aroma installer so you could just select what you wanted to remove, which seemed perfect, except it didn't work. It was removing nothing despite the fact when the script ran it looked like it was doing all it should. Looking at the script that ran, some of the file names were wrong and it wasn't pointing to the 'arm' folder to remove the odex files. So I modified the script to test and set it to remove just one folder as a trial run. The script ran, but did nothing. It seems redundant to me to remove the .apk file and the odex file separately when you can just delete the folder and do in one action. However, I am at a loss as to how to accomplish that from the script.
One of the scripts is Bloatware Removal Script 1.
I can't seem to find the location that I got the one with the Aroma installer, but I have the file on my computer.
So, all this said (I wanted you all to know the process I went through in hopes it would help) to ask, how would one delete a folder from recovery using a script. The CoolBoy script uses:
Code:
delete("/system/app/Chrome.apk");
But not only does it not delete the apk, if I drop the file extension to delete the folder, it does not do that either. The Aroma installer option seems perfect, I just am not familiar with the command that would needed to be used in order to delete the folder. Thanks for reading my long winded post and for any help.
Hello xda-developers,
I'm trying to figure out the proper way to transfer app data from an Android image disk. I'm very new to this, so I hope I'm not missing something basic.
Situation. I have a .img disk image file obtained from a .vmdk file via a virtualbox conversion , the latter being created by an Android emulator. I'm trying to recover some app data and transfer that to a new, working, .img disk. The emulator works on Android 4.4.2, if that matters.
What I did. I extracted apks and copied app data folders (com.<devname>.<appname>) from/to the /data/data directory. I did that using a file manager (ES file explorer) or via the cp command, as I found in many tutorials and guides. Others suggested to copy those folders to /Android/data instead, so I did try that as well. These procedures were ineffective, because they both messed up with folders and files permissions. Although cp -ar retains folders/files permissions and ownership, that was of no use after the import into the working image. Those operations were performed on Ubuntu 18.04.
The problem (and a workaround). When the apks are installed, a new uid (in the 10000 group) is generated for them. These values are unknown when I import the data folders, hence they are destroyed at phone boot. A log in /data/system/uiderrors.txt confirms this. The only way I could make it work was to install the apk from scratch, open the app so that the new data folders are created with a proper uid, replace those folders with old ones and manually change ownership and permissions accordingly (for every apk). This turned out to be effective but it's a very tedious and error-prone process.
What am I doing wrong? How do ADB push, pull and backup commands manage folders permissions/ownership and app uids? Could they be useful in my situation? If so, how can I use them on a .img file?
Thank you.
I've got a specialized Android box running 8.1. I also have a full system image for the machine.
Within the image is a custom app that I'd like to modify. I'm able to pull the APK and ODEX/VDEX files from the priv-app folder. I'm also able to deodex to get all of the smali files, and recreate the classes.dex.
This is about as far as I've gotten. I should also say I've never done this, so may not have all the necessary tools. At this point, I'm simply trying to create a new and functional full APK that can be installed on another machine.
For anyone following....
Once you've got your dex files, add it/them to the apk package. Install Visual Studio Code (the free general use version of Visual Studio). Then install the APKLab extension. With VS open, CTRL-Shift-P to bring up the command menu, where APKLab: Open an APK should be at the top. Select it, then choose the APK to open, along with the desired options. These are what I generally choose:
-decompile_java (much easier to read the java than smali code, although it cannot be edited)
-force-manifest
-no-debug-info
-deobf
-show-bad-code
*unselect only-main-classes
Make any edits within the smali. In the left side Explorer menu, right click apktool.yml and select APKLab: Prepare for HTTPS Inspection. When complete, right click apktool.yml and select APKLab: Rebuild the APK. Your newly compiled APK will be placed in the "dist" folder.
Is theres a way to modify and run this apks without unlocking secrecy or auth token? i pulled it from my oppo and when i run the app it'll update the existing app
norimee said:
Is theres a way to modify and run this apks without unlocking secrecy or auth token? i pulled it from my oppo and when i run the app it'll update the existing app
Click to expand...
Click to collapse
You can't modify an APK, as it's in binary. You could remove it though - Let me know if you need help.
An APK ( read: Android Application Package ) file by nature is a ZIP file - not a binray - what can get extracted with any zip utility (e.g. 7zip), you can view all resources correctly but all java files are not correctly decompiled.
Content of an APK file looks like
You can also see the contents of an APK file within the Android device itself, which helps a lot in debugging, using
https://play.google.com/store/apps/details?id=com.dasmic.android.apkpeek
All files including the manifest of an app can be viewed and also shared using email, cloud etc., no rooting required.