Bug: Unable to fetch app-names (labels) of some apps properly

[AndroidDeveloperLB]

Running the sample, I've found this app that it failed to get its app-name (label) properly :

apk label is different for "com.google.android.networkstack.permissionconfig" on /system/priv-app/NetworkPermissionConfigGoogle/NetworkPermissionConfigGoogle.apk : correct one is: "com.android.server.NetworkPermissionConfig" vs found: "com.google.android.networkstack.permissionconfig"isSystemApp?true

This might be related:

hsiafan/apk-parser#123
hsiafan/apk-parser#99

Attached the problematic APK:

NetworkPermissionConfigGoogle.zip

EDIT: another case:

apk label is different for "com.google.android.gms" on /product/priv-app/PrebuiltGmsCore/PrebuiltGmsCore.apk : correct one is: "Google Play services" vs found: "resourceId:0x7f1a0033"

It became quite large, so I had to split it. Rename "PrebuiltGmsCore.zip" to "PrebuiltGmsCore.zip.001" and "PrebuiltGmsCore2.zip" to "PrebuiltGmsCore.zip.002" , and "PrebuiltGmsCore3.zip" to "PrebuiltGmsCore.zip.003"

PrebuiltGmsCore.zip
PrebuiltGmsCore2.zip
PrebuiltGmsCore3.zip

[AndroidDeveloperLB]

Another example, originated from Vivo V23:

apk label is different for "com.mediatek.ims" on /system/priv-app/ImsService/ImsService.apk : correct one is: "com.mediatek.ims.ImsApp" vs found: "com.mediatek.ims" isSystemApp?true

ImsService.zip

[AndroidDeveloperLB]

Another example, from Samsung Galaxy A32:

apk label is different for "com.android.stk" on /system/app/Stk/Stk.apk : correct one is: "SIM Toolkit" vs found: "SIM toolkit" isSystemApp?true
apk label is different for "com.android.stk2" on /system/app/Stk2/Stk2.apk : correct one is: "SIM Toolkit2" vs found: "SIM toolkit" isSystemApp?true
apk label is different for "com.samsung.app.newtrim" on /system/app/VideoTrimmer/VideoTrimmer.apk : correct one is: "Video trimmer" vs found: "Video Trimmer" isSystemApp?true

APKs:

apks.zip

[AndroidDeveloperLB]

More examples, this time including apps that are not built-in:

apk label is different for "com.unicell.pangoandroid" on /data/app/~~1tUbh_pu1ADTMAVluBDmOg==/com.unicell.pangoandroid-uvBuwCw2W_yUsg5wwe9D1Q==/base.apk : correct one is: "Pango" vs found: "פנגו" isSystemApp?false
apk label is different for "com.google.android.ext.shared" on /system/app/GoogleExtShared/GoogleExtShared.apk : correct one is: "Android Shared Library" vs found: "{7:65536}" isSystemApp?true
apk label is different for "android.autoinstalls.config.google.nexus" on /product/app/PlayAutoInstallConfig/PlayAutoInstallConfig.apk : correct one is: "Device configuration" vs found: "@string/app_name" isSystemApp?true
apk label is different for "com.samsung.slsi.telephony.oemril" on /system_ext/priv-app/OemRilService/OemRilService.apk : correct one is: "com.samsung.slsi.telephony.oemril.OemRilApp" vs found: "com.samsung.slsi.telephony.oemril" isSystemApp?true

Attached for some:

labels.zip

[msdhedhi]

I ran into a related issue where the original apk-parser could no longer consume apk files from an A15 aosp build. I was able to fork/patch the library: msdhedhi/apk-parser@6104ca5

[AndroidDeveloperLB]

@msdhedhi Interesting. Very appreciate it that you've contacted me here and offer this.
Have you tested the parsing of the apps I've mentioned?
Also, how did you find about this solution? Where did you look at?
And why not fork from my repository?

[msdhedhi]

