Une façon (plutôt grossière) de voir pour quelle architecture les bibliothèques natives d'un APK sont conçues est de le décompresser (ce n'est qu'un fichier zip) et de jeter un œil au dossier libs - si l'application contient des bibliothèques natives, elles seront divisées en les sous-dossiers suivants à l'intérieur (avec les bibliothèques compilées à l'intérieur de ceux-ci):
Voir Package d'application Android pour plus d'informations sur la structure d'un APK et la source de la liste ci-dessus. Une liste plus complète (y compris MIPS64), ainsi que des informations sur des choses spécifiques à l'architecture, peuvent être trouvées sur une version archivée de la page de gestion ABI du développeur Android , capturée le 18 avril 2016.
Chose intéressante, le fait de cibler un seul ABI (où une application comprend des bibliothèques natives conçues pour une architecture) ne signifie pas nécessairement que l'application ne fonctionnera pas sur des appareils qui utilisent d'autres architectures. ARMv8-a, par exemple, est rétrocompatible avec ARM et ARMv7-a, et les appareils Android x86 d'Intel contiennent une couche de traduction propriétaire qui permet au code ARM de s'exécuter sur des appareils x86 (permettant aux applications ARM uniquement de s'exécuter sur des plates-formes x86). Une liste des ABI qu ' un dispositif applications peut exécuter peuvent être trouvées dans la ro.product.cpu.abilistpropriété, qui peut être atteint dans une coquille (par exemple par l' intermédiaire d' une application de terminal sur le dispositif, ou au-dessus de la BAD en utilisant adb shell) en utilisant la getpropcommande: getprop ro.product.cpu.abilist.
