Some reasons why an app is incompatible can be seen from AndroidManifest.xml, others only exists in the [Play] Store configuration (such as limitations to a country, a carrier or if the app developer has just white-listed certain devices for whatever reason).

AndroidManifest.xml

Back to AndroidManifest.xml. If you decode it using a tool like apktool or Jadx-GUI you should first check the entry minSdkVersion:

<uses-sdk android:minSdkVersion="30" android:targetSdkVersion="33"/>

In this example the app is restricted to Android 11 and newer. Theoretically there can also be a maxSdkversion entry but apps that have such an entry are very very rare.

The next restrictions can come from uses-feature entries that are marked as android:required="true":

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

There can be multiple entries for different hardware features like Bluetooth, camera and so on. If you encounter an entry that has android:required="false" the this is an optional hardware requirement, thus it should not matter if your device supports it or not. You can get the list of supported features of your phone using the command adb shell pm list features.

The next entries are the uses-libraries:

<uses-library android:name="org.apache.http.legacy" android:required="true"/>

Again like for the hardware features these entries define software libraries your phone has to support. You can get the list of supported shared libraries using the command adb shell pm list libraries.

Even if this is a software requirement it is not possible on un-rooted devices to install a missing library. On rooted devices it is theoretically possible to add a missing library but often those libraries require certain hardware features or other (manufacturer specific) libraries, so adding them is usually not possible.

CPU architecture

Another very important restriction is which CPU architectures are supported by an APK. At the moment there are four relevant CPU architectures:

• armeabi-v7a alias armeabi (ARM 32 bit)
• arm64-v8a (ARM 64 bit)
• x86
• x86_64

x86 and x86_64 are only relevant for emulators, physical devices with one of these architectures were not released in the last 10 years. You can check which architecture is supported by an APK by checking the libs folder. If this folder does not exist or has no subfolder, then there is no architecture restriction. For newer split APK you have a separate APK file with the architecture in it's file-name. In such a case the base APK files (where the classes*.dex are stored in has no libs folder).

You can check the supported CPU architectures of your phone using the command adb shell getprop ro.product.cpu.abilist.

Some reasons why an app is incompatible can be seen from AndroidManifest.xml, others only exists in the [Play] Store configuration (such as limitations to a country, a carrier or if the app developer has just white-listed certain devices for whatever reason).

AndroidManifest.xml

Minimum/maximum Android version

Back to AndroidManifest.xml. If you decode it using a tool like apktool or Jadx-GUI you should first check the entry minSdkVersion:

<uses-sdk android:minSdkVersion="30" android:targetSdkVersion="33"/>

In this example the app is restricted to Android 11 and newer. Theoretically there can also be a maxSdkversion entry but apps that have such an entry are very very rare.

Hardware features

The next restrictions can come from uses-feature entries that are marked as android:required="true":

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

There can be multiple entries for different hardware features like Bluetooth, camera and so on. If you encounter an entry that has android:required="false" the this is an optional hardware requirement, thus it should not matter if your device supports it or not. You can get the list of supported features of your phone using the command adb shell pm list features.

Required shared libraries

The next relevant entries are the uses-libraries:

<uses-library android:name="org.apache.http.legacy" android:required="true"/>

Again like for the hardware features these entries define software libraries your phone has to support. You can get the list of supported shared libraries using the command adb shell pm list libraries.

Even if this is a software requirement it is not possible on un-rooted devices to install a missing library. On rooted devices it is theoretically possible to add a missing library but often those libraries require certain hardware features or other (manufacturer specific) libraries, so adding them is usually not possible.

CPU architecture

Another very important restriction is which CPU architectures are supported by an APK. At the moment there are four relevant CPU architectures:

• armeabi-v7a alias armeabi (ARM 32 bit)
• arm64-v8a (ARM 64 bit)
• x86
• x86_64

