[BUG] Recompiling system jars produces strange jars

[taylor00541]

Information

1. Apktool Version (apktool -version) - 2.9.3
2. Operating System (Mac, Linux, Windows) - Windows 11
3. APK From? (Playstore, ROM, Other) - ROM
4. Java Version (java --version) - java 20.0.1 2023-04-18

Steps to Reproduce

1. Download lineage-20.0-20240126-nightly-lynx-signed.zip from here.
2. Extract system.img from the OTA, and then get /system/framework/framework.jar (framework.jar.zip)
3. apktool d -o framework framework.jar
4. apktool b -api 29 -c -f -o framework2.jar ./framework
5. Note that framework.jar is 32.6 MB and framework2.jar is 17.6 MB
6. Run unzip -lv framework.jar, unzip -lv framework2.jar Note that framework.jar contains 57 files, and framework2.jar contains 54 files (missing res/vendor.mime.types, res/android.mime.types, res/debian.mime.types).
7. Note that the checksums of all the .dex files have changed.
8. Replacing the produced file on a running ROM causes a boot loop.
9. The same holds for other system .jars.

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? Irrelevant
3. Are you using the latest apktool version? Yes

Possibly related issues

1. [BUG] apktool b generates bad hiddenapi_class_data_item #2918
2. [BUG] Framework.jar cannot be recompiled normally. The latest apktool #2662

[iBotPeaches]

hmm thats odd. Thanks for details.

I'm watching some updates to upstream smail for newer dex types. Though you are targeting API 29, so probably that. Either way you might have some luck running some tests directly w/ smali to rule out specific Apktool beahvior.

https://github.com/google/smali

[iBotPeaches]

Going to mark as 3rd-party and await a new release from google/smali. I believe whatever is happening here is over my knowledge.

[iBotPeaches]

smali/baksmali v3.0.5 has been merged and available for testing on this bleeding edge release - https://github.com/iBotPeaches/Apktool/actions/runs/8048426591

[ProgerXP]

smali/baksmali v3.0.5 has been merged and available for testing on this bleeding edge release - https://github.com/iBotPeaches/Apktool/actions/runs/8048426591

I have the same issue with an official Samsung firmware for Android 14. I can confirm that this release does not fix the problem (neither the latest 2.9.3 does):

# java -jar apktool-v2.9.2-27-5422bd70-SNAPSHOT.jar d framework.jar
I: Using Apktool v2.9.2-27-5422bd70-SNAPSHOT on framework.jar with 4 thread(s).
I: Baksmaling classes.dex...
I: Baksmaling classes5.dex...
I: Baksmaling classes4.dex...
I: Baksmaling classes2.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
I: Baksmaling classes6.dex...
I: Baksmaling classes3.dex...

# ls unknown
android  com

# unzip -l framework.jar
...omitted for brevity...
     2242  2008-01-01 00:00   res/android.mime.types
    12022  2008-01-01 00:00   res/debian.mime.types
      533  2008-01-01 00:00   res/vendor.mime.types

As a result, the rebuilt framework.jar is missing res/ breaking the system if flashed. This can be worked around by either manually adding res/ back (zip framework.jar res/) or editing apktool.yml (unknownFiles) and copying res/ to unknown/ - then apktool b will produce proper JARs.

[iBotPeaches]

I don't think any release in my memory ever has persisted res/ contents for a jar file. That must be a new requirement.

[ProgerXP]

I don't think any release in my memory ever has persisted res/ contents for a jar file. That must be a new requirement.

Do you need the official JAR for confirmation?

FYI, here's what happens with the device (logcat) if you flash framework.jar missing that res/:

W MediaProvider: Failed operation Intent { act=com.android.providers.media.action.SCAN_VOLUME (has extras) }
W MediaProvider: java.lang.RuntimeException: Failed to parse debian.mime.types
W MediaProvider:     at android.content.type.DefaultMimeMapFactory.parseTypes(DefaultMimeMapFactory.java:102)

You can see res/debian.mime.types is exactly one of those files from my earlier post. You can't take screenshots, use the camera, My Files and MTP break, etc. etc.

[iBotPeaches]

If you can link me to an official jar/something that has proof of the res contents within it - yeah that'll help. I don't yet know if thats a specific Samsung thing or AOSP.

[ProgerXP]

framework.zip, source:

AP_F946BXXS1BXBM_F946BXXS1BXBM_MQB77758044_REV00_user_low_ship_MULTI_CERT_meta_OS14.tar.md5

Related: it'd be good if apktool reported when it ignores/removes some entries from the input APK or JAR. I spent half a day figuring why a rebuilt JAR with no modifications fails until I checked its contents by accident.

[long5436]

smali/baksmali v3.0.5 has been merged and available for testing on this bleeding edge release - https://github.com/iBotPeaches/Apktool/actions/runs/8048426591

I have the same issue with an official Samsung firmware for Android 14. I can confirm that this release does not fix the problem (neither the latest 2.9.3 does):

# java -jar apktool-v2.9.2-27-5422bd70-SNAPSHOT.jar d framework.jar
I: Using Apktool v2.9.2-27-5422bd70-SNAPSHOT on framework.jar with 4 thread(s).
I: Baksmaling classes.dex...
I: Baksmaling classes5.dex...
I: Baksmaling classes4.dex...
I: Baksmaling classes2.dex...
I: Copying assets and libs...
I: Copying unknown files...
I: Copying original files...
I: Baksmaling classes6.dex...
I: Baksmaling classes3.dex...

# ls unknown
android  com

# unzip -l framework.jar
...omitted for brevity...
     2242  2008-01-01 00:00   res/android.mime.types
    12022  2008-01-01 00:00   res/debian.mime.types
      533  2008-01-01 00:00   res/vendor.mime.types

As a result, the rebuilt framework.jar is missing res/ breaking the system if flashed. This can be worked around by either manually adding res/ back (zip framework.jar res/) or editing apktool.yml (unknownFiles) and copying res/ to unknown/ - then apktool b will produce proper JARs.

I had the same problem, your reply temporarily fixed it