Menerapkan Antarmuka Partisi Produk

Android 11 memisahkan partisi product , menjadikannya independen dari partisi system dan vendor . Sebagai bagian dari perubahan ini, Anda kini dapat mengontrol akses partisi product ke antarmuka asli dan Java (yang mirip dengan cara kerja penerapan antarmuka untuk partisi vendor ).

Menerapkan antarmuka asli

Untuk mengaktifkan penerapan antarmuka asli, setel PRODUCT_PRODUCT_VNDK_VERSION ke current . (Versi ini secara otomatis disetel ke current ketika tingkat API pengiriman untuk target lebih besar dari 29.) Penerapan memungkinkan:

• Modul asli di partisi product untuk ditautkan:
  • Secara statis atau dinamis ke modul lain di partisi product yang menyertakan pustaka statis, bersama, atau header.
  • Secara dinamis ke perpustakaan VNDK di partisi system .
• Pustaka JNI dalam APK yang tidak dibundel di partisi product untuk ditautkan ke pustaka di /product/lib atau /product/lib64 (ini merupakan tambahan pada pustaka NDK).

Penegakan tidak mengizinkan tautan lain ke partisi selain partisi product .

Penegakan waktu build (Android.bp)

Di Android 11, modul sistem dapat membuat varian gambar produk selain varian gambar inti dan vendor. Saat penerapan antarmuka asli diaktifkan ( PRODUCT_PRODUCT_VNDK_VERSION disetel ke current ):

• Modul asli di partisi product berada dalam varian produk, bukan varian inti.

• Modul dengan product_available: true dalam file Android.bp tersedia untuk varian produk.

• Pustaka atau binari yang menentukan product_specific: true dapat ditautkan ke pustaka lain yang menentukan product_specific: true atau product_available: true dalam file Android.bp nya.

• Library VNDK harus memiliki product_available: true di file Android.bp nya sehingga biner product dapat ditautkan ke lib VNDK.

Tabel berikut merangkum properti Android.bp yang digunakan untuk membuat varian gambar.

Penegakan waktu pembangunan (Android.mk)

Ketika penerapan antarmuka asli diaktifkan, modul asli yang diinstal ke partisi product memiliki jenis tautan native:product yang hanya dapat ditautkan ke native:product atau native:vndk lainnya. Mencoba menautkan ke modul apa pun selain ini menyebabkan sistem build menghasilkan kesalahan pemeriksaan jenis tautan.

Penegakan waktu proses

Ketika penerapan antarmuka asli diaktifkan, konfigurasi linker untuk bionic linker tidak mengizinkan proses sistem menggunakan pustaka product , sehingga membuat bagian product untuk proses product tidak dapat ditautkan ke pustaka di luar partisi product (namun, proses tersebut dapat tautan ke perpustakaan VNDK). Upaya untuk melanggar konfigurasi link runtime menyebabkan proses gagal dan menghasilkan pesan kesalahan CANNOT LINK EXECUTABLE .

Menerapkan antarmuka Java

Untuk mengaktifkan penerapan antarmuka Java, setel PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE ke true . (Nilai secara otomatis ditetapkan ke true ketika tingkat API pengiriman untuk target lebih besar dari 29.) Jika diaktifkan, penegakan mengizinkan/menolak akses berikut.

Seperti di partisi vendor , aplikasi atau pustaka Java di partisi product hanya diperbolehkan menggunakan API publik dan sistem; menautkan ke perpustakaan yang menggunakan API tersembunyi tidak diperbolehkan. Pembatasan ini mencakup penautan pada waktu pembuatan dan refleksi pada waktu proses.

Membangun penegakan waktu

Pada waktu pembangunan, Make dan Soong memverifikasi bahwa modul Java di partisi product tidak menggunakan API tersembunyi dengan memeriksa bidang platform_apis dan sdk_version . sdk_version aplikasi di partisi product harus diisi dengan versi API current , system_current , atau numerik, dan bidang platform_apis harus kosong.

Penegakan waktu proses

Runtime Android memverifikasi bahwa aplikasi di partisi product tidak menggunakan API tersembunyi, termasuk refleksi. Untuk mengetahui detailnya, lihat Pembatasan pada antarmuka non-SDK .

Mengaktifkan penerapan antarmuka produk

Gunakan langkah-langkah di bagian ini untuk mengaktifkan penerapan antarmuka produk.

Langkah 1: Buat makefile dan aktifkan pemeriksaan jalur artefak

Pada langkah ini, Anda mendefinisikan makefile system .

