Did the checker die or something?

Hmm that is odd. Actions not showing the commit.

Hmm that is odd. Actions not showing the commit.

There, it's back from slumber.

I guess with how much upper casing is going on to the hex, I might see if spotless or something can just lint those.

Let me know if you are done, just want to take a closer look at the ARSC changes otherwise it seems good.

That Copilot is pretty cool, never seen that in action on GitHub.
Anyways, I'm done. If you have any questions, I'm happy to rant.
Full ROM decompile shows no diffs between pre-changes apktool and new one, so this looks good.

By the way, AOSP has at least 3 different variations of how resource qualifiers should be formatted, no consistency at all and some of them are nonsense that aapt2 can't read. I based my changes on how aapt2 actually parses the qualifiers, which is what we care about when we want to recompile an app.

OK, now I'm really done. Don't feel like anything else in need of urgent rework.
Really proud of the latest commit. Main class is beautiful now. You'll find it a lot easier to work with.

Are all the options intended one too much? I see this, but expect this.

    private static final Option verboseOption = Option.builder("v")
            .longOpt("verbose")
            .desc("Increase output verbosity.")
            .build();

see this

    private static final Option verboseOption = Option.builder("v")
        .longOpt("verbose")
        .desc("Increase output verbosity.")
        .build();

expect this

Are all the options intended one too much? I see this, but expect this.

    private static final Option verboseOption = Option.builder("v")
            .longOpt("verbose")
            .desc("Increase output verbosity.")
            .build();

see this

    private static final Option verboseOption = Option.builder("v")
        .longOpt("verbose")
        .desc("Increase output verbosity.")
        .build();

expect this

You're probably right, but I find it more readable when it's closer to the Option.builder() call.
Looking at the rest of code, we don't really have that consistent.
i.e. here it's less indent:

imo this

    private static final Option verboseOption = Option.builder("v")
        .longOpt("verbose")
        .desc("Increase output verbosity.")
        .build();

makes less sense, because if you move Option.builder() to the next line, then I'd write something like this:

    private static final Option verboseOption =
        Option.builder("v")
            .longOpt("verbose")
            .desc("Increase output verbosity.")
            .build();

so the single-indent is reserved for what's after = whether it's actually on a new line or not, but that's just a preference.

I can adjust the indentation however you prefer, I'm not religious about it, I'm only religious about making it consistent. XD

Yeah I guess I shouldn't complain until there is a linter (spotless?) that just enforces it and does it all.

@HassanMirza01 - Can you give some examples? I tested this and nothing looked broken from my point of view in CLI execution.

-api or --api-level not getting recognize at all in repacking apks.

only decompile option has -api option, build dont have it,

Ah I see. Maybe our loading since its gated behind the advanced flag is causing it to not recognize the flag. I'll investigate when home today, unless @IgorEisberg beats me to it.

CLI parsing sucks after these changes, neither advanced mode working nor --version. broke all automation stuff, and no -api level setting option either. can't even see all available options apktool provides

Apktool is a command-based tool, so having --advanced and --version as options made no sense when those are separate operation modes with different output, rather than options for any of the commands.
It's apktool help for advanced usage information, and apktool version to output version.
Many other tools that have multiple operation modes (= commands) operate this way, for example apksigner.jar has help and version commands.
Just because you fail to adapt to changes that make perfect sense doesn't mean that "CLI parsing sucks after these changes".
I really don't see the difficulty in writing just version instead of -version/--version or help instead of -advance/--advanced. It's actually a lot easier.
The only case where having these as options would be in applications that don't have multiple commands/modes, each with separate set of valid options.

@iBotPeaches @IgorEisberg -api option removed ?

Forcing API is meant for baksmali, specifically for decoding JARs where there's no AndroidManifest.xml.
Once decoded, API level is already in apktool.yml and used for building.
There is no reason to have -api for building (that's what apktool.yml is for). If you had it, then you simply misused it, that's all. You can remove it from your usage for apktool b without anything being affected.

Ah I see. Maybe our loading since its gated behind the advanced flag is causing it to not recognize the flag. I'll investigate when home today, unless @IgorEisberg beats me to it.

Nope, everything is as intended. There's a reason we keep minSdkVersion in apktool.yml even for JARs.

Forcing API is meant for baksmali, specifically for decoding JARs where there's no AndroidManifest.xml. Once decoded, API level is already in apktool.yml and used for building. There is no reason to have -api for building (that's what apktool.yml is for). If you had it, then you simply misused it, that's all. You can remove it from your usage for apktool b without anything being affected.

so what api level will be stored in apktool.yml ? minSdkVersion or -api provided value?

