[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["没有我需要的信息","missingTheInformationINeed","thumb-down"],["太复杂/步骤太多","tooComplicatedTooManySteps","thumb-down"],["内容需要更新","outOfDate","thumb-down"],["翻译问题","translationIssue","thumb-down"],["示例/代码问题","samplesCodeIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-04-04。"],[],[],null,["# Build for 32-bit and 64-bit architectures\n\nThe build system supports building binaries for two target CPU architectures,\n32 bit and 64 bit, in the same build. This two-target build is known as a\n*multilib build*.\n\nFor built-in static libraries and shared libraries, the build system sets up\nrules to build binaries for both architectures. The product configuration\n(`PRODUCT_PACKAGES`), together with the dependency graph, determines which\nbinaries are built and installed to the system image.\n\nFor executables and apps, the build system builds only the 64-bit version by\ndefault, but you can override this setting with a global\n`BoardConfig.mk` variable or a module-scoped variable.\n| **Caution:** If an app exposes an API to other apps that can be either 32 bit or 64 bit, the app must have the `android:multiarch` property set to `true` within its manifest to avoid potential errors.\n\nIdentify a second CPU architecture and ABI\n------------------------------------------\n\n`BoardConfig.mk` includes the following variables to configure the second CPU\narchitecture and application binary interface (ABI):\n\n- `TARGET_2ND_ARCH`\n- `TARGET_2ND_ARCH_VARIANT`\n- `TARGET_2ND_CPU_VARIANT`\n- `TARGET_2ND_CPU_ABI`\n- `TARGET_2ND_CPU_ABI2`\n\nFor an example makefile that uses these variables, see\n[`build/make/target/board/generic_arm64/BoardConfig.mk`](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/make/target/board/generic_arm64/BoardConfig.mk).\n\nIn a multilib build, module names in `PRODUCT_PACKAGES` cover\nboth the 32-bit and 64-bit binaries, as long as they're defined by the build\nsystem. For libraries included by dependency, a 32-bit or 64-bit library is\ninstalled only if it's required by another 32-bit or 64-bit library or\nexecutable.\n\nHowever, module names on the `make` command line cover only the\n64-bit version. For example, after running `lunch aosp_arm64-eng`,\n`make libc` builds only the 64-bit libc. To\nbuild the 32-bit libc, you need to run `make libc_32`.\n\nDefine module architecture in Android.mk\n----------------------------------------\n\nYou can use the `LOCAL_MULTILIB` variable to configure your build\nfor 32 bit and 64 bit and override the global `TARGET_PREFER_32_BIT` variable.\n\nTo override `TARGET_PREFER_32_BIT`, set `LOCAL_MULTILIB` to one of the\nfollowing:\n\n- `both` builds both 32 bit and 64 bit.\n- `32` builds only 32 bit.\n- `64` builds only 64 bit.\n- `first` builds for only the first architecture (32 bit in 32-bit devices and 64 bit in 64-bit devices).\n\nBy default, `LOCAL_MULTILIB` isn't set and the build system decides which\narchitecture to build based on the module class and other\n`LOCAL_`\u003cvar translate=\"no\"\u003e*\u003c/var\u003e variables, such as `LOCAL_MODULE_TARGET_ARCH`\nand `LOCAL_32_BIT_ONLY`.\n| **Note:** In a multilib build, conditionals like `ifeq $(TARGET_ARCH)` don't work.\n\nIf you want to build your module for specific architectures, use the following\nvariables:\n\n- `LOCAL_MODULE_TARGET_ARCH` - Set this variable to a list of architectures,\n such as `arm x86 arm64`. If the architecture being built is in that list, the\n current module is included by the build system.\n\n- `LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH` - This variable is the opposite of\n `LOCAL_MODULE_TARGET_ARCH`. If the architecture being built is `not`\n in that list, the current module is included by the build system.\n\nThere are minor variants of these two variables:\n\n- `LOCAL_MODULE_TARGET_ARCH_WARN`\n- `LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH_WARN`\n\nThe build system warns if the current module is skipped because of the\narchitectures listed.\n\nTo set up build flags for a particular architecture, use the\narchitecture-specific `LOCAL_`\u003cvar translate=\"no\"\u003e*\u003c/var\u003e variables where\n\u003cvar translate=\"no\"\u003e*\u003c/var\u003e is an architecture-specific suffix, for example:\n\n- `LOCAL_SRC_FILES_arm, LOCAL_SRC_FILES_x86,`\n- `LOCAL_CFLAGS_arm, LOCAL_CFLAGS_arm64,`\n- `LOCAL_LDFLAGS_arm, LOCAL_LDFLAGS_arm64,`\n\nThese variables are applied only if a binary is being built for that\narchitecture.\n\nSometimes it's easier to set up flags based on whether the binary is\nbeing built for 32-bit or 64-bit. Use the `LOCAL_`\u003cvar translate=\"no\"\u003e*\u003c/var\u003e\nvariable with a `_32` or `_64` suffix, for example:\n\n- `LOCAL_SRC_FILES_32, LOCAL_SRC_FILES_64,`\n- `LOCAL_CFLAGS_32, LOCAL_CFLAGS_64,`\n- `LOCAL_LDFLAGS_32, LOCAL_LDFLAGS_64,`\n\n| **Note:** Not all the `LOCAL_`\u003cvar translate=\"no\"\u003e*\u003c/var\u003e variables support the architecture-specific variants. For an up-to-date list of `LOCAL_`\u003cvar translate=\"no\"\u003e*\u003c/var\u003e variables, refer to [`build/make/core/clear_vars.mk`](https://cs.android.com/android/platform/superproject/+/android-latest-release:build/make/core/clear_vars.mk).\n\nSet library installation path\n-----------------------------\n\nFor a non-multilib build, you can use `LOCAL_MODULE_PATH` to install a library\nto a location other than the default location. For example,\n`LOCAL_MODULE_PATH := $(TARGET_OUT_SHARED_LIBRARIES)/hw`.\n\nHowever, in a multilib build, use `LOCAL_MODULE_RELATIVE_PATH` instead: \n\n LOCAL_MODULE_RELATIVE_PATH := hw\n\nWith this format, both the 64-bit and 32-bit libraries are installed in the\ncorrect location.\n\nIf you build an executable as both 32 bit and 64 bit, use one of\nthe following variables to distinguish the install path:\n\n- `LOCAL_MODULE_STEM_32, LOCAL_MODULE_STEM_64` - Specifies the installed filename.\n- `LOCAL_MODULE_PATH_32, LOCAL_MODULE_PATH_64` - Specifies the install path.\n\nObtain intermediate directory for source files\n----------------------------------------------\n\nIn a multilib build, if you generate source files to\n`$(local-intermediates-dir)` (or `$(intermediates-dir-for)`\nwith explicit variables), it doesn't work reliably. That's\nbecause the intermediate generated sources are required by both the 32-bit and\n64-bit builds, but `$(local-intermediates-dir)` points to only one of\nthe two intermediate directories.\n\nThe build system provides a dedicated, multilib-friendly,\nintermediate directory for generating sources. To retrieve the intermediate\ndirectory's path, use the\n`$(local-generated-sources-dir)` or\n`$(generated-sources-dir-for)` macro. The uses of these macros are similar to\n`$(local-intermediates-dir)` and `$(intermediates-dir-for)`.\n\nIf a source file is generated to this dedicated directory and picked up\nby `LOCAL_GENERATED_SOURCES`, it's built for both 32 bit and 64 bit\nin a multilib build.\n\nIndicate system architecture of prebuilt binary targets\n-------------------------------------------------------\n\nIn a multilib build, you can't use `TARGET_ARCH`, or `TARGET_ARCH` combined with\n`TARGET_2ND_ARCH`, to indicate the system architecture of the prebuilt\nbinary targets. Instead, use the `LOCAL_`\u003cvar translate=\"no\"\u003e*\u003c/var\u003e variables\n`LOCAL_MODULE_TARGET_ARCH` or\n`LOCAL_MODULE_UNSUPPORTED_TARGET_ARCH`.\n\nWith these variables, the build system can choose the corresponding 32-bit\nprebuilt binary even if it's working on a 64-bit multilib build.\n\nIf you want to use the chosen architecture to compute the source path for the\nprebuilt binary, call `$(get-prebuilt-src-arch)`.\n\nEnsure 32-bit and 64-bit ODEX file generation\n---------------------------------------------\n\nFor 64-bit devices, by default Google generates both 32-bit and 64-bit ODEX\nfiles for the boot image and any Java libraries. For APKs, by default Google\ngenerates ODEX only for the primary 64-bit architecture. If an app is launched\nin both 32-bit and 64-bit processes, use `LOCAL_MULTILIB := both` to make sure\nthat both 32-bit and 64-bit ODEX files are generated. If the app has any 32-bit\nor 64-bit JNI libraries, that flag also tells the build system to include them."]]