Apktool: [INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2] after Compile

[Deltafox79]

Information

1. Apktool Version (apktool -version) -
   2.3.0
2. Operating System (Mac, Linux, Windows) -
   Windows
3. APK From? (Playstore, ROM, Other) -
   PlayStore
   

   Stacktrace/Logcat

Include stacktrace here

After recompile apk and signed I have this issue when install recompiled apk...

`Failure [INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]

Steps to Reproduce

1. apktool
   apktool.bat r ..apk

Frameworks

If this APK is from an OEM ROM (Samsung, HTC, LG). Please attach framework files
(.apks that live in /system/framework or /system/priv-app)

APK

If this APK can be freely shared, please upload/attach a link to it.

http://www17.zippyshare.com/v/cE36EDY0/file.html

Questions to ask before submission

1. Have you tried apktool d, apktool b without changing anything?
   yes
2. If you are trying to install a modified apk, did you resign it?
   yes
3. Are you using the latest apktool version?
   yes

[iBotPeaches]

Sorry delayed on this. Was going to look into it, but forgot my dev phone today. Just letting you know I read this and have the application locally and will look into it hopefully tomorrow.

[Deltafox79]

Hi I have update download link any info on this issue? Regards

[danhawkes]

Think this is triggered by settingextractNativeLibs to false in the manifest. Have reverted a change to set it and the recompiled APK installs successfully.
https://developer.android.com/guide/topics/manifest/application-element.html

[iBotPeaches]

Interesting. Apktool should not change values of the Manifest though. I'll run some tests with that info.

 E: application (line=34)
      A: android:label(0x01010001)=@0x7f0d0032
      A: android:icon(0x01010002)=@0x7f0b0000
      A: android:name(0x01010003)="com.bittorrent.client.BTApp" (Raw: "com.bittorrent.client.BTApp")
      A: android:allowBackup(0x01010280)=(type 0x12)0x0
      A: android:hardwareAccelerated(0x010102d3)=(type 0x12)0xffffffff
      A: android:supportsRtl(0x010103af)=(type 0x12)0x0
      A: android:extractNativeLibs(0x010104ea)=(type 0x12)0x0
      A: android:resizeableActivity(0x010104f6)=(type 0x12)0xffffffff
      A: android:roundIcon(0x0101052c)=@0x7f0b0000

AAPT already has it set to 0x0 or false.

[Deltafox79]

Yes if I put true the extractNativeLibs apk compiled works.. strange if whit -r option apk have same problems..

Regards

[iBotPeaches]

Looked into this some more. If going by the words of @danhawkes & @Deltafox79 that manually changing this extractNativeLibs property to true resolves the booting issue doesn't make much sense.

I confirmed that the property was false in the original application, the decoded original application and the rebuilt (dirty) application. Apktool should not be in the market of random changing properties in the Manifest.

There was some research online that an application needs to be "zipaligned" to resolve this issue. I read that here: https://github.com/scala-android/sbt-android/issues/252

Might be worth testing. Resign, then zipalign and try with the property set to false.

[slowjack2k]

I can confirm this behavoir with a different apk. It still only works when I set extractNativeLibs to true. With extractNativeLibs false I get INSTALL_FAILED_INVALID_APK

[peret]

I can also confirm that this is still an issue in 2.3.4. zipaligning the apk did unfortunately not fix it.
The documentation of the extractNativeLibs attribute says: "If set to false, then your native libraries must be page aligned and stored uncompressed in the APK."

Could the issue be related to apktool compressing the native libs for some reason? From what I can see, .so-files are actually on the doNotCompress list though...

[Deltafox79]

Hi Any news on this issue? also whit latest apktool-2.4.1-c20659-SNAPSHOT-small.jar this bug is present..

Just use d for decompile apk and manifest change android:extractNativeLibs="false" why false?

Download apk for test :

debug.apk

Regards

[rosasurfer]

With the current version of the Android build environment the manifest attribute /manifest/application[@android:extractNativeLibs] is always set to false. This means the libraries in the APK are page aligned by the build environment (not to confuse with zipaligning the whole APK) and the loader loads them directly from the APK (presumably storage space considerations). When the ApkTool (version 2.4.0) recompiles such an APK it doesn't change the manifest settings but due to the recompilation the resulting library file layout in the APK is not page aligned anymore, and that's the cause the loader fails and the error occures. Removing the attribute or explicitely setting it to true (the default value) prevents the bug to happen.

[timjosten]

@iBotPeaches If extractNativeLibs="false", then .so files should not be ZIP compressed. The system will load .so files directly from APK binary file. It won't work if .so files are compressed.

For a dirty fix, you should always change this attribute to true.
For a proper fix, you should implement new code to not compress .so files if this attribute is set to false, but compress everything else.

[iBotPeaches]

@iBotPeaches If extractNativeLibs="false", then .so files should not be ZIP compressed. The system will load .so files directly from APK binary file. It won't work if .so files are compressed.

For a dirty fix, you should always change this attribute to true.
For a proper fix, you should implement new code to not compress .so files if this attribute is set to false, but compress everything else.

Thanks for the research. I see. So the property extraction is required if true, if false is just uses random access to stream file.

[giacomoferretti]

Seems to work with 2.4.2-d3f9d5-SNAPSHOT.

After rebuilding, zipalign it using this command: zipalign -p -f 4 input.apk output.apk
Then sign it with apksigner and should work now.

[bletham]

I was running into this issue (in apktool 2.4.1, and using zipalign after jarsigner) and @giacomoferretti's approach worked for me.

[iBotPeaches]

This should be handled now with proper handling of compression. Zipaligning may be required to align to 4byte boundries.

Closing.