parsing APK crashes if targetSdkVersion is set to a string value

[eighthave]

Describe what you wanted to do

Inspect these APKs:

https://github.com/googlesamples/android-testdpc/releases/download/6.0.0-preview/TestDPC_6000.apk
https://github.com/googlesamples/android-testdpc/releases/download/5.0.0-preview/TestDPC_5000.apk
https://github.com/googlesamples/android-testdpc/releases/download/v3.0.2/TestDPC_N_3002.apk
https://github.com/googlesamples/android-testdpc/releases/download/v3.0.3/TestDPC_N_3003.apk
https://github.com/googlesamples/android-testdpc/releases/download/5.0.1-preview/TestDPC_5001.apk

Describe what you expected

This should work:

from androguard.core.apk import APK
apk = APK('TestDPC_6000.apk')

Describe what actually happened

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/dist-packages/androguard/core/apk/__init__.py", line 294, in __init__
    self._apk_analysis()
  File "/usr/local/lib/python3.9/dist-packages/androguard/core/apk/__init__.py", line 371, in _apk_analysis
    self.permission_module = androconf.load_api_specific_resource_module(
  File "/usr/local/lib/python3.9/dist-packages/androguard/core/androconf.py", line 261, in load_api_specific_resource_module
    ret = loader[resource_name](api)
  File "/usr/local/lib/python3.9/dist-packages/androguard/core/api_specific_resources/__init__.py", line 36, in load_permissions
    apilevel = int(apilevel)
ValueError: invalid literal for int() with base 10: 'Q'

System Information

• Androguard Version: 4.1.1 and 3.4.0~a2
• Python Version: 3.11.2
• Operating System: Debian

[eighthave]

Hmm, makes me think about androguard/androguard#1026 too. Seems like on both cases, androguard should do what the Android OS does when parsing these. That might mean just ignoring targetSdkVersion or maybe returning a default value?

[erev0s]

Hi @eighthave, Android internally makes the conversion as defined here.
It would be nice to have it and it seems easy to be implemented.
Will add a flag to it, so I can get back to it in the future or if someone else wants to pick it up.

[eighthave]

I don't think Build.java is where this parsing behavior is defined, or at least I can't see anything related there. Looks like here is the parsing:

• https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android14-release/core/java/android/content/pm/PackageParser.java#2201
• https://android.googlesource.com/platform/frameworks/base/+/refs/heads/android14-release/core/java/android/content/pm/PackageParser.java#2588

And the crazy thing is that it looks like the parser there supports using a string there! APK formats are always full of surprises. The documentation says this field is "an integer":
https://developer.android.com/guide/topics/manifest/uses-sdk-element#target

[erev0s]

Hi @eighthave, I was not clear enough thus the confusion.
I meant that the string/int values are described in the build.java file. As you correctly pointed out the computeTargetSdkVersion method helps with this "translation" and if you notice closely you will see how the build.java is being used (Although PackageParser is deprecated the exact same things apply for ParsingPackageUtils.java).

Indeed you are right, the developer documentation from Android states it as an integer, presumably because eventually it is converted to one. I can agree that the documentation can be improved.

[eighthave]

Right, I see what you mean, Build is used in translating the string value to the right integer. I just found the table that's used, the crazy thing is that it is read from the System Properties:

[erev0s]

After giving some thought over it and seeing this issue, i think the next steps make sense:

• Offer a method to do the mapping of a string to an API level
• If the mapping fails, consider having some default value being returned
• Warn the user that this is a valid case only for pre-release and the "check" is happening only against the platform running on (so its a specific edge case I would say)

given the inconsistency of other tools against this and the fact that this is an edge case, I would say it is of low priority but regardless its a "nice to have".