3

I have an ARMv7a device and I am not able to install ARMv8a applications. But I am able to install ARMv7a + ARMv8a applications.

How am I able to install ARMv7a + ARMv8a and ARMv7a but not ARMv8a applications?

Improve this question
7
  • 4
    If somebody understands English and French she/he will be able to read a book written in English or French. If you only understand French it will be very hard for you to understand a book in English. ARMv7 and ARMv8a are also like languages and the CPU is like a person reading the book of a certain language. Most ARMv8 CPUs are multi language capable. ARMv7 only understand one "language". As the language is hard coded in the CPU you can't change it by software.
    – Robert
    May 6, 2021 at 18:37
  • 1
    Nice explanation by Robert, thanks! Another analogy: A newer version of your word processor has added additional "formatting elements" to the document format. It can still read the older formats fine – but the older version naturally cannot understand the new format (think *.doc vs *.docx). ARMv7 is the (older) predecessor of ARMv8, the latter added new instruction sets ARMv7 does not understand.
    – Izzy ♦
    May 6, 2021 at 20:07
  • Android apps for “armeabi-v7a” and “x86” architecture: SoC vs. Processor vs. ABI
    – Irfan Latif
    May 6, 2021 at 20:37
  • 1
    @Izzy Things are getting even more complicated as CPUs will be released that only support ARMv8 but not ARMv7 and then there is the new 64bit only CPU type ARMv9 (bit incompatible to ARMv8 as far as I know) which just been announced. Things will really getting complex next year's...
    – Robert
    May 6, 2021 at 20:37
  • Ouch, that's indeed bad news. So ends our "easy chain"…
    – Izzy ♦
    May 7, 2021 at 22:55

2 Answers 2

Reset to default
6

Basics

Applications that are entirely built from Java or Kotlin code, including all the libraries and SDKs they use, don't care about which of armv7a and armv8a a device supports. However, quite a few apps include "native code", aka "machine code", usually compiled from C or C++ code using the Android Native Development Kit ("NDK").

A given piece of machine code is either 32-bit (armv7a) or 64-bit (armv8a). It cannot be both.

Running native code

Applications that support both armv7a and armv8a have two sets of machine code included in their APK files:

  • One set for armv7a
  • One set for armv8a

Your armv7a device can happily run the code that's intended for it. It can understand that, and has the libraries and other software it needs to run it. It can't understand armv8a code at all, and is thus unable to run it. Applications that only support armv8a thus can't be run, so Android prevents you from installing them. If it let you install them, you'd waste data and storage finding out that they crashed when run.

Forthcoming complexities

The ARMv9 architecture Is gradually appearing in Android devices. The Qualcomm Snapdragon 8 Gen 1 was one of the first v9 chips announced, in November 2021. Most ARMv9 cores can't run armv7a code, because they don't implement that 32-bit instruction set (or any other). The 2023 generation of new core designs from ARM is the first with no cores at all that can run armv7a code. They can run armv8a code.

This means that devices with ARMv9 processors:

  • Can run apps that support armv7a and armv8a.
  • Can run apps that only support armv8a.
  • Can't run apps that only support armv7a.

It's a good thing that Google have been demanding that new and updated apps for the Play Store include armv8a code since August 2019 if they include any native code.

If and when the Android NDK acquires an option to build for armv9a, such code won't run on armv7a or armv8a devices. I presume that Google will require APKs with armv9a code to provide armv8a code as well, at least for a few years.

Why is there any armv7a machine code in use?

Android has quite a long history, and when it started, neither armv7a nor armv8a had been standardised. So there's been a gradual process of upgrading native code to newer standards.

In more detail, the original NDK in June 2009 only supported "armeabi" machine code, using the ARMv5TE instruction set. Armv7a was added in June 2010, x86 in June 2011 and MIPS in May 2012. Armv8a, along with 64-bit x86 and MIPS was added in July 2014. Armeabi, MIPS and MIPS64 were removed in June 2018.

Someone starting on Android NDK work today would support armv7a and armv8a, or maybe only armv8a if they were only interested in newer, faster devices, or their app needed to use lots of memory.

There have been a few Android devices that had 64-bit processors and a 64-bit Android kernel, but didn't have 64-bit Java/Kotlin run-times. The one I encountered was a 2017 model of the Amazon Kindle Fire HD 10, which is now discontinued. I bought it for the 64-bit Android 5, and the lack of 64-bit Java run-times was no problem for the native code I needed to test in the ADB shell.

The main benefit of 64-bit Java/Kotlin run-times is that they allow apps running on them to access more memory. This is only significant on devices with at least 4GB of RAM, so providing those run-times on devices with smaller memories has little value. As of 2023, 4GB seems to be becoming the standard for new low-end Android devices.

Improve this answer
1

Regarding the SoC:

  • ARMv7 SoC => 32-bit
  • ARMv8 SoC => 32-bit + 64-bit both

Regarding the app:

  • ARMv7a + ARMv8a packages => it has both ARMv7a and v8a binaries of that app bundled, so it installs the 32-bit version (ARMv7a) of the package if the device has an ARMv7 SoC or the 64-bit version if the device has an ARMv8 SoC.

  • ARMv7a packages => it only has 32-bit binaries, installable on both ARMv7 and v8 chips.

  • ARMv8a packages => it only has ARMv8a installable binaries, so if the device is 32-bit, the app package simply won't install.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .