universal-android-debloater icon indicating copy to clipboard operation
universal-android-debloater copied to clipboard

Display application name in addition to package name

Open hitnrun30 opened this issue 2 years ago • 12 comments

Just a suggestion, to help, add another column that is the associated app name, if known.

hitnrun30 avatar Oct 25 '21 12:10 hitnrun30

You can't easily get the application name from ADB. You need the aapt binary on your device and I don't know if I really want to do this.

This involves downloading the right aapt binary depending on your Android version and architecture. (I found this mirror on Github) but I'll host everything on this repo if I continue with this idea.

After getting the right aapt binary

adb push aapt /data/local/tmp
adb shell chmod 0755 /data/local/tmp/aapt

To get the app name :

adb shell /data/local/tmp/aapt-pie d badging </path/to/apk.apk> | grep 'application: label='

There is kind of an alternative to all of this but it's not a real solution. The apk filename is often the app name so we can just parse it from the path of the package and display it as the application name.

$ adb shell /data/local/tmp/aapt d badging /system/priv-app/StatementService/StatementService.apk | rg 'label='
application: label='Intent Filter Verification Service' icon=''

$ adb shell /data/local/tmp/aapt d badging /system/app/Calendar/Calendar.apk | rg 'label='
application: label='Calendar' icon='res/mipmap-anydpi-v26/ic_launcher.xml'

$ adb shell /data/local/tmp/aapt d badging /system/priv-app/qcrilmsgtunnel/qcrilmsgtunnel.apk | rg 'label='
application: label='' icon=''

$ adb shell /data/local/tmp/aapt d badging /system/priv-app/SettingsProvider/SettingsProvider.apk | rg 'label='
application: label='Settings Storage' icon='res/mipmap-mdpi-v4/ic_launcher_settings.png'

$ adb shell /data/local/tmp/aapt d badging /system/app/SecureElement/SecureElement.apk | rg 'label='
application: label='' icon=''

As you can see. The apk name is not always the app name. The thing is there isn't even always an label...

We need to keep in mind that most of the time, the application label isn't really more useful than the package name. However, it is much more complicated to display it.

0x192 avatar Feb 03 '22 17:02 0x192

The apk filename is often the app name so we can just parse it from the path of the package and display it as the application name.

That's not my experience at all. The app name and apk filename are usually not the same in my experience (mainly on Oneplus devices).

KarlRamstedt avatar Feb 06 '22 15:02 KarlRamstedt

That's not my experience at all. The app name and apk filename are usually not the same in my experience (mainly on Oneplus devices).

Yes. sometimes would have been more appropriate.

What do you think of this feature (with aapt) otherwise?

0x192 avatar Feb 11 '22 21:02 0x192

I dunno, the moment you gotta push packages to install on the device things get a bit messy for my taste. I suppose it wouldn't hurt to have it as an option, if it's not too complicated to implement, but I personally wouldn't use it; I can just use a package viewer on the phone to look up the package name if the description doesn't properly convey what the package is.

KarlRamstedt avatar Feb 18 '22 11:02 KarlRamstedt

Another option is to unzip the AndroidManifest.xml from the APK, then parse it. But in most cases, it's raw-binary-XML, so it needs a special parser. IDK if aapt already does this

Rudxain avatar Feb 03 '23 19:02 Rudxain

Why not use a dictionary? If I check the description of com.google.android.gm it says "Gmail". This could be directly shown in the list. The next step is to make that name searchable.

tbertels avatar Feb 10 '23 09:02 tbertels

Why not use a dictionary?

Because that requires extra maintenance, since the name could change at any time.

If I check the description of com.google.android.gm it says "Gmail". This could be directly shown in the list. The next step is to make that name searchable.

I agree with this. We could use the dictionary as a temporary solution, but that would still require work that would be "wasted" in the long run

Rudxain avatar Feb 10 '23 14:02 Rudxain

I wonder if system applications change name that often. Note that if that happens, the old name could then be kept in a searchable old_name property or just mentioned in the description.

tbertels avatar Feb 10 '23 16:02 tbertels

Note that if that happens, the old name could then be kept in a searchable old_name property or just mentioned in the description.

Wait, that gives me an idea. What if we automate this process? Of course, not all apps can have their names automatically updated. We could fetch and parse the name by using the app-market URLs (not the URL per-se, I mean the page being pointed by the link)

Rudxain avatar Feb 10 '23 17:02 Rudxain

There's about 400 apps with a Google Play link, and less than 10 for the Galaxy Store out of 2327 apps. That's a start.

An other way, mentioned by KarlRamstedt is to use a package viewer. Package Name Viewer 2.0 (https://play.google.com/store/apps/details?id=com.csdroid.pkg) for example shows system apps and their names when available and allows the user to export them in a .csv file.

tbertels avatar Feb 10 '23 17:02 tbertels

Package Viewer 2.0 [...] allows the user to export them in a .csv file

Nice! this will make everything much easier. But the only way I know to automate the CSV Export is to simulate a UI touch (which can be done via ADB). Perhaps, an easier option is to make a dedicated app that listens to a broadcast or an intent coming from ADB, then responds with the CSV

Rudxain avatar Feb 10 '23 20:02 Rudxain

I got an idea. We could write a script that sends HTTP HEAD requests to G Play Store, S Galaxy Store, and etc., to check if each pack exists there, and if it does, add the link to the description.

Or even better, we could add this functionality directly to UAD. Everytime the user clicks a pack to see its description, UAD would check if there's a market link available. To make it more efficient, it could cache results.

To make it smarter, it should parse the pack ID to ignore markets and prioritize order: for example, if the ID contains "samsung", UAD will only check GPS & SGS, no need to check other stores. If the ID doesn't contain any known OEM name, and the list isn't Oem, it won't make any request

Rudxain avatar Feb 13 '23 19:02 Rudxain