[WDX/WLX] APK-wdx - Android application packages

[milo1012]

APK-wdx 2.1

An Android application package (APK) content plug-in (wdx) for Total Commander.
Scans .apk files for specific information. (App name, version, target and minimum OS, etc.)

Can be used in all program parts where content plug-ins are supported.
(besides changing them in TCs 'Change Attributes...' and for 'Synchronize Dirs...')

As of version 2.0 you can also register the plug-in as a Lister plug-in (wlx),
so that you can see the App icons in TC's preview/thumbnail mode, and view
assembled App information in Lister/QuickView.

Uses a custom Android Asset Packaging Tool DLL file in order to work,
but you can change that to use the external official retail tool (aapt.exe) instead.

The plug-in fields are self-explanatory.
Note that not all fields are available for specific APK files, so they might be empty or zero.
The language fields use the default App name when no specific language string was found.

The field 'String pool' (the very last field, following the language-specific App names) parses the 'resource table string pool' in the APK,
meaning that all strings that are available in the strings.xml and the names for resource files (e.g. Pictures/Images) can be searched here.
You can use TC's Lister to view that same string pool (if registered as Lister plug-in), but with full Unicode support.



Current Version 2.1:
(32+64 bit, source available)
totalcmd.net
SHA1: 01a5ce9a1f18e31073145194653ab1d2316a1765


Old Version 2.0:
(32+64 bit)
totalcmd.net
SHA1: bbd1b0c80a0ac019a287bf75f94fdc7701de1d26

Old Version 1.5:
(32+64 bit)
totalcmd.net
SHA1: ab85ddad73c5ff80e363694947eba9943d2b57ab

