[core] Possible issue: parsed APK has a reference to an adaptive icon that has no files to reference to

[AndroidDeveloperLB]

Sadly I can't fill this form correctly, because I use the online tool which doesn't even seem to show the version of Jadx:

http://www.javadecompilers.com/

The problematic file is:

base.zip

The website shows that the app icon is "adaptiveproduct_one":

This file doesn't exist when I extract the APK file. In fact there are almost no resource folders, no "mipmap" or "drawable" folders at all.

Using a different tool (here), I got 2 different candidates for icons:

1. "res/xm.png" , but this file is just this one:
   

2. "res/uG.xml" , and even though it failed to get its content as adaptive icon, on the website I got this:

<?xml version="1.0" encoding="utf-8"?>
<adaptive-icon xmlns:android="http://schemas.android.com/apk/res/android" xmlns:app="http://schemas.android.com/apk/res-auto" xmlns:aapt="http://schemas.android.com/aapt">
    <background>
        <bitmap android:src="@mipmap/adaptiveproduct_one_background_color_108"/>
    </background>
    <foreground>
        <bitmap android:src="@mipmap/adaptiveproduct_one_foreground_color_108"/>
    </foreground>
</adaptive-icon>

But, again, "mipmap" folder doesn't exist, and even the file "adaptiveproduct_one_foreground_color_108" doesn't exist anywhere using Jadx...

So, what I did is to try another website, here, and this is what I got from it:

base.apk.zip

Seems it has 2 resource folders: "res" and "resourced/res" (the one I saw before, without mipmap and drawable folders). Looking at "res", I can finally see "adaptiveproduct_one_foreground_color_108" file.

How could it be? Where did this folder and its files come from? Are those all in "resources.arsc" file somehow?

[jpstotz]

I am sorry but APK files with somehow obfuscated resources are not yet supported by Jadx.

As mentioned in #931 (comment) please use apktool to decompile those resources.

[AndroidDeveloperLB]

This is called obfuscated resources? How is it done?
I think all of the drawables are inside the "resources.arsc" file. Am I correct?

[jpstotz]

I am sorry but you are wrong. Inside resources.arsc are only strings. All the other (e.g. xml) resources are stored as separate file in the APK in the /res folder.

[AndroidDeveloperLB]

So it's in the "fV" file? How could it be this way? I didn't know it's possible.
How do such apps being made?

[jpstotz]

You are asking the wrong persons(s). If we would knew how such an app can be created we could implement in Jadx the necessary steps for a deobfuscation of the resource file names.

[AndroidDeveloperLB]

Sorry for that.
Do you know of any library that can be used on Android itself, handle APK files nicely, even if they are not available via a file-path (example is a Uri) ?

[jpstotz]

If a file is only available as URI, retrieve the data and save it. All Java based APK reading tools need a file because Java ZipFile class is used. And for on-device libraries I don't have any recommendations I do app-analysis only off-device.

[AndroidDeveloperLB]

@jpstotz If what you need is a fraction of what's in the APK, that's a bad solution.
If the APK is very large, it might not be possible (not enough space), and could take a long time.
Plus it causes creation of junk files which need to be removed.
Having a Uri, you can re-create the InputStream as you wish, hence reaching every possible byte on the file, and that's without copying anything to storage.
Sure it will be slower in some cases, but it's way faster than copying everything to storage first, especially for large files.
Not only that, but on some cases when you have a Uri, the app that provided it already has the file, so it's useless to copy it again, creating a duplicate.

And, even without a Uri, it's still very useful to handle InputStream because the APK might be inside a zipped file.
This is useful for the case of split APKs, for example.
The Android framework cannot handle split APKs at all, even with a file-path. Try to parse a split APK (not the base one) using it, and you will see.
Only via libraries it's possible.

[jpstotz]

@AndroidDeveloperLB That this the typical balance between disk-usage and CPU usage. Just saving the APK file grants you random access. Streaming it requires you to process/skip each entry again and again until you have found the one you are looking for (in worst case you end up in an algorithm with a run-time of O(n^2) hence is totally inefficient). And there is one more problem:

99% of all APKs can be read using a stream. However there are APKs that can't be accessed via ZipInputStream because they have an ZIP entry that use a compression without specifying the entry size. Such ZIP files can not be read. This is an oddity of the ZIP file format. See this Stackoverflow question for details.

[AndroidDeveloperLB]

Right. I actually edited this answer, and there are solutions for it, as I asked about here and here. Of course, there could be better solutions, but that's what I have for now, and it works fine on my app (here). I plan to improve it further, of course.

And it's not the APK issue itself, it's the ZIP file that has it inside. I don't think I ever saw an APK that has this issue. If you have, please show me an official link to it.

As for efficiency, again, it depends on the case. If all you want to do is to show app info: name, package name, app icon, version code, version name,... - you don't need most of the APK file, and there aren't many times that you will go back and forward in it.
And same goes for when you actually need to install it, because then most of the time you will go in linear direction like a normal stream, exactly like on a ZipFile.