Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release thay vì aosp-main để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.

Trang này được dịch bởi Cloud Translation API.

Buộc thực thi giao diện phân vùng sản phẩm

Android 11 tách riêng phân vùng product, giúp phân vùng này độc lập với các phân vùng system và vendor. Trong khuôn khổ của những thay đổi này, bạn hiện có thể kiểm soát quyền truy cập của phân vùng product vào ứng dụng gốc và Java các giao diện (tương tự như cách hoạt động của quá trình thực thi giao diện đối với vendor phân vùng).

Thực thi giao diện gốc

Để bật tính năng thực thi giao diện gốc, hãy đặt PRODUCT_PRODUCT_VNDK_VERSION đến current. (Phiên bản này được tự động đặt thành current khi cấp độ API vận chuyển cho mục tiêu lớn hơn 29.) Biện pháp thực thi cho phép:

Các mô-đun gốc trong phân vùng product cần liên kết:
- Tĩnh hoặc động đến các mô-đun khác trong phân vùng product bao gồm thư viện tĩnh, thư viện dùng chung hoặc thư viện tiêu đề.
- Tự động đến các thư viện VNDK trong phân vùng system.
Các thư viện JNI trong các tệp APK chưa được nhóm trong phân vùng product để liên kết đến trong /product/lib hoặc /product/lib64 (đây là tính năng bổ sung cho thư viện NDK).

Biện pháp thực thi không cho phép đường liên kết khác đến các phân vùng ngoài product phân vùng.

Thực thi thời gian xây dựng (Android.bp)

Trong Android 11, các mô-đun hệ thống có thể tạo một biến thể hình ảnh sản phẩm ngoài các biến thể hình ảnh cốt lõi và hình ảnh của nhà cung cấp. Khi tính năng thực thi giao diện gốc được bật (PRODUCT_PRODUCT_VNDK_VERSION được đặt thành current):

Các mô-đun gốc trong phân vùng product lại có trong biến thể sản phẩm của biến thể chính.
Các mô-đun có product_available: true trong tệp Android.bp đang có sẵn cho biến thể sản phẩm.
Các thư viện hoặc tệp nhị phân chỉ định product_specific: true có thể liên kết với các thư viện khác chỉ định product_specific: true hoặc product_available: true trong tệp Android.bp.
Thư viện VNDK phải có product_available: true trong tệp Android.bp để tệp nhị phân product có thể liên kết với thư viện VNDK.

Bảng sau đây tóm tắt các thuộc tính Android.bp dùng để tạo biến thể hình ảnh.

Các thuộc tính trong Android.bp	Đã tạo biến thể
Các thuộc tính trong Android.bp	Trước khi thực thi	Sau khi thực thi
mặc định (không có)	cốt lõi (bao gồm `/system`, `/system_ext` và `/product`)	lõi (bao gồm `/system` và `/system_ext` nhưng không bao gồm `/product`)
`system_ext_specific: true`	core	core
`product_specific: true`	core	sản phẩm
`vendor: true`	nhà cung cấp	nhà cung cấp
`vendor_available: true`	core, vendor	core, vendor
`product_available: true`	Không áp dụng	core, product
`vendor_available: true` VÀ `product_available: true`	Không áp dụng	cốt lõi, sản phẩm, nhà cung cấp
`system_ext_specific: true` VÀ `vendor_available: true`	cốt lõi, nhà cung cấp	cốt lõi, nhà cung cấp
`product_specific: true` VÀ `vendor_available: true`	cốt lõi, nhà cung cấp	sản phẩm, nhà cung cấp

Thực thi thời gian xây dựng (Android.mk)

Khi bạn bật tính năng thực thi giao diện gốc, các mô-đun gốc được cài đặt vào phân vùng product sẽ có loại đường liên kết native:product chỉ có thể liên kết với các mô-đun native:product hoặc native:vndk khác. Đang cố liên kết với một các mô-đun khác với những mô-đun này khiến hệ thống xây dựng tạo bước kiểm tra loại liên kết .

Thực thi trong thời gian chạy

