Cortex-A53 cpuinfo'd as ARMv7?

Question

I picked up a used Samsung Galaxy Core Prime offered by MetroPCS in the US for testing. The device is powered by Android 5.1.1. Testing requirements are a 64-bit ARM processor, but I'm not sure if I have met the requirements.

According to cat /proc/cpuinfo (see below), I see Qualcomm Technologies, Inc MSM8916. That's a Cortex-A53, which is ARMv8a/64-bit architecture. But I also see ARMv7 listed, which is a 32-bit architecture.

Can anyone explain why I am seeing conflicting results?

---

$ adb shell cat /proc/cpuinfo
processor   : 0
model name  : ARMv7 Processor rev 0 (v7l)
BogoMIPS    : 38.40
Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xd03
CPU revision    : 0

processor   : 1
model name  : ARMv7 Processor rev 0 (v7l)
BogoMIPS    : 38.40
Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xd03
CPU revision    : 0

processor   : 2
model name  : ARMv7 Processor rev 0 (v7l)
BogoMIPS    : 38.40
Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xd03
CPU revision    : 0

processor   : 3
model name  : ARMv7 Processor rev 0 (v7l)
BogoMIPS    : 38.40
Features    : swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part    : 0xd03
CPU revision    : 0

Hardware    : Qualcomm Technologies, Inc MSM8916
Revision    : 0006
Serial      : 000009f200000001
Processor   : ARMv7 Processor rev 0 (v7l)

Answer 1

Some more testing reveals the following. I've done this procedure hundreds of times, so I know the results are an ominous sign.

I'm guessing it is a Cortex-A53/ARM-v8a processor, but its configured in 32-bit mode.

---

$ aarch64-linux-android-readelf -h ./cryptest.exe | grep -i 'class\|machine'
  Class:                             ELF64
  Machine:                           AArch64
$ aarch64-linux-android-readelf -h ./libcryptopp.so | grep -i 'class\|machine'
  Class:                             ELF64
  Machine:                           AArch64

[Push test program to /data/local/tmp, open a remote shell]

shell@cprimeltemtr:/ $ cd /data/local/tmp
shell@cprimeltemtr:/data/local/tmp $ LD_LIBRARY_PATH=./; ./cryptest.exe v
/system/bin/sh: ./cryptest.exe: not executable: 64-bit ELF file

Answer 2

What you have there is a 64-bit CPU running a 32-bit Android kernel. The kernel maintains /proc/cpuinfo and reports on what it is using rather than what exists. The boot code of the device will have put the processor into 32-bit mode before starting Android.

The 32-bit OS can recognise 64-bit executables, because there are identifying numbers in the file header. It knows it can't run 64-bit executables, and tells you so. There are several kinds of mixed 32/64-bit Android:

1. This one, with 64-bit hardware and a 32-bit Android. Devices like this were presumably produced to take advantage of new hardware before the vendor had finished updating their version of Android.
2. 64-bit hardware and operating system, but 32-bit Android RunTime ("ART"). This setup will run 32-bit and 64-bit native code, but Java/Kotlin code runs in a 32-bit environment. I've encountered one device like this, a 2017 model of the Amazon Kindle Fire HD.
3. 64-bit hardware and operating system, capable of running 32-bit and 64-bit native code, and with 64-bit ART. This has been common for several years as of 2023. However, it will gradually disappear over the next decade or so, because most new designs of ARM hardware are 64-bit only, and can't run 32-bit native code.