cause i unpacked some android 15 apks and they stored
sdkInfo: minSdkVersion: 35

even though i provided -api 34 in decoding command, whats use of -api value in decoding then? also, not all want to build with -api version 35, Xiaomi uses older version of jars as seen in header of it, so i want to build with older api.

Forcing API is meant for baksmali, specifically for decoding JARs where there's no AndroidManifest.xml. Once decoded, API level is already in apktool.yml and used for building. There is no reason to have -api for building (that's what apktool.yml is for). If you had it, then you simply misused it, that's all. You can remove it from your usage for apktool b without anything being affected.

so what api level will be stored in apktool.yml ? minSdkVersion or -api provided value?

For APK it's retrieved from AndroidManifest.xml, for JARs it's retrieved automatically from baksmali.
If you provide -api, then that version will be forced on baksmali instead and stored in apktool.yml.
It's completely optional, there's no reason to use this option nowadays.

cause i unpacked some android 15 apks and they stored sdkInfo: minSdkVersion: 35

even though i provided -api 34 in decoding command, whats use of -api value in decoding then? also, not all want to build with -api version 35, Xiaomi uses older version of jars as seen in header of it, so i want to build with older api.

Then you misuse the tool. If the APK has minSdkVersion of 35, then I'm not sure what magic you expect to happen that will turn it to depend on 34 instead. Again, -api was always intended for baksmali, it had no other usage in code. And since minSdkVersion is automatically interpreted from baksmali, the option is for advanced usage only and has no know practical use.

cause i unpacked some android 15 apks and they stored sdkInfo: minSdkVersion: 35
even though i provided -api 34 in decoding command, whats use of -api value in decoding then? also, not all want to build with -api version 35, Xiaomi uses older version of jars as seen in header of it, so i want to build with older api.

Then you misuse the tool. If the APK has minSdkVersion of 35, then I'm not sure what magic you expect to happen that will turn it to depend on 34 instead. Again, -api was always intended for baksmali, it had no other usage in code. And since minSdkVersion is automatically interpreted from baksmali, the option is for advanced usage only and has no know practical use.

you are wrong here! baksmali not picking up correct api level as seen in repacks! see the original classes.dex file, it has 039 version jar, and the repacked file i did with this new apktool, it packed with 041 which is incompatible

in previous apktool, using -api value was actually affecting classes.dex compilation

i used api 34 for baksmali tool for services.jar, and you can see it repacked with 040 jar version which is still recognizable by rom but 041 is not

i used api 34 for baksmali tool for services.jar, and you can see if repacked with 040 jar version which is still recognizable by rom but 041 is not

Yes, as I already said, you are misusing the tool. If you want dex version 039 then don't use the -api option.
Let the API level be decided automatically. This is not an apktool issue, it's defined in smali:
https://github.com/google/smali/blob/main/dexlib2/src/main/java/com/android/tools/smali/dexlib2/VersionMap.java#L55

Yes, as I already said, you are misusing the tool. If you want dex version 039 then don't use the -api option. Let the API level be decided automatically. This is not an apktool issue, it's defined in smali: https://github.com/google/smali/blob/main/dexlib2/src/main/java/com/android/tools/smali/dexlib2/VersionMap.java#L55

well, seems like removing -api totally from decompiling and recompiling still generates 041 version dex files. i dont know what else needed to get older type output, its just too much confusion! whats issue in adding back -api option simply?

baksmali tool itself has option to get an api value whatever it is, also, i dont understand how baksmali will get value from stock apk? we are not providing any stock apk to build command, so it will definitely use minSdkVersion for api which is wrong

baksmali tool itself has option to get an api value whatever it is, also, i dont understand how baksmali will get value from stock apk? we are not providing any stock apk to build command, so it will definitely use minSdkVersion for api which is wrong

Hassan, what are you talking about? How is minSdkVersion wrong? I'm getting minSdkVersion: 29 when decoding any JAR, which is perfect to get a 039 dex when building. For JARs, baksmali gets the value from the stock dex files. It's not that hard to understand.

minSdkVersion

bro, am not using apktool for jars like framework.jar and services.jar etc, i use smali/baksmali for them but the dex files present inside apks are issue, how 29 will be set for those classes.dex files which are inside apks?

i can see its all fine for jars unpack but not for apks :)

baksmali tool itself has option to get an api value whatever it is, also, i dont understand how baksmali will get value from stock apk? we are not providing any stock apk to build command, so it will definitely use minSdkVersion for api which is wrong