Khi bạn bật tính năng thực thi giao diện gốc, cấu hình trình liên kết cho trình liên kết bionic sẽ không cho phép các quy trình hệ thống sử dụng thư viện product, tạo một phần product cho các quy trình product không thể liên kết với thư viện bên ngoài phân vùng product (tuy nhiên, các quy trình như vậy có thể liên kết với thư viện VNDK). Cố gắng vi phạm cấu hình liên kết thời gian chạy sẽ khiến không thành công và tạo thông báo lỗi CANNOT LINK EXECUTABLE.

Thực thi giao diện Java

Để bật tính năng thực thi giao diện Java, hãy đặt PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE thành true. (Giá trị là tự động đặt thành true khi cấp độ API vận chuyển cho mục tiêu là lớn hơn 29.) Khi được bật, chế độ thực thi sẽ cho phép hoặc không cho phép các quyền truy cập sau:

API	/system	/system_ext	/product	/vendor	/data
API công khai
@API Hệ thống
@hide API

Như trong phân vùng vendor, một ứng dụng hoặc một thư viện Java trong product phân vùng chỉ được phép sử dụng API công khai và API hệ thống; liên kết đến một thư viện sử dụng API ẩn đều không được phép. Quy định hạn chế này bao gồm việc liên kết tại thời điểm tạo bản dựng và phản chiếu trong thời gian chạy.

Thực thi thời gian tạo bản dựng

Tại thời điểm tạo bản dựng, Make và Soong xác minh rằng các mô-đun Java trong phân vùng product không sử dụng các API ẩn bằng cách kiểm tra các trường platform_apis và sdk_version. Bạn phải điền current, system_current hoặc phiên bản số của API vào sdk_version của ứng dụng trong phân vùng product và trường platform_apis phải trống.

Thực thi trong thời gian chạy

Môi trường thời gian chạy Android xác minh rằng các ứng dụng trong phân vùng product không sử dụng API ẩn, bao gồm cả phản chiếu. Để biết chi tiết, hãy tham khảo Quy định hạn chế về không phải SDK .

Bật tính năng thực thi giao diện sản phẩm

Hãy làm theo các bước trong phần này để bật tính năng thực thi giao diện sản phẩm.

Bước	Việc cần làm	Bắt buộc
1	Xác định tệp makefile hệ thống của riêng bạn, chỉ định các gói cho phân vùng `system`, sau đó đặt chế độ kiểm tra yêu cầu về đường dẫn cấu phần phần mềm trong `device.mk` (để ngăn các mô-đun không phải hệ thống cài đặt vào phân vùng `system`).	Không
2	Dọn dẹp danh sách được phép.	Không
3	Thực thi giao diện gốc và xác định lỗi liên kết trong thời gian chạy (có thể chạy trong song song với thực thi Java).	Có
4	Thực thi giao diện Java và xác minh hành vi trong thời gian chạy (có thể chạy song song với việc thực thi gốc).	Có
5	Kiểm tra hành vi trong thời gian chạy.	Có
6	Cập nhật `device.mk` bằng cách thực thi giao diện sản phẩm.	Có

Bước 1: Tạo tệp makefile và bật tính năng kiểm tra đường dẫn cấu phần phần mềm

Trong bước này, bạn xác định tệp makefile system.

Tạo một tệp makefile xác định các gói cho phân vùng system. Ví dụ: tạo tệp oem_system.mk bằng nội dung sau:

$(call inherit-product, $(SRC_TARGET_DIR)/product/handheld_system.mk)
$(call inherit-product, $(SRC_TARGET_DIR)/product/telephony_system.mk)

# Applications
PRODUCT_PACKAGES += \
    CommonSystemApp1 \
    CommonSystemApp2 \
    CommonSystemApp3 \

# Binaries
PRODUCT_PACKAGES += \
    CommonSystemBin1 \
    CommonSystemBin2 \
    CommonSystemBin3 \

# Libraries
PRODUCT_PACKAGES += \
    CommonSystemLib1 \
    CommonSystemLib2 \
    CommonSystemLib3 \

PRODUCT_SYSTEM_NAME := oem_system
PRODUCT_SYSTEM_BRAND := Android
PRODUCT_SYSTEM_MANUFACTURER := Android
PRODUCT_SYSTEM_MODEL := oem_system
PRODUCT_SYSTEM_DEVICE := generic

