kotlin / wrong 'res' sub-folderes mapping.

[ghost]

Information

1. Version: 2.4.1-b05f19-SNAPSHOT - https://github.com/eladkarako/icompile/releases/download/latest/apktool-cli-all_2.4.1-b05f19-SNAPSHOT.jar.zip
2. OS: Windows
3. APK from Google-Play

A kotlin based APK is decompiled successfully,
for re-compilation I do what I always do, which is
build with APKTool, unzip, copy original META-INF (removing MANIFEST.MF, CERT.SF, CERT.RSA),
zip it, rename it to apk, sign it with 'foo' keystore and 4byte-align it.
I do it because APKTool does not copy the META-INF folder properly (another bug..)
this method generates a functional APK every time,
but with kotlin apks I get an apk without an icon (green default android icon which makes it look like those malware apk you get some times from shady ad-filled websites...)

I wonder if anyone can try to decompile/recompile this one,
com.goldtouch.ynet.apk.zip
will appreciate any help from @iBotPeaches (is there an already opened issue for this?)

[iBotPeaches]

You've struck a long time issue and not easily fixable. So here is the short version.

How do you know the directory is drawable-xhdpi-v4 or not? If you just look at the directory, that is your first guess. However, if you read the qualifiers. It only builds the directory folder name from that. Version qualifiers are implicit and added only when another qualifier used is past a certain Android milestone.

This allows Android to toss out parsing folders very quickly because it knows on Froyo it can't parse "xxxxhdpi" or "dark" by the added "v13" at the end, since Froyo (8) is not larger than 13. So when you are building assets from resources, you need to unpack resources from application. Do you trust the filepath in zip? or the filepath generated from qualifier?

Should those match? Or not?

What happens with recording uncompressed assets, those are working at zip level (not qualifier level). So we already have a problem. We work in both resources (resources.arsc) and binary apk (uncompressed file recording) so these naturally won't match.

I tried to fix this in past - #1272 (comment) and https://github.com/iBotPeaches/Apktool/pull/1758/files and this broke nearly every application out there, while only fixing a few Windows issue.

This requires investigation, time and more.

[iddoeldor]

having the same issue w/ il.co.yes.yesgo

W: aapt: brut.common.BrutException: brut.common.BrutException: Could not extract resource: /prebuilt/aapt/linux/aapt (defaulting to $PATH binary)
W: First type is not attr!
W: A/        ( 7774): First type is not attr!
brut.androlib.AndrolibException: brut.common.BrutException: could not exec (exit code = 134): [aapt, p, --min-sdk-version, 21, --target-sdk-version, 26, --ver...

[Autissima]

I think I have the same issue and sadly I don't really understand android too well .-.

Is there some sort of manual fix to this that you found?

[Autissima]

Ye, I know how to do the signing and aligning, I could decompile and recompile with keeping original resources, thanks, I'll try around a little bit :)

Edit:
Wait, do you mean I decompile it once, then copy that in another folder, and copy the changed things back afterwards?
Because just having a decompressed apk will not have an apktools.yml

Edit 2:
Ok, so what I wanna do is change some colours in an app (I've got permission from the dev to do this etc.) and I can replace the compiled files from the original with some where I changed the colour values (as defined in an xml), but it doesn't do anything.

Sorry if I am asking you here, but, am I misunderstanding where the colours get defined?

[iBotPeaches]

I slipped in a wishlist item into ROADMAP for this. Commit above. I don't see anything happening in here, because we are missing what is seemed to be a bug with a massive feature request/tweak.

Closing - https://github.com/iBotPeaches/Apktool/blob/master/ROADMAP.md#implicit-qualifiers-cleanup