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.