# For system-as-root devices, system.img should be mounted at /, so we
# include ROOT here.
_my_paths := \
 $(TARGET_COPY_OUT_ROOT)/ \
 $(TARGET_COPY_OUT_SYSTEM)/ \

$(call require-artifacts-in-path, $(_my_paths),)

Trong tệp device.mk, kế thừa tệp makefile chung cho phân vùng system và bật tính năng kiểm tra yêu cầu về đường dẫn cấu phần phần mềm. Ví dụ:
```
$(call inherit-product, $(SRC_TARGET_DIR)/product/oem_system.mk)

# Enable artifact path requirements checking
PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := strict
```

Giới thiệu về các yêu cầu đối với đường dẫn cấu phần phần mềm

Khi bạn đặt PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS thành true hoặc strict, hệ thống xây dựng ngăn các gói được xác định trong các tệp makefile khác cài đặt cho đường dẫn được xác định trong require-artifacts-in-path và ngăn chặn các gói được xác định trong tệp makefile hiện tại từ việc cài đặt cấu phần phần mềm bên ngoài đường dẫn được xác định trong require-artifacts-in-path.

Trong ví dụ trên, với PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS được đặt thành strict, các tệp makefile bên ngoài oem_system.mk không thể bao gồm các mô-đun được cài đặt vào phân vùng root hoặc system. Để đưa các mô-đun này vào, bạn phải xác định các mô-đun đó trong chính tệp oem_system.mk hoặc trong một tệp makefile đi kèm. Việc cố gắng cài đặt mô-đun vào các đường dẫn không được phép sẽ gây ra lỗi bản dựng. Để khắc phục nghỉ ngơi, hãy làm theo một trong những cách sau:

Cách 1: Thêm mô-đun hệ thống vào tệp makefile có trong oem_system.mk. Điều này giúp đáp ứng yêu cầu về đường dẫn cấu phần phần mềm (vì các mô-đun hiện tồn tại trong một tệp makefile đi kèm) và do đó cho phép cài đặt vào tập hợp đường dẫn trong "require-artifacts-in-path".
Cách 2: Cài đặt các mô-đun vào phân vùng system_ext hoặc product (và không cài đặt các mô-đun vào phân vùng system).
Cách 3: Thêm mô-đun vào PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST. Danh sách này liệt kê các mô-đun được phép cài đặt.

Bước 2: Xoá danh sách được phép

Trong bước này, bạn sẽ làm trống PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST để tất cả thiết bị chia sẻ oem_system.mk cũng có thể chia sẻ một hình ảnh system. Để làm trống danh sách được phép, hãy di chuyển mọi mô-đun trong danh sách sang phân vùng system_ext hoặc product hoặc thêm các mô-đun đó vào tệp tạo system. Chiến dịch này là không bắt buộc vì bạn không bắt buộc phải xác định hình ảnh system thông thường để bật tính năng thực thi giao diện sản phẩm. Tuy nhiên, việc làm trống danh sách được phép hữu ích khi xác định ranh giới system bằng system_ext.

Bước 3: Thực thi giao diện gốc

Ở bước này, bạn đặt PRODUCT_PRODUCT_VNDK_VERSION := current, sau đó tìm để phát hiện các lỗi bản dựng và thời gian chạy, đồng thời giải quyết chúng. Cách kiểm tra quá trình khởi động và nhật ký thiết bị, đồng thời tìm và khắc phục lỗi liên kết thời gian chạy:

Đặt PRODUCT_PRODUCT_VNDK_VERSION := current.
Tạo bản dựng thiết bị và tìm lỗi bản dựng. Bạn có thể thấy một vài toà nhà điểm chèn quảng cáo cho các biến thể sản phẩm còn thiếu hoặc các biến thể chính. Sau đây là một số điểm chèn quảng cáo phổ biến:
- Mọi mô-đun hidl_interface có product_specific: true sẽ không được cung cấp cho các mô-đun hệ thống. Để khắc phục, hãy thay thế product_specific: true bằng system_ext_specific: true.
- Các mô-đun có thể thiếu biến thể sản phẩm cần thiết cho sản phẩm các mô-đun. Để khắc phục, hãy cung cấp mô-đun đó cho phân vùng product bằng cách đặt product_available: true hoặc di chuyển mô-đun sang product phân vùng bằng cách đặt product_specific: true.
Lưu ý: Dấu ngắt bản dựng cũng tương tự như đối với các mô-đun được mô tả trong Android.mk.
Khắc phục lỗi bản dựng và đảm bảo bản dựng thiết bị thành công.
Truyền hình ảnh và tìm lỗi thời gian chạy trong quá trình khởi động và nhật ký thiết bị.
- Nếu thẻ linker trong nhật ký trường hợp kiểm thử cho thấy CANNOT LINK EXECUTABLE thông báo, tệp make thiếu phần phụ thuộc (và không được ghi lại tại thời gian xây dựng).
- Để kiểm tra thư viện này từ hệ thống xây dựng, hãy thêm thư viện bắt buộc vào trường shared_libs: hoặc required:.
Giải quyết các phần phụ thuộc bị thiếu theo hướng dẫn ở trên.

