4

Most apks have a /lib dir inside with .so files that can be several megabytes. Some even come loaded with libs for different architectures (arm, mips, x86). Libs for relevant arch are copied in /data/app-lib/[package name] at install time, so they take double the space.

I tried to strip the apk from the /lib folder, rewrite, zipalign and put back to install location /data/app or /system/app or /system/priv-appto reclaim some space.

Tried with Chrome v78, it went from 45 mb apk to 15 mb... Other apps too. Everything seems to work.

Anyone thinks it's a bad idea? IMO the very Android system should perform this operation by default at install time...

edit 13 Nov

I wrote a script to automate the strip operation, just have to copy the apk to strip in a dir where this script resides, along with zip and zipalign binaries.

#!/system/bin/sh
for filename in `find . -name '*.apk'`
do
        ./zip -d $filename "lib/*"
        ./zipalign -fv 4 $filename $filename.new|tail
        mv $filename.new $filename
        chmod 644 $filename
done;

On my device I can swap original with stripped apks on the fly and they (usually) run fine without rebooting, even system apps.

5

Based on my experience, modifying an APK file after the installation is not a big problem as long as you don't touch the DEX files. Especially the native libraries for other architectures than the one of your device can usually be stripped without problems as they are totally ignored after the installation.

However there are apps that implement extra security checks (usually banking, finance, streaming apps with DRM or otherwise extra hardened apps) that performs some sort of self-test to check whether they have been modified or not. Modifying those apps will end up in a non-working app.

  • 1
    How is this part handled exactly e.g. to not break future updates from original developer? "During validation, v2+ scheme treats the APK file as a blob and performs signature checking across the entire file. Any modification to the APK, including ZIP metadata modifications, invalidates the APK signature." Any thoughts? Retaining original META-INF folder and AndroidManifest.xml should work? – Irfan Latif Nov 12 at 21:27
  • 1
    @Irfan Good point, however the APK v2+ signature is not the problem as the APK file is AFAIK not checked after it has been installed. However the Google Play Frosting signature will also be destroyed/removed by modifying the APK file. Therefore Google Play may complain that the modified apps are not genuine. But I am not sure what and when this Forsting signature is checked. – Robert Nov 13 at 8:35
  • APK signatures are checked after app is installed: on update. To me that seems to be the only (or at least major) purpose of signing apps. Otherwise those are self-signed, can't be verified against a CA. And (if not downloaded from Play Store) there's no way to confirm if an app with certain package name is from original developer. Anyone can develop app with any package name signed with his/her own certificate. Contradiction occurs on update. Or am I going in wrong direction? – Irfan Latif Nov 13 at 19:37
  • @Irfan I have not tested it but it in theory it is not necessary to verify an installed app before you update it. As Android already has verified the APK file at installation time you could simply extract the certificate without verification and compare it with the certificate from the update to-be-installed. Or even more likely the package manager uses the certificate data from it's cache e.g. /data/system/packages.xml. – Robert Nov 13 at 19:55
  • Got your point. Updated version is verified against pre-installed app's signatures but the old app itself isn't re-verfied (most probably). It makes sense because pm would be using signatures from packages.xml. Thanks. – Irfan Latif Nov 13 at 21:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.