1. Buat makefile yang mendefinisikan paket untuk partisi system . Misalnya, buat file oem_system.mk dengan yang berikut ini:

   $(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. Dalam file device.mk , warisi makefile umum untuk partisi system dan aktifkan pemeriksaan persyaratan jalur artefak. Misalnya:

   $(call inherit-product, $(SRC_TARGET_DIR)/product/oem_system.mk)
   
   # Enable artifact path requirements checking
   PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS := strict
   

Tentang persyaratan jalur artefak

Ketika PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS disetel ke true atau strict , sistem build akan mencegah paket yang ditentukan di makefile lain agar tidak dipasang ke jalur yang ditentukan di require-artifacts-in-path dan mencegah paket yang ditentukan di makefile saat ini memasang artefak di luar jalur yang ditentukan di require-artifacts-in-path .

Pada contoh di atas, dengan PRODUCT_ENFORCE_ARTIFACT_PATH_REQUIREMENTS disetel ke strict , makefile di luar oem_system.mk tidak dapat menyertakan modul yang diinstal ke root atau partisi system . Untuk memasukkan modul-modul ini, Anda harus mendefinisikannya dalam file oem_system.mk itu sendiri atau dalam makefile yang disertakan. Upaya memasang modul ke jalur yang tidak diizinkan menyebabkan kerusakan build. Untuk memperbaiki kerusakan, lakukan salah satu hal berikut:

• Opsi 1: Sertakan modul sistem dalam makefile yang disertakan dalam oem_system.mk . Hal ini membuat persyaratan jalur artefak terpenuhi (karena modul sekarang ada dalam makefile yang disertakan) dan dengan demikian memungkinkan instalasi ke kumpulan jalur di `require-artifacts-in-path.

• Opsi 2: Instal modul ke partisi system_ext atau product (dan jangan instal modul ke partisi system ).

• Opsi 3: Tambahkan modul ke PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST . Ini berisi daftar modul yang diizinkan untuk dipasang.

Langkah 2: Kosongkan daftar yang diizinkan

Pada langkah ini, Anda mengosongkan PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST sehingga semua perangkat yang berbagi oem_system.mk juga dapat berbagi satu citra system . Untuk mengosongkan daftar yang diizinkan, pindahkan modul apa pun dalam daftar ke system_ext atau partisi product atau tambahkan ke file pembuatan system . Langkah ini bersifat opsional karena menentukan citra system umum tidak diperlukan untuk mengaktifkan penerapan antarmuka produk. Namun, mengosongkan daftar yang diizinkan berguna untuk menentukan batas system dengan system_ext .

Langkah 3: Terapkan antarmuka asli

Pada langkah ini, Anda menyetel PRODUCT_PRODUCT_VNDK_VERSION := current , lalu mencari kesalahan build dan runtime serta menyelesaikannya. Untuk memeriksa boot dan log perangkat serta menemukan dan memperbaiki kegagalan tautan runtime:

1. Setel PRODUCT_PRODUCT_VNDK_VERSION := current .

2. Bangun perangkat dan cari kesalahan build. Anda mungkin akan melihat beberapa jeda build untuk varian produk atau varian inti yang hilang. Istirahat umum meliputi:

   • Modul hidl_interface apa pun yang memiliki product_specific: true tidak akan tersedia untuk modul sistem. Untuk memperbaikinya, ganti product_specific: true dengan system_ext_specfic: true .
   • Modul mungkin tidak memiliki varian produk yang diperlukan untuk modul produk. Untuk memperbaikinya, buat modul tersebut tersedia untuk partisi product dengan menyetel product_available: true atau pindahkan modul ke partisi product dengan menyetel product_specific: true .

3. Atasi kesalahan build dan pastikan perangkat berhasil dibuat.

4. Flash gambar dan cari kesalahan runtime pada boot dan log perangkat.

   • Jika tag linker dari log kasus pengujian menampilkan pesan CANNOT LINK EXECUTABLE , berarti file make tidak memiliki ketergantungan (dan tidak ditangkap pada waktu pembuatan).
   • Untuk memeriksanya dari sistem build, tambahkan perpustakaan yang diperlukan ke bidang shared_libs: atau required:

5. Selesaikan dependensi yang hilang menggunakan panduan yang diberikan di atas.

Langkah 4: Terapkan antarmuka Java

Pada langkah ini, Anda menyetel PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true , lalu temukan dan perbaiki kesalahan build yang dihasilkan. Carilah dua jenis kesalahan tertentu:

• Kesalahan jenis tautan. Kesalahan ini menunjukkan bahwa aplikasi tertaut ke modul Java yang memiliki sdk_version lebih luas. Untuk memperbaikinya, Anda dapat memperluas sdk_version aplikasi atau membatasi sdk_version perpustakaan. Contoh kesalahan:

  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.
  

• Kesalahan simbol. Kesalahan ini menunjukkan bahwa simbol tidak dapat ditemukan karena berada di API tersembunyi. Untuk memperbaikinya, gunakan API yang terlihat (tidak tersembunyi) atau cari alternatif. Contoh kesalahan:

  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
  

Langkah 5: Periksa perilaku runtime

Pada langkah ini, Anda memverifikasi perilaku runtime seperti yang diharapkan. Untuk aplikasi yang dapat di-debug, Anda dapat memantau penggunaan API tersembunyi melalui log menggunakan StrictMode.detectNonSdkApiUsage (yang menghasilkan log saat aplikasi menggunakan API tersembunyi). Alternatifnya, Anda dapat menggunakan alat analisis statis veridex untuk mendapatkan jenis penggunaan (tautan atau refleksi), tingkat pembatasan, dan tumpukan panggilan.

• Sintaks Veridex:

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

• Contoh hasil 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;
  

Untuk detail tentang penggunaan veridex, lihat Menguji menggunakan alat veridex .

Langkah 6: Perbarui perangkat.mk

Setelah memperbaiki semua kegagalan build dan runtime, serta memverifikasi bahwa perilaku runtime sesuai yang diharapkan, atur yang berikut ini di device.mk :

• PRODUCT_PRODUCT_VNDK_VERSION := current
• PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true