x86 and x86_64 are only relevant for emulators, physical devices with one of these architectures were not released in the last 10 years. You can check which architecture is supported by an APK by checking the libs folder. If this folder does not exist or has no subfolder, then there is no architecture restriction. For newer split APK you have a separate APK file with the architecture in it's file-name. In such a case the base APK files (where the classes*.dex are stored in has no libs folder).

You can check the supported CPU architectures of your phone using the command adb shell getprop ro.product.cpu.abilist.

Some reasons why an app is incompatible can be seen from AndroidManifest.xml, others only exists in the [Play] Store configuration (such as limitations to a country, a carrier or if the app developer has just white-listed certain devices for whatever reason).

Back to AndroidManifest.xml. If you decode it using a tool like apktool or Jadx-GUI you should first check the entry minSdkVersion:

<uses-sdk android:minSdkVersion="30" android:targetSdkVersion="33"/>

In this example the app is restricted to Android 11 and newer. Theoretically there can also be a maxSdkversion entry but apps that have such an entry are very very rare.

The next restrictions can come from uses-feature entries that are marked as android:required="true":

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

There can be multiple entries for different hardware features like Bluetooth, camera and so on. If you encounter an entry that has android:required="false" the this is an optional hardware requirement, thus it should not matter if your device supports it or not. You can get the list of supported features of your phone using the command adb shell pm list features.

The next entries are the uses-libraries:

<uses-library android:name="org.apache.http.legacy" android:required="true"/>

Again like for the hardware features these entries define software libraries your phone has to support. You can get the list of supported shared libraries using the command adb shell pm list libraries.

Even if this is a software requirement it is not possible on un-rooted devices to install a missing library. On rooted devices it is theoretically possible to add a missing library but often those libraries require certain hardware features or other (manufacturer specific) libraries, so adding them is usually not possible.

Some reasons why an app is incompatible can be seen from AndroidManifest.xml, others only exists in the [Play] Store configuration (such as limitations to a country, a carrier or if the app developer has just white-listed certain devices for whatever reason).

AndroidManifest.xml

Back to AndroidManifest.xml. If you decode it using a tool like apktool or Jadx-GUI you should first check the entry minSdkVersion:

<uses-sdk android:minSdkVersion="30" android:targetSdkVersion="33"/>

In this example the app is restricted to Android 11 and newer. Theoretically there can also be a maxSdkversion entry but apps that have such an entry are very very rare.

The next restrictions can come from uses-feature entries that are marked as android:required="true":

<uses-feature android:name="android.hardware.bluetooth_le" android:required="true"/>

There can be multiple entries for different hardware features like Bluetooth, camera and so on. If you encounter an entry that has android:required="false" the this is an optional hardware requirement, thus it should not matter if your device supports it or not. You can get the list of supported features of your phone using the command adb shell pm list features.

The next entries are the uses-libraries:

<uses-library android:name="org.apache.http.legacy" android:required="true"/>

Again like for the hardware features these entries define software libraries your phone has to support. You can get the list of supported shared libraries using the command adb shell pm list libraries.

Even if this is a software requirement it is not possible on un-rooted devices to install a missing library. On rooted devices it is theoretically possible to add a missing library but often those libraries require certain hardware features or other (manufacturer specific) libraries, so adding them is usually not possible.

CPU architecture

Another very important restriction is which CPU architectures are supported by an APK. At the moment there are four relevant CPU architectures:

• armeabi-v7a alias armeabi (ARM 32 bit)
• arm64-v8a (ARM 64 bit)
• x86
• x86_64

x86 and x86_64 are only relevant for emulators, physical devices with one of these architectures were not released in the last 10 years. You can check which architecture is supported by an APK by checking the libs folder. If this folder does not exist or has no subfolder, then there is no architecture restriction. For newer split APK you have a separate APK file with the architecture in it's file-name. In such a case the base APK files (where the classes*.dex are stored in has no libs folder).

You can check the supported CPU architectures of your phone using the command adb shell getprop ro.product.cpu.abilist.