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

Android 11 tách các gói phân vùng product, khiến phân vùng này độc lập với 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 phí vận chuyển Cấp độ API của 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 với 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 chuyển sang các thư viện VNDK trong phân vùng system.
  • Các thư viện JNI trong các 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 sản phẩm bên cạnh các biến thể hình ảnh chính và hình ảnh của nhà cung cấp. Khi quảng cáo gốc đã bật thực thi giao diện (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 hoặc tệp nhị phân khác các thư viện chỉ định product_specific: true hoặc product_available: true trong các tệp Android.bp của họ.

  • 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 các thư viện VNDK.

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

Các thuộc tính trong Android.bp Đã tạo biến thể
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)		 cốt 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 cốt lõi, nhà cung cấp cốt lõi, nhà cung cấp
product_available: true Không áp dụng cốt lõi, sản phẩm
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 thực thi giao diện gốc được bật, các mô-đun gốc được cài đặt vào Phân vùng product có một loại liên kết native:product chỉ có thể liên kết đến 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 tính năng thực thi giao diện gốc được bật, cấu hình trình liên kết cho trình liên kết bionic 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 đến các thư viện bên ngoài phân vùng product (tuy nhiên, các quy trình đó 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 chế độ 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, quá trình thực thi sẽ cho phép hoặc không cho phép những điều sau access:

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 áp dụng cho cả việc liên kết khi tạo bản dựng và suy ngẫm trong thời gian chạy.

Thực thi thời gian xây dựng

Tại thời điểm xây dựng, Make và Soong xác minh rằng các mô-đun Java trong product không sử dụng các API ẩn bằng cách kiểm tra platform_apis và sdk_version trường. sdk_version của các ứng dụng trong phân vùng product phải được điền current, system_current hoặc phiên bản số của API 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 Tác vụ Bắt buộc
1 Xác định tệp makefile của hệ thống của riêng bạn chỉ định các gói cho Phân vùng system, sau đó thiết lập quy trình 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). N
2 Xoá danh sách được phép. N
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). Y
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 có thực thi gốc). Y
5 Kiểm tra hành vi trong thời gian chạy. Y
6 Cập nhật device.mk để thực thi giao diện sản phẩm. Y

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

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

  1. Tạo một tệp makefile xác định các gói cho phân vùng system. Cho Ví dụ: tạo tệp oem_system.mk như 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),)

  2. Trong tệp device.mk, hãy kế thừa tệp makefile chung cho system và bật tuỳ chọn kiểm tra các 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à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: hãy xác định chúng 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 thực hiện một trong những thao tác sau:

  • Cách 1: Đưa mô-đun hệ thống vào các tệp makefile có trong oem_system.mk. Việc 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 mô-đun vào phân vùng system_ext hoặc product (và không cài đặt mô-đun vào phân vùng system).

  • Cách 3: Thêm mô-đun vào PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST. Trang 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

Ở bước này, bạn tạo PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST trống để tất cả thiết bị chia sẻ oem_system.mk cũng có thể chia sẻ một system hình ảnh. Để làm trống danh sách cho phép, hãy di chuyển bất kỳ mô-đun nào trong danh sách vào system_ext hoặc product phân vùng hoặc thêm chúng vào system tạo tệp. 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. Để kiểm tra nhật ký và quá trình khởi động thiết bị cũng như tìm và khắc phục lỗi liên kết trong thời gian chạy:

  1. Đặt PRODUCT_PRODUCT_VNDK_VERSION := current.

  2. 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. Giờ nghỉ giải lao thông thường bao gồm:

    • Mọi mô-đun hidl_interface có product_specific: true sẽ không có sẵn cho các mô-đun hệ thống. Để khắc phục, hãy thay thế product_specific: true cùng với 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.

  3. Giải quyết lỗi bản dựng và đảm bảo rằng thiết bị được tạo thành công.

  4. Cài đặt ROM hình ảnh và tìm lỗi thời gian chạy trong nhật ký và quá trình khởi động 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 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:.

  5. 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ả. Tìm hai loại lỗi cụ thể:

  • Lỗi 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. Ví dụ về lỗi:

    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 biểu tượng. Lỗi này cho biết rằng không thể tìm thấy biểu tượng vì nó 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ế. Ví dụ về lỗi:

    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

Ở bước này, bạn xác minh các hành vi trong thời gian chạy 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 veridex công cụ phân tích tĩnh để biết kiểu sử dụng (liên kết hoặc suy ngẫm), mức giới hạn 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 veridex công cụ.

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