I tried the apks in "labels.zip". The manifest for OemRilService.apk does not have a "android:label" attribute so the label is being returned as null.
GoogleExtShared.apk reports the correct label "Android Services Library"
PlayAutoInstallConfig.apk is returning the label as "@string/app_name" so that still needs to be looked at.
To debug this issue, i looked at the struct ResTable_type in file https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r5/libs/androidfw/include/androidfw/ResourceTypes.h
The following checkin added support for new formats
https://android.googlesource.com/platform/frameworks/base/+/a1f2bce0e56185d8a3ddbbb75cf9daacdcb5a3d2%5E%21/libs/androidfw/include/androidfw/ResourceTypes.h
I did not fork from your repo since it has pulled in a bunch of androidx imports and kotlkin code and our solution currently requires it to be all java without any andoridx/kotlin libraries.

[AndroidDeveloperLB]

Those libraries are quite common on Android, and Kotlin is becoming more and more popular. Besides, creating a release version using Proguard, a lot would be removed anyway if not used.
I also applied some fixes on the way.
You use it outside of Android, perhaps?

I had created the sample to have some tests on the current device, too, to check for weird issues. Such a thing helps to find possible issues on the repository in parsing APKs, from actual scenarios.
That's how I've found all these APK files.

Is it the only thing you've fixed?

[AndroidDeveloperLB]

@msdhedhi I tried to add your changes to mine (was hard but I think I got it). Still got 36 errors of label fetching.
About "OemRilService.apk", Android OS says its label isn't empty but "com.samsung.slsi.telephony.oemril.OemRilApp".

About "GoogleExtShared.apk", seems it's not installed anymore on my device, but it's installed on Android emulator, and indeed it got "Android Shared Library" as label, so you made the detection better indeed.

About "PlayAutoInstallConfig.apk", sadly the app isn't installed anymore and I can't install it on my device, but I can on the emulator.

I wanted now to compare before&after , on my device and on emulator.

Device (Pixel 6, Android 15):
label errors: 25 before, 36 after
However, number of errors of not being able to parse APK files at all decreased in , from 94 to 17.

Emulator (API 34 - Android 14):
label errors: 2 before, 1 after.

So again an improvement in label detection.
This time it failed to get the label of "com.google.android.ondevicepersonalization.services" (OnDevicePersonalizationGoogle.apk, attached here). Supposed to be "com.android.ondevicepersonalization.services.OnDevicePersonalizationApplication". Seems similar case of "OemRilService.apk". Perhaps the OS takes the path to the class that extends Application for some reason. I've noticed it when checking the manifest via online APK parsers:

http://www.javadecompilers.com/apk
https://sisik.eu/apk-tool

OnDevicePersonalizationGoogle.zip

Please test on a real device against all APK files of the OS. This way you could find issues as I've found.
Here's the APK of my sample, to test on all installed apps:

app-debug.zip

[AndroidDeveloperLB]

@msdhedhi Here are many more APK files that got the app label wrong. Sometimes it's just by a single letter for some reason (upper-case vs lower-case) :

apks.zip

apks2.zip

apks3.zip

Another one is a bit big, so here is a link to it:
https://www.apkmirror.com/apk/google-inc/pixel-camera-services/pixel-camera-services-2-0-654932140-02-release/

[msdhedhi]

@AndroidDeveloperLB I am attaching the app manifest for OnDevicePersonalizationGoogle.apk. It has no label
AndroidManifest.txt
The app has no label so when Android loads it, it shows the package name instead of the lablel.
PixelCameraServices seems to print the correct label after my latest commit.
I will try others when I get some time.
Our solution is a big unique where we use the apk-parser library on a java springboot server. We do not use library on android OS. We noticed some issues with parsing apks generated by Android 15 aosp build process so we decided to patch the apk-parser to support some new flags.

[AndroidDeveloperLB]

@msdhedhi Yes, for OnDevicePersonalizationGoogle, I've updated my repository to handle this, so that it will fetch the packageName&app-class in this case.

However, as I wrote, there are still many weird cases it doesn't return the same names. Sometimes by just a single letter change for some reason.

You should consider using Android stuff. It offers many more features this way. Also this way we can test better, as it was quite hard for me to patch my code based on your changes, manually...