Accidental changes for the res/ and r/ changes? I remember those fixes from AndroidResGuard.

with that max 29 sdkver for dex, -api is not needed at all but still thanks for that :)

Accidental changes for the res/ and r/ changes? I remember those fixes from AndroidResGuard.

Nah it's unchanged, just moved it out of ResFileValue to the only place where it's relevant ResFileDecoder as stripResFilePath and used our ApkInfo.RESOURCES_DIRNAMES array that has those dir names already. The behavior is identical.

with that max 29 sdkver for dex, -api is not needed at all but still thanks for that :)

Exactly. Realistically with the max 29 limit, -api is not needed for anything at all, it can only do harm than anything useful.

with that max 29 sdkver for dex, -api is not needed at all but still thanks for that :)

Exactly. Realistically with the max 29 limit, -api is not needed for anything at all, it can only do harm than anything useful.

if you removed -api option then you should limit it to 29 already, still its all good now. i already had smali working fine so only apktool was affected for me.

Do you think we should emit a log message if api > 29 and say something like "Dropping API level to 29 from x, due to smali issue y"?

I just want to avoid some "magic" transformation that may go unnoticed in a year or two

Do you think we should emit a log message if api > 29 and say something like "Dropping API level to 29 from x, due to smali issue y"?

I just want to avoid some "magic" transformation that may go unnoticed in a year or two

best way would be to detect dex version from available classes.dex file in apk and that too while decompiling. there might be other ways too but this seems better

Do you think we should emit a log message if api > 29 and say something like "Dropping API level to 29 from x, due to smali issue y"?

I just want to avoid some "magic" transformation that may go unnoticed in a year or two

No? What dex version is used for smali is not something the user should be concerned about, nor the user needs to understand the relationship between minSdkVersion (explicit) and dex version (implicit). It's apktool's job to automate these things and not produce broken output.

That's why I think -api is useless, should be removed completely to discourage its abuse by people who don't understand it.
The mere existence of this option is the source of confusion. Many specify it "just to be safe", not understanding the consequences.

You can't predict what will happen in a year or two, but smali is currently broken, the VersionMap doesn't match reality (no app is built with 040 or 041 regardless of API, they shouldn't have touched it).

Do you think we should emit a log message if api > 29 and say something like "Dropping API level to 29 from x, due to smali issue y"?
I just want to avoid some "magic" transformation that may go unnoticed in a year or two

best way would be to detect dex version from available classes.dex file in apk and that too while decompiling. there might be other ways too but this seems better

smali/baksmali doesn't support specifying the dex version, only an API version for opcodes, and we already get the resolved API version from dex if needed (JARs). Current method is fine. You won't see APKs with dex versions not matching the app's minSdkVersion, that's hardcoded in build tools.

Should we consider #3775 fixed at this point? I believe #3699 was already enough considering this fixed fetching the minSdkVersion value for jar files.

Should we consider #3775 fixed at this point? I believe #3699 was already enough considering this fixed fetching the minSdkVersion value for jar files.

#3699 wasn't enough because it only applied to JARs. If you decompiled an app with minSdkVersion > 29, then you wouldn't get the expected dex 039 files. This wasn't due to the PR that Connor mentioned in #3775, it was actually this change, specifically in mapApiToDexVersion. Yes, it's over a year old.

This PR fixes #3775. Now even if the app has minSdkVersion: 35, it'll smali into dex 039. -api is obsolete in all cases.