[BUG] Qualifier omittion causes conflict (Android 15 AOSP)

[IgorEisberg]

Conflict happens because Apktool currently doesn't preserve qualifiers as stored in resources.arsc.
While I get that omitting the API version qualifier makes sense in certain instances, apparently AAPT2 wasn't designed that way.
In this example values-en-rXA-neuter clashes with values-en-rXA-neuter-v33 because the -v33 is being omitted, the only way to decompile this APK is to not manipulate the output qualifiers with sdkVersion >= getNaturalSdkVersionRequirement().

Source:

Apktool/brut.apktool/apktool-lib/src/main/java/brut/androlib/res/data/ResConfigFlags.java

Lines 559 to 561 in 2461481

	if (mSdkVersion > 0 && mSdkVersion >= getNaturalSdkVersionRequirement()) {
	sb.append("-v").append(mSdkVersion);
	}

APK: https://drive.google.com/file/d/1FVp1ZPv858hpzCuKx2o5BnA3uVtwNxmK/view

Log:

I: Using Apktool 2.10.1-SNAPSHOT on PermissionController.apk with 24 threads
I: Baksmaling classes.dex...
I: Loading resource table...
I: Baksmaling classes2.dex...
Exception in thread "main" brut.androlib.exceptions.AndrolibException: Multiple resources: spec=0x7f1302a5 string/permission_description_summary_storage, config=-en-rXA-neuter
        at brut.androlib.res.data.ResType.addResource(SourceFile:0)
        at brut.androlib.res.decoder.ARSCDecoder.readResourceTable(SourceFile:0)
        at brut.androlib.res.decoder.ARSCDecoder.decode(SourceFile)
        at brut.androlib.res.data.ResTable.loadResPackagesFromApk(SourceFile)
        at brut.androlib.ApkDecoder.decodeResources(SourceFile:0)
        at brut.androlib.ApkDecoder.decode(SourceFile:0)
        at brut.apktool.Main.main(SourceFile:0)

[iBotPeaches]

The only way to safely remove that is to remove appt1 support, which may not be too crazy of an idea.

[IgorEisberg]

The only way to safely remove that is to remove appt1 support, which may not be too crazy of an idea.

My man, I removed aapt1 support on our private fork years ago. It has been obsolete for so long already.
One can always use an older version of apktool if aapt1 is absolutely not optional.
If you want me to clean up aapt1 neatly, let me know and I'll make a pull request.

[iBotPeaches]

I'll release 2.11.x before end of year - then we can start 3.x and kill aapt1. I just want a smali release and might have to poke those guys so we can get a stable smali cut.

[successor55]

I use https://apkeditor.io for setting debuggable or patching network security when nothing else parses the apk

[HassanMirza01]

i saw this change in your pull request @IgorEisberg but seems like this has something wrong, i was trying on MIUI apks and i can't see any -vXX in res folders even though aapt2 dump confirms many folders in -vXX form, like anim-v34.

Then i thought may be its MIUI's apps issue and anyone can get triggered with MIUI name, i unpacked whatsapp apk and i can see many -vXX in res which are not even in apk's res/ folder, i know resources.arsc has mapping for it but why apktool not respecting it?

inshort, this change never had any impact before, nor has now. or may be i dont understand how its working

[IgorEisberg]

i saw this change in your pull request @IgorEisberg but seems like this has something wrong, i was trying on MIUI apks and i can't see any -vXX in res folders even though aapt2 dump confirms many folders in -vXX form, like anim-v34.

Then i thought may be its MIUI's apps issue and anyone can get triggered with MIUI name, i unpacked whatsapp apk and i can see many -vXX in res which are not even in apk's res/ folder, i know resources.arsc has mapping for it but why apktool not respecting it?

inshort, this change never had any impact before, nor has now. or may be i dont understand how its working

Apktool doesn't preserve original file and folder names, it outputs according to the qualifiers stored in resources.arsc.
If there is no API level specified for a resources, then the output folder won't have one either.