Bước 4: Thực thi giao diện Java

Ở bước này, bạn đặt PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true, sau đó tìm và khắc phục lỗi bản dựng kết quả. Hãy tìm hai loại lỗi cụ thể:

Lỗi về loại đường liên kết. Lỗi này cho biết rằng một ứng dụng liên kết đến các mô-đun Java có sdk_version rộng hơn. Để khắc phục, bạn có thể mở rộng phạm vi của ứng dụng sdk_version hoặc hạn chế sdk_version của thư viện. Lỗi ví dụ:

error: frameworks/base/packages/SystemUI/Android.bp:138:1: module "SystemUI" variant "android_common": compiles against system API, but dependency "telephony-common" is compiling against private API.Adjust sdk_version: property of the source or target module so that target module is built with the same or smaller API set than the source.

Lỗi ký hiệu. Lỗi này cho biết không tìm thấy một biểu tượng vì biểu tượng đó nằm trong một API ẩn. Để khắc phục, hãy sử dụng API hiển thị (không bị ẩn) hoặc tìm một thay thế. Lỗi ví dụ:

frameworks/opt/net/voip/src/java/com/android/server/sip/SipSessionGroup.java:1051: error: cannot find symbol
            ProxyAuthenticate proxyAuth = (ProxyAuthenticate)response.getHeader(
                                           ^
  symbol:   class ProxyAuthenticate
  location: class SipSessionGroup.SipSessionImpl

Bước 5: Kiểm tra hành vi trong thời gian chạy

Trong bước này, bạn xác minh hành vi trong thời gian chạy đúng như dự kiến. Đối với các ứng dụng có thể gỡ lỗi, bạn có thể theo dõi mức sử dụng API bị ẩn bằng cách ghi nhật ký bằng StrictMode.detectNonSdkApiUsage (sẽ tạo nhật ký khi ứng dụng sử dụng API ẩn). Ngoài ra, bạn có thể sử dụng công cụ phân tích tĩnh veridex để biết loại hình sử dụng (liên kết hoặc phản chiếu), cấp độ hạn chế và ngăn xếp lệnh gọi.

Cú pháp Veridex:

./art/tools/veridex/appcompat.sh --dex-file={apk file}

Ví dụ về kết quả Veridex:

#1: Linking greylist-max-o Landroid/animation/AnimationHandler;-><init>()V use(s):
       Lcom/android/systemui/pip/phone/PipMotionHelper;-><init>(Landroid/content/Context;Landroid/app/IActivityManager;Landroid/app/IActivityTaskManager;Lcom/android/systemui/pip/phone/PipMenuActivityController;Lcom/android/internal/policy/PipSnapAlgorithm;Lcom/android/systemui/statusbar/FlingAnimationUtils;)V

#1332: Reflection greylist Landroid/app/Activity;->mMainThread use(s):
       Landroidx/core/app/ActivityRecreator;->getMainThreadField()Ljava/lang/reflect/Field;

Để biết thông tin chi tiết về cách sử dụng veridex, hãy tham khảo bài viết Kiểm thử bằng công cụ veridex.

Bước 6: Cập nhật device.mk

Sau khi khắc phục tất cả lỗi của bản dựng và thời gian chạy, đồng thời xác minh thời gian chạy đó như dự kiến, hãy thiết lập các nội dung sau trong device.mk:

PRODUCT_PRODUCT_VNDK_VERSION := current
PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true