Because apktool was previously accepting all of the options regardless of which command is used, now it enforces correct usage, like every good tool should do. A good tool should not allow misusage.

minSdkVersion

bro, am not using apktool for jars like framework.jar and services.jar etc, i use smali/baksmali for them but the dex files present inside apks are issue, how 29 will be set for those classes.dex files which are inside apks?

I'm not bro. If the APK has minSdkVersion of 35, then yes smali will assemble dex 041. If you think it's a problem you can report it on smali repo. Still, dex 041 is perfectly compatible with Android 15, so I don't see what your problem is. You can't use an APK with minSdkVersion 35 on lower versions of Android anyway.

baksmali tool itself has option to get an api value whatever it is, also, i dont understand how baksmali will get value from stock apk? we are not providing any stock apk to build command, so it will definitely use minSdkVersion for api which is wrong

Because apktool was previously accepting all of the options regardless of which command is used, now it enforces correct usage, like every good tool should do. A good tool should not allow misusage.

minSdkVersion

bro, am not using apktool for jars like framework.jar and services.jar etc, i use smali/baksmali for them but the dex files present inside apks are issue, how 29 will be set for those classes.dex files which are inside apks?

I'm not bro. If the APK has minSdkVersion of 35, then yes smali will assemble dex 041. If you think it's a problem you can report it on smali repo. Still, dex 041 is perfectly compatible with Android 15, so I don't see what your problem is. You can't use an APK with minSdkVersion 35 on lower versions of Android anyway.

041 jar is an issue! see this, header size error due to 041 classes.dex file

just got 1 of your rom's apk file from that channel, and i can see 039 version classes.dex file. how you are using 039 for yourself and forcing others to use 041? why?

just got 1 of your rom's apk file from that channel, and i can see 039 version classes.dex file. how you are using 039 for yourself and forcing others to use 041? why?

Because I'm using custom smali/baksmali. I don't agree with the 040 and 041 being forced, the maintainers of the smali repo don't seem to understand that APKs/JARs with those dex versions don't exist in the wild. This incompatibility issue sounds like smali issue to me, not apktool.

just got 1 of your rom's apk file from that channel, and i can see 039 version classes.dex file. how you are using 039 for yourself and forcing others to use 041? why?

Because I'm using custom smali/baksmali. I don't agree with the 040 and 041 being forced, the maintainers of the smali repo don't seem to understand that APKs/JARs with those dex versions don't exist in the wild. This incompatibility issue sounds like smali issue to me, not apktool.

so you are using custom stuff your way and forcing others to not use an option which baksmali itself provides? -a option in smali is for setting api, which was reading it from apktool -api command, so how its a misuse?

smali/baksmali maintainer doing all well, not forcing anyone to use 041 if base apk is from android 15 rom

just got 1 of your rom's apk file from that channel, and i can see 039 version classes.dex file. how you are using 039 for yourself and forcing others to use 041? why?

Because I'm using custom smali/baksmali. I don't agree with the 040 and 041 being forced, the maintainers of the smali repo don't seem to understand that APKs/JARs with those dex versions don't exist in the wild. This incompatibility issue sounds like smali issue to me, not apktool.

so you are using custom stuff your way and forcing others to not use an option which baksmali itself provides? -a option in baksmali is for setting api, which was reading it from apktool -api command, so how its a misuse?

smali/baksmali maintainer doing all well, not forcing anyone to use 041 if base apk is from android 15 rom

Smaling with API higher than 29 produces dex 040 or 041, how is it "doing well" exactly? If you can't see the root of the problem, I have no reason discussing this further. It's easier barking here instead of complaining on smali repo, of course. Up to Connor how he wants to handle this.

just got 1 of your rom's apk file from that channel, and i can see 039 version classes.dex file. how you are using 039 for yourself and forcing others to use 041? why?

Because I'm using custom smali/baksmali. I don't agree with the 040 and 041 being forced, the maintainers of the smali repo don't seem to understand that APKs/JARs with those dex versions don't exist in the wild. This incompatibility issue sounds like smali issue to me, not apktool.

so you are using custom stuff your way and forcing others to not use an option which baksmali itself provides? -a option in baksmali is for setting api, which was reading it from apktool -api command, so how its a misuse?
smali/baksmali maintainer doing all well, not forcing anyone to use 041 if base apk is from android 15 rom

Smaling with API higher than 29 produces dex 040 or 041, how is it "doing well" exactly? If you can't see the root of the problem, I have no reason discussing this further. It's easier barking here instead of complaining on smali repo, of course. Up to Connor how he wants to handle this.

