Les raisons pour lesquelles une application est incompatible sont les suivantes AndroidManifest.xml d'autres n'existent que dans la configuration du [Play] Store (comme les limitations à un pays, à un opérateur ou si le développeur de l'application a mis certains appareils sur liste blanche pour une raison ou une autre).
AndroidManifest.xml
Version minimale/maximale d'Android
Retour à AndroidManifest.xml . Si vous le décodez à l'aide d'un outil comme apktool o Jadx-GUI vous devez d'abord vérifier l'entrée minSdkVersion :
<uses-sdk android:minSdkVersion="30" android:targetSdkVersion="33"/>
Dans cet exemple, l'application est limitée à Android 11 et aux versions plus récentes. Théoriquement, il peut aussi y avoir un maxSdkversion mais les applications qui ont une telle entrée sont très rares.
Caractéristiques du matériel
Les restrictions suivantes peuvent provenir de uses-feature qui sont marquées comme android:required="true" :
<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>
Il peut y avoir plusieurs entrées pour différentes fonctions matérielles comme le Bluetooth, l'appareil photo, etc. Si vous rencontrez une entrée qui a android:required="false" il s'agit d'une exigence matérielle facultative, il n'est donc pas important que votre appareil la prenne en charge ou non. Vous pouvez obtenir la liste des fonctionnalités prises en charge par votre téléphone à l'aide de la commande adb shell pm list features .
Bibliothèques partagées requises
Les prochaines entrées pertinentes sont les suivantes uses-libraries :
<uses-library android:name="org.apache.http.legacy" android:required="true"/>
Comme pour les fonctionnalités matérielles, ces entrées définissent les bibliothèques logicielles que votre téléphone doit prendre en charge. Vous pouvez obtenir la liste des bibliothèques partagées prises en charge à l'aide de la commande adb shell pm list libraries .
Même s'il s'agit d'une exigence logicielle, il n'est pas possible d'installer une bibliothèque manquante sur des appareils non rootés. Sur les appareils rootés, il est théoriquement possible d'ajouter une bibliothèque manquante, mais ces bibliothèques requièrent souvent certaines caractéristiques matérielles ou d'autres bibliothèques (spécifiques au fabricant), de sorte qu'il n'est généralement pas possible de les ajouter.
Architecture de l'unité centrale
Une autre restriction très importante concerne les architectures de CPU prises en charge par un APK. À l'heure actuelle, il existe quatre architectures de processeur pertinentes :
armeabi-v7a alias armeabi (ARM 32 bits)arm64-v8a (ARM 64 bits)x86x86_64
x86 et x86_64 ne concernent que les émulateurs, car les appareils physiques dotés de l'une de ces architectures n'ont pas été commercialisés au cours des dix dernières années. Vous pouvez vérifier quelle architecture est prise en charge par un APK en vérifiant le paramètre libs dossier. Si ce dossier n'existe pas ou n'a pas de sous-dossier, il n'y a pas de restriction d'architecture. Pour les APK fractionnés plus récents, vous avez un fichier APK séparé avec l'architecture dans son nom de fichier. Dans ce cas, les fichiers APK de base (où les classes*.dex sont stockées) n'ont pas de dossier libs.
Vous pouvez vérifier les architectures de processeurs prises en charge par votre téléphone en utilisant la commande adb shell getprop ro.product.cpu.abilist .
