[BUG] Samsung Android 15 malformed compiled jar

[starbucks2010]

Information

1. Apktool Version (apktool -version) - apktool_2.11.1_20250117.jar
2. Operating System (Mac, Linux, Windows) - Windows 11
3. APK From? (Playstore, ROM, Other) - Samsung S24 Ultra S928B ROM Android 15 OneUI7 Beta3
4. Java Version (java --version) - 20.0.2

Stacktrace/Logcat

https://drive.google.com/drive/folders/1HbnHabVtNxdxn0LxLwpA0dJxhVKv6Or0?usp=sharing

Include stacktrace here

Steps to Reproduce

1. Decompile services.jar - ok
2. Recompile services.jar - ok
3. Decompile the recompiled services.jar - impossible (see errors from log_decompile.txt)

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)
https://drive.google.com/drive/folders/1HbnHabVtNxdxn0LxLwpA0dJxhVKv6Or0?usp=sharing

APK

If this APK can be freely shared, please upload/attach a link to it.
https://drive.google.com/drive/folders/1HbnHabVtNxdxn0LxLwpA0dJxhVKv6Or0?usp=sharing

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? No, stock apk/jar unmodified, keep original signature
3. Are you using the latest apktool version? Yes

[salvogiangri]

Samsung Android 15 frameworks are packed using DEX format 039, use the "-api 29" flag to properly decompile/recompile back the jar files.
#3641 (comment)

[salvogiangri]

Additionally, looking at the logs you provided you used the "Batch ApkTool" script rather than this tool itself, that script is not in any way connected to the OG apktool/smali tools, so if you have an issue specific with it you should be reporting it to the script author, not here.

[starbucks2010]

Thank you for your reply Salvo.
The BatchApkTool works fine on Android 14 so it shouldn't be a problem of the tool. The DEX format 039 seems not not to be handled well by the new apktool 2.11.

Wouldn't have any impact on Android 15 resources.arc using "-api 29" instead "-api 35" ?

[salvogiangri]

Standalone apktool will handle jar files just fine as it detects the correct API version to use by checking the DEX file version format if not specified:

Apktool/brut.apktool/apktool-lib/src/main/java/brut/androlib/ApkDecoder.java

Lines 309 to 312 in e547948

	// in case we have no resources, we should store the minSdk we pulled from the source opcode api level
	if (!mApkInfo.hasResources() && mMinSdkVersion > 0) {
	mApkInfo.setMinSdkVersion(Integer.toString(mMinSdkVersion));
	}

So I'm pretty sure the script you're using is messing up with the API value as API 35 forces baksmali/smali to repack DEX files using 041 format which isn't fully supported yet by the tool, also, it won't match the original version from the untouched jar (039 vs 041).

Imho, the best thing to do at the moment is to handle de-recompiling of apks/dexs files separately in a way where it matches the original as much as possible to avoid issues, what I personally do is to use the -s flag in apktool to skip dex handling and use baksmali/smali manually with the correct API flag based on the DEX file magic:
salvogiangri/UN1CA@d3ad136
salvogiangri/UN1CA@fcc2fc5

[iBotPeaches]

Okay, so I'm trying to catch up on this and refresh myself.

• Apktool optionally accepts --api to invoke baksmali with said value.
• After disassembly with baksmali, it records the minSdkVersion if it has no resources to produce that value.
• Baksmali/smali reverse the api value to dex value using opcodes
• This PR appears to have changes to this logic in dexlib

So in my summary. In the meantime while API 35 is not well supported by downstream smali - manually invoke Apktool during disassembly with an api (29)? to trick the intended dex version in this specific usecase.

[salvogiangri]

So in my summary. In the meantime while API 35 is not well supported by downstream smali - manually invoke Apktool during disassembly with an api (29)? to trick the intended dex version in this specific usecase.