well, i hope you know that smali has an option "-a" which is to set api version someone wanna use. if i use api 34 there, then dex files are of version 040, which clearly make sense, smali has all dex version support properly and for each android.
i just want that support in apktool also, cause if smali tool is packed inside apktool, then why we are not allowed to use its native options like before? if someone dont specify -api then use the one which we extracted in apktool.yml simple, any big reason for not including -api in repack? i dont see
@iBotPeaches

041 jar is an issue! see this, header size error due to 041 classes.dex file

@iBotPeaches looks like smali is broken and builds 041 dex with 112-byte headers instead of the expected 120-byte HeaderV41 headers. Those 041 dex literally can't be baksmali'd again.
https://cs.android.com/android/platform/superproject/main/+/main:art/libdexfile/dex/dex_file.h;l=187

Which would still make it a smali issue...

I think since we are still on the 2.x branch we could bring back the ability to override the api-level (which overrides apktool.yml) as its passed to smali. I believe maybe those workarounds are used to workaround the bugs on 040/041 dex versions

I think since we are still on the 2.x branch we could bring back the ability to override the api-level (which overrides apktool.yml) as its passed to smali. I believe maybe those workarounds are used to workaround the bugs on 040/041 dex versions

there is another suggestion though, add an entry for dexversion in apktool.yml under minsdkversion. so it correctly follows minsdkversion for resources etc and dexversion for dex compilation, that way, we dont need -api parameter at all

this will keep the recompiled apk as close to sourced one.

I think since we are still on the 2.x branch we could bring back the ability to override the api-level (which overrides apktool.yml) as its passed to smali. I believe maybe those workarounds are used to workaround the bugs on 040/041 dex versions

Alright, but that still doesn't solve the possibility of building 041 dex by default if minSdkVersion >= 35 and -api is not specified to a lower API level explicitly, which means broken APKs.

It's related to this: #3725
Trying to decompile a dex 041 that was assembled with smali results in that error.

I never encountered the issue myself because in my smali/baksmali I restored the old versions map before Google decided to shove their 040 and 041 in there:

    public static int mapApiToDexVersion(int api) {
        if (api <= 23) {
            return 35;
        }
        if (api <= 25) {
            return 37;
        }
        if (api <= 27) {
            return 38;
        }
        return 39;
    }

But since you're using stock smali/baksmali for apktool, best to just put an upper limit of 29 on API level for smali, to ensure dex <= 039. More than 039 doesn't even exist in the wild, and 041 is broken completely, so even outputting those dex files shouldn't be a thing.

I think since we are still on the 2.x branch we could bring back the ability to override the api-level (which overrides apktool.yml) as its passed to smali. I believe maybe those workarounds are used to workaround the bugs on 040/041 dex versions

Alright, but that still doesn't solve the possibility of building 041 dex by default if minSdkVersion >= 35 and -api is not specified to a lower API level explicitly, which means broken APKs.

It's related to this: #3725 Trying to decompile a dex 041 that was assembled with smali results in that error.

I never encountered the issue myself because in my smali/baksmali I restored the old versions map before Google decided to shove their 040 and 041 in there:

    public static int mapApiToDexVersion(int api) {
        if (api <= 23) {
            return 35;
        }
        if (api <= 25) {
            return 37;
        }
        if (api <= 27) {
            return 38;
        }
        return 39;
    }

But since you're using stock smali/baksmali for apktool, best to just put an upper limit of 29 on API level for baksmali, to ensure dex <= 039. More than 039 doesn't even exist in the wild, and 041 is broken completely, so even outputting those dex files shouldn't be a thing.

make sense, thanks for understanding that. appreciated

@IgorEisberg one more thing, i saw you changed sources code to if (!mConfig.isForced() && !isModified(working, stored)) { return true; } in copying raw sources,

i am changing a file in smali_classes3 folder but apktools showing its copying raw classes3.dex file, why? never had such issue before

Haven't changed anything regarding that... what you're saying makes no sense.
How are you "changing a file in smali_classes3" if there are raw "classes*.dex" files in the folder?
You clearly decoded that APK without sources (-s/--no-src).

@IgorEisberg one more thing, i saw you changed sources code to if (!mConfig.isForced() && !isModified(working, stored)) { return true; } in copying raw sources,
i am changing a file in smali_classes3 folder but apktools showing its copying raw classes3.dex file, why? never had such issue before

Haven't changed anything regarding that... what you're saying makes no sense. How are you "changing a file in smali_classes3" if there are raw "classes*.dex" files in the folder? You clearly decoded that APK without sources (-s/--no-src).

yes, my bad, i mistakenly press a different menu and instantly removed comment, peace :)