Apktool: kotlin / wrong 'res' sub-folderes mapping.

[eladkarako]

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?)

[eladkarako]

OK I've found out whats wrong with the APK real quick,
I've compared the unzipped APK from 'dist' vs. the original APK,
and it seems that several sub-folders under 'res' got the wrong name.

this is non-code related, but a resources mapping issue,
it only seems to happen in this kotlin-based APK.

should be	got from apktool
drawable-hdpi-v4	drawable-hdpi
drawable-mdpi-v4	drawable-mdpi
drawable-nodpi-v4	drawable-nodpi
drawable-xhdpi-v4	drawable-xhdpi
layout-sw600dp-v13	layout-sw600dp
layout-v16	removed totally (no folder) edit: the content of the folder got moved to under res/layout/

it seems that the 'dash' plus version number is gone, and 'layout-v16' is completely gone,
since I'm not doing any changes in those resources I'll try to simply copy them unzipped
(encoded) original APK, to the unzipped (recompiled) APK I've got from APKTool,

how does the folder mapping get decided? is it simply a reading of the folder tree,
or is it mapped against an XML that describes all the resources? and that's how the new folder structure is created?

[eladkarako]

I can see now that the content of the missing folder res/layout-v16/(raw APK unzipping),
got into the res/layout/ folder

[eladkarako]

I've tried de/recompile with --no-res,
and manually completing all the missing files,
but the result APK does not have an icon, and would not install.

[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 - https://github.com/iBotPeaches/Apktool/issues/1272#issuecomment-379345005 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.

[eladkarako]

hmm.. I see,
I've tried to solved it by copying the missing folders over, but (now I see..) APKTool obviously encodes resource arsc too...

b.t.w. I only see this issue in kotlin based APKs, so my "tactic" is browsing apkpure website for the latest, older, version of that APK that doesn't uses kotlin... (maybe processing of a kotlin-based APKs, easily identify by a 'kotlin' folder present under the root of the archive, should use alternate resource-parsing.. 🤔)

[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...

[eladkarako]

@iddoeldor it does not seems to be related. perhaps you should open a new issue with the aapt exception. (have you tries extraction from shorter directory tree?)

[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?

[eladkarako]

@DrAutissimo, not really, just workarounds.

One workaround is for simple tasks such as just modding the android manifest xml,
once I've recompiled the APK,
I've got into the dist folder, unzipped the APK,
on a different folder I've JUST UNZIPPED the original APK,
then I've moved the (now in a binary format) modded android manifest xml to the folder of the unzipped original apk, overwriting the old one.
I've then got into META-INF, deleted just the stuff related to the signature (RSA, SF, MF files) leaving everything else untouched.

I've then JUST ZIPPED back the files, renamed the extension to apk,
signed it, and 4byte aligned it.

so,

You first decompile everything,
this way you get access to smali, assets and resources,
after you've done editing and compiling you don't use the actual dist apk,
but copy some of its files over the files of the original apk extracted in another folder.

You can even try copy modified (after you build the project, I mean) files,
and overwrite their original version in the res/ folder of the original "just-unzipped" apk. just never overwrite or copy over the re-generated resources.arsc, this way you keep your end result non-corrupted.

Note: this isn't mentioned enough in the process of using APKTool,
but the signing and aligning is part of the process and can not be avoided,
it requires you to generate (at least once) a self-signed keystore, then use that keystore to sign the APK, it all uses executes the comes with Java installations, see:
https://gist.github.com/eladkarako/caa019c0ee5abff8e14ad26f44236c3a#file-jarsign-zip-apk-xpi-jar-files-with-keystore-full-readme-md

[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?

[eladkarako]

Again:

Yes you work with three folders:
1- unzip the original APK (not decompile).
2- decompile the original APK.

All XMLs are binary in the APK (zip archive),
APKTool makes them readable and editable (decompile),
and back to binary (recompile).

edit as much XMLs under /res folder as you wish.

3- After you recompile ("build") 2, you'll get in the dist folder an APK (that will not work...),
unzip it, this is the third folder everything in here is binary (similar to 1).

TRY copy JUST the (now binary) files from 3 over to the same place at 1, overwriting the old ones at 1.

you are now working just with 1.

in meta inf remove old signature files,
zip 1 files, change extension to APK, sign and align.
try to install.

If you can - you have successfully worked-around the issue and created a mod
of the original APK.

The overall process is simple, but there are several steps. the confusing part is that you don't actually use the whole APK from the dist,
just pin-pick files from it.

Hope it helps.

[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