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
Hallo guys, I trying deodex my rom a week but it did not work as well. Successful only half the rom. Please help me, I have tried many ways to including XUltimate exactly.
Rom here: http://www.mediafire.com/?qj9hllq7cp6uuqj
Sorry for ugly english
What is your phone?
If is an Motorola, here is the tutorial:
Deodexing Explained + How To
So you want to theme… but you keep hearing about all this deodexing stuff… so whats that all about?
Stock android implements an odex file structure; for every (well…most) system app(s) (.apk file) and framework files (.jar) there is a corresponding .odex file, so for example you have;
/system/app/Phone.apk
/system/app/Phone.odex
/system/framework/com.motorola.android.mediasync.jar
/system/framework/com.motorola.android.mediasync.odex
What do the .odex files do?
All of your apps on your device are packaged as .apk files; these files are compiled from google source code and can interchangeably be viewed/thought of as a compressed folder (like a .zip or a .rar); and all of your framework components (well most…) are packaged as .jar files which literally stands for Java Archive (so again this can be compared to a .zip or a .rar).
When the android OS want’s to run your apps or utilize its framework components, it has to parse (read/interpret) the compressed data held within your .apk and/or.jar files. What the odex file structure aims to do, is to expedited this process by utilizing another file (.odex file) to compliment every.apk file (and .jar file); the odex file, includes the most critical data in an uncompressed format so the android os can quickly interpret that important information before parsing through the rest of the data held within the compressed .apk files (and .jar files). So subsequently, in an .odex file structure the .apk & .jar files don’t include all of the applications/framework-components data; Essentially, two files are acting as one; for your apps there are .apk files + their corresponding .odex file and for your framework components there are .jar files + their corresponding .odex file. This works nicely as an optimized file structure, except in the circumstance when the user want’s to theme; theming requires a modification to your .apks; the image files (.pngs) held within the pngs are replaced with different ones. However it is impossible to theme an application if it exists as two files. So that is why it is said you need to be DeOdexed in order to theme; DeOdexing is the process of re-bundling that uncompressed critical data (.odex files) back into your compressed .apk (& .jar) files, so that now all of the data is included in the .apk files necessary to run your applications without the presence of .odex files; in addition all the data is now included within the .jar files necessary to utilize your framework components without .odex files. In a DeOdexed file structure, there are no odex files present.
What are the benefit’s of DeOdexing?
Simple. To be able to theme a stock ROM.
Deodexing doesn’t speed your phone up or do anything of the sort.
It is simply something that is necessary to be able to theme a stock ROM.
How do you DeOdex?
One way you can deodex is to use the application xUltimate which actually rebundles that information for you. Another way, is to use a pre-made DeOdexer Update.zip; this zip already has all the repackaged fully compressed .apk files and utilizes code in the update script to delete all of the odex files present. So essentially all it’s doing is overwriting all your old semi data inclusive .apk files with fully inclusive ones and then deleting the (now) superfluous .odex files. This is the easiest way to do it, since all the work is already done for you. Just flash it in clockwork as you would for any theme:
Download it
Place it on your sdcard
Open Droid X Bootstrap
Hit Bootstrap Recover > Ok > Reboot Recovery
Navigate to ‘Install zip from sdcard’ with volume keys and select with camera button
Navigate to ‘Choose zip from sdcard’ and select
Navigate to the directory containing the above deodexer zip
Select it > Yes
Wait for it to do its thing > reboot system
You are now deodexed.
How can you check to see if you DeOdexed successfully?
Open a file explorer (like Root Explorer or Astro)
Navigate to the directory /system/app
Check for the presence of .odex files
Navigate to the directory /system/framework
Check for the presence of .odex files
If there are no odex files present then you are deodexed!
Now you can theme!
Will DeOdexing slow you down?
Technically it should, but in actuality its really quite negligible to notice, however… In my opinion, it’s rather silly to DeOdex and stay on stock ROM; you should just make the switch to a custom ROM. Why? Because custom ROMs are already deodexed and they zipalign your apps on boot; zipaliging is the process of reorganizing the manner in which the .apk is packaged to optimized it for being parsed faster by the android OS, it is comparable if not better than the odex file structure, so you get the best of both worlds; a themed ROM and the speed of an optimized file structure. That is why Stock is lame and custom ROMS pwn (IMO of course…)
I'm not sure if I've chosen the right forum to post this in, but I can't think of anything more specifically suited for it. Apologies in advance if someone has to move it.
I'm trying to install apps in /system, and I'm wondering where I should put the libraries.
I've been running with the libraries in their respective app folders (in /system/app/ and /system/priv-app/,) ported directly from /data/app/, and I haven't actually encountered any issues. However, I recently realized that /system/lib/ exists for libraries belonging to system apps. However, some of the apps have libraries with conflicting names, and different sizes. So, I'm not sure if moving them to /system/lib/ is advisable, or if I should continue leaving the libraries in their respective folders, as is done on the data partition.
Thanks in advance to anyone who takes the time to reply!
Heya,
A while ago, my phone, which is a samsung A3 from 2015, got an update to marshmallow.
That's cool ofcourse and it runs awesome! but I like when my phone has a nice, clean and organized system and Samsung does not do that for all apps.
What I mean is that
- Some apps are odexed, and some apps are not AND some apps are odexed, but the apk file still contains a classes.dex file.
- Some apps have a folder with libs inside the app directory, and some have this folder inside the apk file AND some have this folder inside both
So ideally, i would like all apps to follow the same structure ofcourse, which would be no classes and lib files inside the apk, and then separate oat and lib folders containing the odexes and libs.
In lollipop this was easily done by copying these files out of the apk and putting them in separate folders, then removing them from the apk itself. My phone accepted this, the apps would run as though nothing had happened and it made me feel happy
However now that i'm on marshmallow, everything i do to an apk to change it results in getting a parsing error with that apk, after which it either becomes very fragile or completely broken.
One way I have found to get around this so far is to resign the apk, but for a lot of apps resigning it makes android ignore the app completely.
So the question is...
Is there something I can change somewhere to make marshmallow act like lollipop in these cases and not care that i removed files from apk's in an attempt to odex or delib them?
Any help would be much appreciated
Further info
- I have also noticed this on an S5 / SM-G900F running marshmallow
- I have not tested this on aosp or lineage because there are no suitable roms for my phone to test this with, and I would not want to use them over stock anyway.
- I have not run into this before marshmallow, it was always fine with me editing apk's like this in older versions of android.
- I am not ready to get over my ocd and accept this :crying:
No one? I suppose it is a really tough question.
So I got around the duplication of lib files by putting the actual libs in the appname\lib\arm folder and then placing zero length lib***.so placeholder files inside the apk.
this somehow keeps the apk intact and does not cause a parse error and makes the app work as it should, even across data wipes, reboots, backups and restores.
putting zero length classes.dex files inside the apk however doesn't work. Although this also doesn't cause a parsing error, the app actually tries to transform the empty classes into dalvik cache and then it breaks.
I'm still open to better suggestions
I'm playing around with installing apps to the system partition before first boot, using a generic installer zip(by Andybones). All I'm doing is taking the apps from /data/app and renaming their directories to something more readable, then installing them to /system/app using the installer zip and setting permissions. I've noticed that some ROMs include odex files in their system partitions, to save time on first boot.
I assume I can just transfer the odex files over with the apk's, but I remember reading that the reason apps install so much faster in Android N is that the apps are no longer fully compiled during the install, but instead do that in the background over time.
Does anyone know if this refers to the odex files? I just don't want to copy over a bunch of odex files if they're incomplete. Any help or advice would be greatly appreciated! =D