As explained in my previous comment, the api flag is not required when handling jar files as baksmali will automatically detect the correct minSdkVersion to use depending the DEX format version (#3699), so imho the issue is caused by that third party script which is instead setting the api flag to 35 and forcing baksmali/smali to use DEX 041 format as opposite of the original jar DEX 039 format.

The same cannot be said for apk files: I'm guessing apktool fetches the minSdkVersion via the app manifest, but there are some instances where this doesn't matches the actual DEX format version used in the apk (eg. Samsung system apps use minSdkVersion 34 but still use DEX 039 instead of 040), for this reason I suggested to handle the resources/smali decompiling manually in this specific instance.

[starbucks2010]

I made a some tests forcing api29 in the tool. I used official apktool 2.9.3 and 2.11 and smali/baksmali 3.0.3 and 3.0.9.

1. services.jar

• decompiled usingapktool 2.9.3 and 2.11 and smali/baksmali 3.0.3, forced api29
• small changes in both smali and smali_classes2 just to force dex recompilation
• recompiled into 2 separate files using apktool 2.9.3 and 2.11 and smali/baksmali 3.0.3, forced api29
• both recompiled services.jar booted fine

2. SecSettings

• decompiled using apktool 2.9.3 and 2.11, smali/baksmali 3.0.3, forced api29
• small changes in string.xml and some smali file to force dex and resources recompilation
• recompiled innto 2 separate files using apktool 2.9.3 and 2.11 and smali/baksmali 3.0.3, forced api29
• the recompiled SecSettings.apk using apktool 2.9.3 contains lots of APKTOOL_DUMMYVAL_0x7fxxxx.xml files (like half of the total number of files in the xml folder)
• the recompiled SecSettings.apk using apktool 2.11 doesn't contain any APKTOOL_DUMMYVAL_0x7fxxxx.xml files in xml folder but it doesn't boot
• I tried also the smali/baksmali 3.0.9 but no difference
• when I try to decompile the recompiled SecSettings.apk it gives me the below error:

---

Batch ApkTool : 3.8.0
APKTOOL (aapt2) : apktool_2.11.0.jar
Build in EXPERT mode : YES
Sign output APKs : NO

[*] Installing framework framework-res.apk
I: Framework installed to: ..\bin\framework\1.apk

[] Decompiling SecSettings_s928b_zxkl_211_309_api29_recomp.apk
I: Using Apktool 2.11.0 on SecSettings_s928b_zxkl_211_309_api29_recomp.apk with 8 threads
I: Baksmaling classes.dex...
I: Loading resource table...
I: Baksmaling classes2.dex...
I: Baksmaling classes3.dex...
I: Baksmaling classes4.dex...
I: Decoding file-resources...
I: Loading resource table from file: ..\bin\framework\1.apk
I: Decoding values / XMLs...
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
Exception in thread "main" java.lang.RuntimeException: java.util.concurrent.ExecutionException: com.android.tools.smali.dexlib2.util.DexUtil$InvalidFile: Unexpected container offset in header
at brut.androlib.BackgroundWorker.waitForFinish(SourceFile:0)
at brut.androlib.ApkDecoder.decode(SourceFile:0)
at brut.apktool.Main.main(SourceFile:0)
Caused by: java.util.concurrent.ExecutionException: com.android.tools.smali.dexlib2.util.DexUtil$InvalidFile: Unexpected container offset in header
at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
... 3 more
Caused by: com.android.tools.smali.dexlib2.util.DexUtil$InvalidFile: Unexpected container offset in header
at com.android.tools.smali.dexlib2.dexbacked.DexBackedDexFile.(SourceFile:0)
at com.android.tools.smali.dexlib2.dexbacked.ZipDexContainer.getEntries(SourceFile:0)
at com.android.tools.smali.dexlib2.dexbacked.ZipDexContainer.getDexEntryNames(SourceFile)
at brut.androlib.ApkDecoder.decodeSourcesSmaliJob(SourceFile:0)
at brut.androlib.ApkDecoder.lambda$decodeSourcesSmali$0(SourceFile)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
at java.base/java.lang.Thread.run(Thread.java:1583)
[] ---> Error decompiling SecSettings_s928b_zxkl_211_309_api29_recomp.apk

DONE with 1 ERRORS.
Elapsed time: 36 sec.

[salvogiangri]

You can't decompile/recompile the Settings app by setting the API flag to 29 because, obviously, it's an API 35 app. Use the latest available apktool version (upstream is better), then separately decompile/recompile the apk/dex files with the proper API version for each. Until a way to match the DEX version format of the original apk gets integrated in the tool (assuming any of the maintainers is interested in this, I have no idea whether or not this minSdkVersion mismatch is something Samsung specific), this is the way to go.

[starbucks2010]

Salvo, have you managed to boot a android 15 device with a modified system app (Settings or SystemUI) with this procedure?

I tried last evening to use a SecSettings (S24U S928B device) modified using your above method but the device didn't boot.
The SecSettings.apk recompiled ok, without errors, but it doesn't boot. So I guess there's something more than the dex format 039 that it isn't handled for the moment by the latest apktool.