Menerapkan Antarmuka Partisi Produk

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

Menegakkan antarmuka asli

Untuk mengaktifkan penegakan antarmuka asli, current PRODUCT_PRODUCT_VNDK_VERSION ke . (Versi secara otomatis disetel ke current ketika level API pengiriman untuk target lebih besar dari 29.) Penegakan memungkinkan:

• Modul asli di partisi product untuk ditautkan:
  • Statis atau dinamis ke modul lain di partisi product yang menyertakan pustaka statis, bersama, atau header.
  • 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 adalah tambahan untuk 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 penegakan antarmuka asli diaktifkan ( PRODUCT_PRODUCT_VNDK_VERSION disetel ke current ):

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

• Modul dengan vendor_available: true dalam file Android.bp mereka tersedia untuk varian produk dan varian vendor.

• Pustaka atau biner yang menentukan product_specific: true dapat menautkan ke pustaka lain yang menentukan product_specific: true atau vendor_available: true di file Android.bp mereka.

• Pustaka VNDK harus memiliki vendor_available: true dalam file Android.bp mereka sehingga binari product dapat ditautkan ke lib VNDK.

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

Penegakan waktu build (Android.mk)

Saat penerapan antarmuka asli diaktifkan, modul asli yang dipasang ke partisi product memiliki jenis tautan native:product yang hanya dapat menautkan ke modul native:product atau native:vndk . Mencoba menautkan ke modul apa pun selain ini menyebabkan sistem pembangunan menghasilkan kesalahan pemeriksaan jenis tautan.

Penegakan runtime

Saat penegakan antarmuka asli diaktifkan, konfigurasi penaut untuk penaut bionik tidak mengizinkan proses sistem menggunakan pustaka product , membuat bagian product untuk proses product yang tidak dapat menautkan ke pustaka di luar partisi product (namun, proses tersebut dapat tautan ke perpustakaan VNDK). Upaya untuk melanggar konfigurasi tautan runtime menyebabkan proses gagal dan menghasilkan pesan kesalahan CANNOT LINK EXECUTABLE .

Menerapkan antarmuka Java

Untuk mengaktifkan penegakan antarmuka Java, setel PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE ke true . (Nilai secara otomatis disetel ke true ketika level API pengiriman untuk target lebih besar dari 29.) Saat diaktifkan, penegakan mengizinkan/melarang akses berikut.

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

Membangun penegakan waktu

Pada waktu pembuatan, Make and 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 runtime

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

Mengaktifkan penegakan 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 menentukan system makefile.

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 , mewarisi makefile umum untuk partisi system dan mengaktifkan pemeriksaan persyaratan jalur artefak. Sebagai contoh:

   $(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 pembangunan mencegah paket yang ditentukan dalam makefile lain untuk menginstal ke jalur yang ditentukan dalam require-artifacts-in-path dan mencegah paket yang ditentukan dalam makefile saat ini dari menginstal artefak di luar jalur yang ditentukan dalam 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 menyertakan modul ini, Anda harus mendefinisikannya di file oem_system.mk itu sendiri atau di makefile yang disertakan. Upaya untuk menginstal modul ke jalur yang tidak diizinkan menyebabkan build break. Untuk memperbaiki jeda, lakukan salah satu hal berikut:

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

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

• Opsi 3: Tambahkan modul ke PRODUCT_ARTIFACT_PATH_REQUIREMENT_ALLOWED_LIST . Daftar ini memungkinkan modul untuk diinstal.

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 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 menetapkan PRODUCT_PRODUCT_VNDK_VERSION := current , lalu mencari kesalahan build dan runtime dan 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 pembuatan. Anda mungkin melihat beberapa jeda build untuk varian produk atau varian inti yang hilang. Istirahat umum meliputi:

   • Setiap modul hidl_interface 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 itu tersedia untuk partisi product dengan menyetel vendor_available: true atau pindahkan modul ke partisi product dengan menyetel product_specific: true .

3. Atasi kesalahan pembuatan dan pastikan perangkat berhasil dibuat.

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

   • Jika tag linker dari log kasus pengujian menunjukkan pesan CANNOT LINK EXECUTABLE , file make tidak memiliki dependensi (dan tidak ditangkap pada waktu build).
   • Untuk memeriksanya dari sistem build, tambahkan pustaka 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 menetapkan PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true , lalu temukan dan perbaiki kesalahan pembuatan yang dihasilkan. Cari dua jenis kesalahan tertentu:

• Kesalahan jenis tautan. Kesalahan ini menunjukkan bahwa aplikasi menautkan ke modul Java yang memiliki sdk_version yang 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 dengan log menggunakan StrictMode.detectNonSdkApiUsage (yang menghasilkan log saat aplikasi menggunakan API tersembunyi). Atau, Anda dapat menggunakan alat analisis statis veridex untuk mendapatkan jenis penggunaan (penautan 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 device.mk

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

• PRODUCT_PRODUCT_VNDK_VERSION := current
• PRODUCT_ENFORCE_PRODUCT_PARTITION_INTERFACE := true