技术问询：除build.prop外，ro.product.cpu.abilist还可在何处设置？属性值为何不一致？

Looking at your command outputs, it’s clear that the ro.product.cpu.abilist value returned by getprop doesn’t match what’s in /system/build.prop. That’s totally normal on Android—system properties can be set from several places beyond just the main build.prop file. Let’s break down the most likely sources:

• Vendor/ODM partition build.prop files
  Modern Android devices use a partitioned system layout, so properties often get defined in secondary build.prop files like /vendor/build.prop or /odm/build.prop (depending on your device’s setup). These files are typically loaded after /system/build.prop, so their settings will override the system partition’s values. To check them, run:

  adb shell cat /vendor/build.prop | grep -i abi
  adb shell cat /odm/build.prop | grep -i abi
  

• Init scripts (init.rc and vendor-specific scripts)
  During boot, the init process runs a set of scripts that can directly set properties using the setprop command. It’s common for vendors to add lines like setprop ro.product.cpu.abilist "x86,armeabi-v7a,armeabi" in these scripts to extend ABI support (like adding ARM compatibility for x86 devices). Check these locations:

  • /init.rc
  • /vendor/etc/init/ (vendor-specific init scripts)
  • /odm/etc/init/ (if your device has an ODM partition)
    You can search these files with:

  adb shell grep -r "ro.product.cpu.abilist" /init.rc /vendor/etc/init /odm/etc/init
  

• Default.prop (compiled-in system defaults)
  The default.prop file contains compiled-in default properties that load early in the boot process—before any build.prop files. While you can’t modify this without recompiling the system, it’s a source of initial values that might be overridden later. To check it:

  adb shell cat /default.prop | grep -i abi
  

• Build-time configuration (BoardConfig.mk for custom ROMs)
  If you’re working with a custom ROM, ro.product.cpu.abilist is often derived from build-time settings in BoardConfig.mk (like TARGET_CPU_ABI, TARGET_CPU_ABI2, and TARGET_CPU_ABILIST). These values are baked into the system image during compilation and can end up overriding static build.prop entries.

In your specific case, the extra ARM ABIs (armeabi-v7a, armeabi) in the getprop output suggest your device is either an x86 emulator or an Intel-powered Android device that supports ARM binary translation. Those additional ABIs are almost certainly being set in one of the vendor/ODM prop files or init scripts mentioned above.

内容的提问来源于stack exchange，提问作者Wangwang