Old Version 0.9:
(32+64 bit+source)
[URL=hhttp://en.file-upload.net/download-9515212/APK-wdx_0_9.rar.htmll]APK-wdx_0_9.rar[/URL]
SHA1: 92a15de8ff6abcda73012f76bb63e54044400946

Old Version 0.8:
(32+64 bit+source)
APK-wdx.rar
SHA1: ec55732cde1b8649d364d4aa75e1c369adf761f4

Please report bugs and give me some feedback.

[seb-]

Thanks!

Its very helpful when you're dealing with a lot of apk files in different versions and the naming is not very good

[kenshicu]

Very good, the one thing that he has not enough is, showing the icon of applications

[milo1012]

Very good, the one thing that he has not enough is, showing the icon of applications

There's not much I can do, because currently there's no way a content plugin can return complex data to TC, such as an Icon.
Furthermore the Android Icons are in a different format, which needs to be decompressed and converted in order to be shown somehow in TC's file list.

Maybe I'll merge a Lister plugin Interface in one of the next versions,
to show all the important App info and the (extracted) Icon, but I can't make any promises.

[Skif_off]

2milo1012
Can you add custom path for aapt.exe? It would be great because Android ADB use aapt.exe too, for example: APK.ini

Code: Select all

[Options]
path = %COMMANDER_PATH%\Plugins\wfx\ADB\bin\aapt.exe

P.S. But now:
\wfx\ADB\bin\aapt.exe - 855040 b with date 2013.03.13 and
\wdx\APK-wdx\aapt.exe - 1466368 b & 2014.12.21
I think must update.

[milo1012]

Can you add custom path for aapt.exe?

I could, but the output format changes slightly every few versions or so.
I already had to adapt my RegEx after updating to that newer version I currently use.
If you'd use an older version some fields will probably not work any more.

I'll see what I can do.
Maybe if I make custom RegEx available in an cfg or ini file
users can see on there own how they adapt it to different aapt versions.

BTW, you can see the version with:

Code: Select all

aapt.exe v

The one currently used is v0.2-1635773.

[Skif_off]

but the output format changes slightly every few versions or so.

I do not knew and yes, it is problem. Maybe you will be able to establish a dialogue with jakubklos for synchronous updates? Probably it would be the most friendly solution for users (for example I do weakly know regular expressions).

Maybe if I make custom RegEx available in an cfg or ini file

and we will be able to update binaries in case of need. Good idea. Is will don't greatly affect the speed?

[milo1012]

Maybe you will be able to establish a dialogue with jakubklos for synchronous updates? Probably it would be the most friendly solution for users (for example I do weakly know regular expressions).

I think it works fine for now, no need to bother with RegEx by yourself. I'll do some tests to take the old aapt version into account.
Until a new major Android version will change the APK file format (I doubt that for the foreseeable future), things should work, even for apps targeting the newest SDK.

Is will don't greatly affect the speed?

No, it's just about getting the info out of the maybe ~10k aapt output, which should work in an instant, no matter how complicated your Expression is.

I will take another look at the aapt source, so that I might be able to directly use that code instead of relying on an external process.
But don't quote me on that. To be honest: it really is quite a task, due to being extensively nested in the Android core.

[kenshicu]

Very good, the one thing that he has not enough is, showing the icon of applications

There's not much I can do, because currently there's no way a content plugin can return complex data to TC, such as an Icon.
Furthermore the Android Icons are in a different format, which needs to be decompressed and converted in order to be shown somehow in TC's file list.

Maybe I'll merge a Lister plugin Interface in one of the next versions,
to show all the important App info and the (extracted) Icon, but I can't make any promises.

Very well, in any case, thank you for the contribution, very useful

[milo1012]

New Version 1.5!

• major improvement: a custom aapt DLL file, which is used instead of the external exe file
  for a great general speed improvement (assuming that I/O performance isn't a limiting factor),
  plus it can now use native x64 code
  (based on the newest Android 5.1 code from March 2015)
• added options to use the aapt.exe program nonetheless, with a possible custom path
• caching can now be customized with a large number of entries, to improve usability,
  like when having low I/O performance or when a lot of sorting in custom columns takes place
  (uses the lz4 compression library to keep memory requirements low)
• fixed: app version sometimes showed value for 'platformBuildVersionName' instead of the true version string
• new field: App main icon file (path in the archive)
• included SDK 22
• modified some RegEx to recognize older aapt.exe program's output
• most paths > 259 characters (MAX_PATH) should work now, due to using SFN paths in that case
• many internal improvements

Check the first post for the new file.

[milo1012]

New Version 2.0!

• major improvement: merged a Lister (wlx) interface, which will show the app icons as preview images (thumbnails) in TC,
  and shows all assembled App information in the Lister/QuickView window;
  additional lister features: text highlight/copy, text search, word wrap, font size change (numpad add/subtract)
• added options for lister interface: 'hq downsampling' and 'raw output only'
• new field: App launcher activity name (might be empty)
• new field: App provided components (e.g. widget, wallpaper, launcher, search, ...)
• improved RegEx for 'Screen Sizes' and 'Resolutions', to avoid unnecessary string separators
• SDK 22 is now called 'Lollipop MR1'
• SDK names will now show the SDK number in parentheses for newer versions, where a name is not implemented yet
• internal improvements

Check the first post for the new file.

[mortalis]

Hi. Could you help me?

Using this plugin gives me

aapt.dll n/a

for all columns

I add a custom column (for example "[=apk.Package]") and it shows me that info.
Tried to restart and changed the aapt.exe path in the contplug.ini file.

TC version: 8.01 32-bit.
OS: Windows XP SP3
Plugin version: 2.0

Thanks.

[mortalis]

Sorry. It's solved.
First didn't notice the UseAaptExe=0 option.

Anyway suppose it means the aapt.dll not working, at least for me.

---

Another question I have.
I only need the names of the .apk files. So I add the Application Name column.
But it the scanning of the files info is rather slow.
I suppose it's because the plugin scans all the info of the .apk files.

So (if I'm right in the last sentence) is it possible to limit the scanning only to the selected column, or explicitly to the app name so that the info is showed faster?

Thanks.

[milo1012]

Anyway suppose it means the aapt.dll not working, at least for me.

Well, the dll needs to be in the same dir as the plugin file
(the 32-bit plug-in (APK.wdx) needs the aapt.dll file, the x64 plug-in (APK.wdx64) needs the aapt64.dll file).
Other than that, the only explanations I have w/o knowing further details:
The DLL is locked by other applications, such as a virus scanner, or the file is corrupted (disk read error).
In the latter case, try to unpack the dll from the plug-in archive again, or try a different plug-in location.

But it the scanning of the files info is rather slow.
I suppose it's because the plugin scans all the info of the .apk files.

So (if I'm right in the last sentence) is it possible to limit the scanning only to the selected column, or explicitly to the app name so that the info is showed faster?

It's true that I parse the info from the "badging" aapt output.
But that is not an issue, unless you have an ancient CPU (below ~500 MHz).
Of course, the DLL will be measurably faster than the exe, so you best try to get the dll working.
But Disk I/O performance is still the main bottleneck.
The file is mapped into RAM by aapt (no matter if using dll file or the aapt.exe).
After that it will be backed up by the Windows file cache.

I suggest that you try the plug-in on a faster disk, or try a defragmentation (if using a classic HDD),
or just copy some apk files to a different disk or an usb drive and compare performance.
And like I already guessed above: there might be a virus scanner interfering, and scanning the file before aapt even gets a hand on it.

There's nothing I can do to speed up the plug-in much further, as I rely on the aapt core.
And I never had trouble for any of the systems I tested and used the plug-in on,
as it was clear that I/O performance was always the main speed factor.

[milo1012]

New Version 2.1!

• the plugin can now optionally detect and use the largest available app (launcher) icon for TC's thumbnails
  and Lister/QuickView (new ini option) (reason: aapt returns the mdpi icon path in many cases)
• high quality app launcher icon downsampling can now optionally be used automatically, depending on the system CPU (when ListerHqDownsampling=2)
• high quality downsampling auto detection is now the default for new plugin installations
• added Total Commander 9.0 Unicode 'fulltext' search support (content plugin) -> you should now be able to search for any Unicode string in the app string pool
• the aapt string pool output will now have invalid UTF-8 characters replaced, making the flawed string pool output for some apps finally "readable" (formerly recoded to ANSI)
• you can now optionally show nothing but the assempled app info fields in Lister/QuickView, skipping the raw aapt and the string pool output completely (might be faster for QuickView when navigating through many apk files) (new option value: ListerRawOutputOnly=2)
• fixed a possible crash in 32-bit when using TC's 'fulltext' search in the string pool (content plugin)
• the text window in Lister/QuickView window will now use the global system color for text and background (formerly black text on black background with some high contrast color settings)
• added SDK 23 name
• raised maximum string pool length

Check the first post for the new file.