Format file APEX

Format container Android Pony EXpress (APEX) diperkenalkan di Android 10 dan digunakan dalam alur penginstalan untuk modul sistem tingkat lebih rendah. Format ini memfasilitasi update komponen sistem yang tidak sesuai dengan model aplikasi Android standar. Beberapa contoh komponen adalah layanan dan library native, lapisan abstraksi hardware (HAL), runtime (ART), dan library class.

Istilah "APEX" juga dapat merujuk pada file APEX.

Latar belakang

Meskipun Android mendukung update modul yang sesuai dengan model aplikasi standar (misalnya, layanan, aktivitas) melalui aplikasi penginstal paket (seperti aplikasi Google Play Store), menggunakan model serupa untuk komponen OS tingkat rendah memiliki kelemahan berikut:

• Modul berbasis APK tidak dapat digunakan di awal urutan booting. Pengelola paket adalah repositori pusat informasi tentang aplikasi dan hanya dapat dimulai dari pengelola aktivitas, yang siap pada tahap berikutnya dari prosedur booting.
• Format APK (terutama manifes) didesain untuk aplikasi Android dan modul sistem tidak selalu sesuai.

Desain

Bagian ini menjelaskan desain tingkat tinggi dari format file APEX dan pengelola APEX, yang merupakan layanan yang mengelola file APEX.

Untuk mengetahui informasi selengkapnya terkait alasan dipilihnya desain untuk APEX ini, lihat Alternatif yang dipertimbangkan saat mengembangkan APEX.

Format APEX

Ini adalah format file APEX.

Gambar 1. Format file APEX

Di tingkat teratas, file APEX adalah file zip tempat file disimpan tanpa dikompresi dan terletak di batas 4 KB.

Keempat file dalam file APEX adalah:

• apex_manifest.json
• AndroidManifest.xml
• apex_payload.img
• apex_pubkey

File apex_manifest.json berisi nama dan versi paket, yang mengidentifikasi file APEX. Ini adalah buffering protokol ApexManifest dalam format JSON.

File AndroidManifest.xml memungkinkan file APEX menggunakan alat dan infrastruktur terkait APK seperti ADB, PackageManager, dan aplikasi penginstal paket (seperti Play Store). Misalnya, file APEX dapat menggunakan alat yang ada seperti aapt untuk memeriksa metadata dasar dari file. File tersebut berisi nama paket dan informasi versi. Informasi ini umumnya juga tersedia di apex_manifest.json.

apex_manifest.json direkomendasikan daripada AndroidManifest.xml untuk kode dan sistem baru yang menangani APEX. AndroidManifest.xml mungkin berisi informasi penargetan tambahan yang dapat digunakan oleh alat publikasi aplikasi yang sudah ada.

apex_payload.img adalah image sistem file ext4 yang didukung oleh dm-verity. Image dipasang saat runtime melalui perangkat loopback. Secara khusus, hierarki hash dan blok metadata dibuat menggunakan library libavb. Payload sistem file tidak diurai (karena gambar harus dapat dipasang di tempatnya). File reguler disertakan dalam file apex_payload.img.

apex_pubkey adalah kunci publik yang digunakan untuk menandatangani image sistem file. Saat runtime, kunci ini memastikan bahwa APEX yang didownload ditandatangani dengan entitas yang sama yang menandatangani APEX yang sama di partisi bawaan.

Panduan penamaan APEX

Untuk membantu mencegah konflik penamaan antara APEX baru seiring kemajuan platform, gunakan panduan penamaan berikut:

• com.android.*
  • Disimpan untuk APEX AOSP. Tidak unik untuk perusahaan atau perangkat mana pun.
• com.<companyname>.*
  • Disimpan untuk perusahaan. Berpotensi digunakan oleh beberapa perangkat dari perusahaan tersebut.
• com.<companyname>.<devicename>.*
  • Direservasi untuk APEX yang unik untuk perangkat tertentu (atau sebagian perangkat).

Pengelola APEX

Pengelola APEX (atau apexd) adalah proses native mandiri yang bertanggung jawab untuk memverifikasi, menginstal, dan meng-uninstal file APEX. Proses ini diluncurkan dan siap di awal urutan {i>booting<i}. File APEX biasanya sudah diinstal sebelumnya pada perangkat pada /system/apex. Secara default, pengelola APEX akan menggunakan paket ini jika tidak ada update yang tersedia.

Urutan update APEX menggunakan class PackageManager dan sebagai berikut.

1. File APEX didownload melalui aplikasi penginstal paket, ADB, atau sumber lainnya.
2. Pengelola paket memulai prosedur penginstalan. Setelah mengenali bahwa file tersebut adalah APEX, pengelola paket akan mentransfer kontrol ke pengelola APEX.
3. Pengelola APEX memverifikasi file APEX.
4. Jika file APEX diverifikasi, database internal pengelola APEX akan diperbarui untuk menunjukkan bahwa file APEX diaktifkan saat booting berikutnya.
5. Pemohon penginstalan menerima siaran setelah verifikasi paket berhasil.
6. Untuk melanjutkan penginstalan, sistem harus dimulai ulang.

7. Saat booting berikutnya, pengelola APEX akan dimulai, membaca database internal, dan melakukan hal berikut untuk setiap file APEX yang tercantum:

   1. Memverifikasi file APEX.
   2. Membuat perangkat loopback dari file APEX.
   3. Membuat perangkat pemetaan perangkat blok di atas perangkat loopback.
   4. Memasang perangkat blok mapper perangkat ke jalur unik (misalnya, /apex/name@ver).

Saat semua file APEX yang tercantum dalam database internal dipasang, pengelola APEX akan menyediakan layanan binder untuk komponen sistem lain guna membuat kueri informasi tentang file APEX yang diinstal. Misalnya, komponen sistem lainnya dapat mengkueri daftar file APEX yang diinstal di perangkat atau membuat kueri jalur persis tempat APEX tertentu dipasang, sehingga file dapat diakses.

File APEX adalah file APK

File APEX adalah file APK yang valid karena merupakan arsip zip yang ditandatangani (menggunakan skema tanda tangan APK) yang berisi file AndroidManifest.xml. Hal ini memungkinkan file APEX menggunakan infrastruktur untuk file APK, seperti aplikasi penginstal paket, utilitas penandatanganan, dan pengelola paket.

File AndroidManifest.xml dalam file APEX berukuran minimal, yang terdiri dari paket name, versionCode, serta targetSdkVersion, minSdkVersion, dan maxSdkVersion opsional untuk penargetan yang lebih mendetail. Informasi ini memungkinkan file APEX dikirim melalui saluran yang ada seperti aplikasi penginstal paket dan ADB.

Jenis file yang didukung

Format APEX mendukung jenis file ini:

• Library bersama native
• File yang dapat dieksekusi native
• File JAR
• File data
• File konfigurasi

Hal ini tidak berarti bahwa APEX dapat mengupdate semua jenis file ini. Jenis file dapat diperbarui bergantung pada platform dan seberapa stabil definisi antarmuka untuk jenis file tersebut.

Opsi penandatanganan

File APEX ditandatangani dengan dua cara. Pertama, file apex_payload.img (khususnya, deskriptor vbmeta yang ditambahkan ke apex_payload.img) ditandatangani dengan kunci. Kemudian, seluruh APEX ditandatangani menggunakan APK signature scheme v3. Dua kunci berbeda digunakan dalam proses ini.

Di sisi perangkat, kunci publik yang sesuai dengan kunci pribadi yang digunakan untuk menandatangani deskriptor vbmeta diinstal. Pengelola APEX menggunakan kunci publik untuk memverifikasi APEX yang diminta untuk diinstal. Setiap APEX harus ditandatangani dengan kunci yang berbeda dan diterapkan baik pada waktu build maupun saat runtime.

APEX di partisi bawaan

File APEX dapat ditempatkan di partisi bawaan seperti /system. Partisi sudah melampaui dm-verity, sehingga file APEX dipasang langsung di perangkat loopback.

Jika APEX ada di partisi bawaan, APEX dapat diupdate dengan menyediakan paket APEX dengan nama paket yang sama dan kode versi yang lebih besar atau sama dengan kode versi. APEX baru disimpan di /data dan, mirip dengan APK, versi yang baru diinstal akan menyamarkan versi yang sudah ada di partisi bawaan. Namun, tidak seperti APK, versi APEX yang baru diinstal hanya diaktifkan setelah reboot.

Persyaratan kernel

Untuk mendukung modul mainline APEX di perangkat Android, fitur kernel Linux berikut diperlukan: driver loopback dan dm-verity. Driver loopback memasang image sistem file dalam modul APEX dan dm-verity memverifikasi modul APEX.

Performa driver loopback dan dm-verity penting untuk mencapai performa sistem yang baik saat menggunakan modul APEX.

Versi kernel yang didukung

Modul mainline APEX didukung pada perangkat yang menggunakan kernel versi 4.4 atau yang lebih tinggi. Perangkat baru yang diluncurkan dengan Android 10 atau yang lebih tinggi harus menggunakan kernel versi 4.9 atau yang lebih tinggi untuk mendukung modul APEX.

Patch kernel yang diperlukan

Patch kernel yang diperlukan untuk mendukung modul APEX disertakan dalam hierarki umum Android. Untuk mendapatkan patch guna mendukung APEX, gunakan versi terbaru pohon umum Android.

Kernel versi 4.4

Versi ini hanya didukung untuk perangkat yang diupgrade dari Android 9 ke Android 10 dan ingin mendukung modul APEX. Untuk mendapatkan patch yang diperlukan, penggabungan down dari cabang android-4.4 sangat direkomendasikan. Berikut adalah daftar patch individual yang diperlukan untuk kernel versi 4.4.

• UPSTREAM: loop: menambahkan ioctl untuk mengubah ukuran blok logis (4.4)
• BACKPORT: block/loop: set hw_sectors (4.4)
• UPSTREAM: loop: Menambahkan LOOP_SET_BLOCK_SIZE di compat ioctl (4.4)
• ANDROID: mnt: Memperbaiki next_descendent (4.4)
• ANDROID: mnt: remount akan diterapkan ke slave slave (4.4)
• ANDROID: mnt: Memperluas pemasangan ulang dengan benar (4.4)
• Mengembalikan "ANDROID: dm verity: add minimum prefetch size" (4.4)
• UPSTREAM: loop: menghapus cache jika offset atau block_size diubah (4.4)

Kernel versi 4.9/4.14/4.19

Guna mendapatkan patch yang diperlukan untuk kernel versi 4.9/4.14/4.19, lakukan penggabungan dari cabang android-common.

Opsi konfigurasi kernel yang diperlukan

Daftar berikut menunjukkan persyaratan konfigurasi dasar untuk mendukung modul APEX yang diperkenalkan di Android 10. Item dengan tanda bintang (*) adalah persyaratan yang sudah ada mulai dari Android 9 dan yang lebih lama.

(*) CONFIG_AIO=Y # AIO support (for direct I/O on loop devices)
CONFIG_BLK_DEV_LOOP=Y # for loop device support
CONFIG_BLK_DEV_LOOP_MIN_COUNT=16 # pre-create 16 loop devices
(*) CONFIG_CRYPTO_SHA1=Y # SHA1 hash for DM-verity
(*) CONFIG_CRYPTO_SHA256=Y # SHA256 hash for DM-verity
CONFIG_DM_VERITY=Y # DM-verity support

Persyaratan parameter command line kernel

Untuk mendukung APEX, pastikan parameter command line kernel memenuhi persyaratan berikut:

• loop.max_loop TIDAK boleh ditetapkan
• loop.max_part harus <= 8

Membangun APEX

Bagian ini menjelaskan cara membangun APEX menggunakan sistem build Android. Berikut adalah contoh Android.bp untuk APEX bernama apex.test.

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    // libc.so and libcutils.so are included in the apex
    native_shared_libs: ["libc", "libcutils"],
    binaries: ["vold"],
    java_libs: ["core-all"],
    prebuilts: ["my_prebuilt"],
    compile_multilib: "both",
    key: "apex.test.key",
    certificate: "platform",
}

Contoh apex_manifest.json:

{
  "name": "com.android.example.apex",
  "version": 1
}

Contoh file_contexts:

(/.*)?           u:object_r:system_file:s0
/sub(/.*)?       u:object_r:sub_file:s0
/sub/file3       u:object_r:file3_file:s0

Jenis dan lokasi file di APEX

Dependensi transitif

File APEX secara otomatis menyertakan dependensi transitif library native bersama atau file yang dapat dieksekusi. Misalnya, jika libFoo bergantung pada libBar, kedua library tersebut disertakan jika hanya libFoo yang tercantum dalam properti native_shared_libs.

Menangani beberapa ABI

Instal properti native_shared_libs untuk antarmuka biner aplikasi (ABI) utama dan sekunder perangkat. Jika APEX menargetkan perangkat dengan satu ABI (yaitu, hanya 32 bit atau hanya 64 bit), hanya library dengan ABI yang sesuai yang diinstal.

Instal properti binaries hanya untuk ABI utama perangkat seperti yang dijelaskan di bawah:

• Jika perangkat hanya 32 bit, hanya varian biner 32-bit yang diinstal.
• Jika perangkat hanya 64 bit, hanya varian biner 64-bit yang diinstal.

Untuk menambahkan kontrol terperinci atas ABI library dan biner native, gunakan properti multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries].

• first: Mencocokkan ABI primer perangkat. Ini adalah setelan default untuk biner.
• lib32: Mencocokkan ABI 32-bit perangkat, jika didukung.
• lib64: Mencocokkan ABI 64-bit perangkat, yang didukung.
• prefer32: Cocok dengan ABI 32-bit perangkat, jika didukung. Jika ABI 32-bit tidak didukung, cocok dengan ABI 64-bit.
• both: Mencocokkan kedua ABI. Ini adalah default untuk native_shared_libraries.

Properti java, libraries, dan prebuilts tidak bergantung pada ABI.

Contoh ini ditujukan untuk perangkat yang mendukung 32/64 dan tidak lebih memilih 32:

apex {
    // other properties are omitted
    native_shared_libs: ["libFoo"], // installed for 32 and 64
    binaries: ["exec1"], // installed for 64, but not for 32
    multilib: {
        first: {
            native_shared_libs: ["libBar"], // installed for 64, but not for 32
            binaries: ["exec2"], // same as binaries without multilib.first
        },
        both: {
            native_shared_libs: ["libBaz"], // same as native_shared_libs without multilib
            binaries: ["exec3"], // installed for 32 and 64
        },
        prefer32: {
            native_shared_libs: ["libX"], // installed for 32, but not for 64
        },
        lib64: {
            native_shared_libs: ["libY"], // installed for 64, but not for 32
        },
    },
}

Penandatanganan vbmeta

Tanda tangani setiap APEX dengan kunci yang berbeda. Jika kunci baru diperlukan, buat pasangan kunci publik-pribadi dan buat modul apex_key. Gunakan properti key untuk menandatangani APEX menggunakan kunci. Kunci publik secara otomatis disertakan dalam APEX dengan nama avb_pubkey.

# create an rsa key pair
openssl genrsa -out foo.pem 4096

# extract the public key from the key pair
avbtool extract_public_key --key foo.pem --output foo.avbpubkey

# in Android.bp
apex_key {
    name: "apex.test.key",
    public_key: "foo.avbpubkey",
    private_key: "foo.pem",
}

Pada contoh di atas, nama kunci publik (foo) menjadi ID kunci tersebut. ID kunci yang digunakan untuk menandatangani APEX ditulis dalam APEX. Saat runtime, apexd memverifikasi APEX menggunakan kunci publik dengan ID yang sama di perangkat.

Penandatanganan APEX

Tanda tangani APEX dengan cara yang sama seperti Anda menandatangani APK. Tanda tangani APEX dua kali; sekali untuk sistem file mini (file apex_payload.img) dan sekali untuk seluruh file.

Untuk menandatangani APEX di tingkat file, tetapkan properti certificate dengan salah satu dari tiga cara berikut:

• Tidak ditetapkan: Jika tidak ada nilai yang ditetapkan, APEX akan ditandatangani dengan sertifikat yang berada di PRODUCT_DEFAULT_DEV_CERTIFICATE. Jika tidak ada tanda yang ditetapkan, jalur akan ditetapkan secara default ke build/target/product/security/testkey.
• <name>: APEX ditandatangani dengan sertifikat <name> di direktori yang sama dengan PRODUCT_DEFAULT_DEV_CERTIFICATE.
• :<name>: APEX ditandatangani dengan sertifikat yang ditentukan oleh modul Soong bernama <name>. Modul sertifikat dapat didefinisikan sebagai berikut.

android_app_certificate {
    name: "my_key_name",
    certificate: "dir/cert",
    // this will use dir/cert.x509.pem (the cert) and dir/cert.pk8 (the private key)
}

Menginstal APEX

Untuk menginstal APEX, gunakan ADB.

adb install apex_file_name
adb reboot

Jika supportsRebootlessUpdate disetel ke true di apex_manifest.json dan APEX yang saat ini diinstal tidak digunakan (misalnya, layanan apa pun yang dikandungnya telah dihentikan), APEX baru dapat diinstal tanpa memulai ulang dengan flag --force-non-staged.

adb install --force-non-staged apex_file_name

Menggunakan APEX

Setelah dimulai ulang, APEX akan dipasang di direktori /apex/<apex_name>@<version>. Beberapa versi APEX yang sama dapat dipasang secara bersamaan. Di antara jalur pemasangan, jalur yang sesuai dengan versi terbaru dipasang di /apex/<apex_name>.

Klien dapat menggunakan jalur yang di-bind-mount untuk membaca atau mengeksekusi file dari APEX.

APEX biasanya digunakan sebagai berikut:

1. OEM atau ODM memuat APEX secara otomatis di bagian /system/apex saat perangkat dikirim.
2. File di APEX diakses melalui jalur /apex/<apex_name>/.
3. Saat versi APEX yang diupdate diinstal di /data/apex, jalur akan mengarah ke APEX baru setelah dimulai ulang.

Memperbarui layanan dengan APEX

Untuk mengupdate layanan menggunakan APEX:

1. Tandai layanan di partisi sistem sebagai dapat diperbarui. Tambahkan opsi updatable ke definisi layanan.

   /system/etc/init/myservice.rc:
   
   service myservice /system/bin/myservice
       class core
       user system
       ...
       updatable
   

2. Buat file .rc baru untuk layanan yang diupdate. Gunakan opsi override untuk menentukan ulang layanan yang ada.

   /apex/my.apex/etc/init.rc:
   
   service myservice /apex/my.apex/bin/myservice
       class core
       user system
       ...
       override
   

Definisi layanan hanya dapat ditentukan dalam file .rc dari APEX. Pemicu tindakan tidak didukung di APEX.

Jika layanan yang ditandai sebagai dapat diupdate dimulai sebelum APEX diaktifkan, mulai akan tertunda hingga aktivasi APEX selesai.

Mengonfigurasi sistem untuk mendukung update APEX

Tetapkan properti sistem berikut ke true untuk mendukung pembaruan file APEX.

<device.mk>:

PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true

BoardConfig.mk:
TARGET_FLATTEN_APEX := false

atau hanya

<device.mk>:

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

APEX Rata

Untuk perangkat lama, terkadang tidak mungkin atau tidak dapat mengupdate kernel lama untuk mendukung APEX sepenuhnya. Misalnya, kernel mungkin dibuat tanpa CONFIG_BLK_DEV_LOOP=Y, yang penting untuk memasang image sistem file di dalam APEX.

APEX rata adalah APEX yang dibuat khusus yang dapat diaktifkan di perangkat dengan kernel lama. File dalam APEX yang disatukan akan diinstal langsung ke direktori di partisi bawaan. Misalnya, lib/libFoo.so dalam my.apex APEX yang diratakan diinstal ke /system/apex/my.apex/lib/libFoo.so.

Mengaktifkan APEX yang diratakan tidak melibatkan perangkat loop. Seluruh direktori /system/apex/my.apex langsung di-bind-mount ke /apex/name@ver.

APEX rata tidak dapat diupdate dengan mendownload APEX versi terbaru dari jaringan karena APEX yang didownload tidak dapat disatukan. APEX yang disatukan hanya dapat diupdate melalui OTA biasa.

APEX yang diratakan adalah konfigurasi default. Artinya, semua APEX secara default diratakan kecuali jika Anda secara eksplisit mengonfigurasi perangkat untuk mem-build APEX yang tidak diratakan guna mendukung update APEX (seperti yang dijelaskan di atas).

Mencampur APEX yang di-flatten dan tidak di-flatten di perangkat TIDAK didukung. APEX di perangkat harus semuanya tidak di-flatten atau semuanya di-flatten. Hal ini sangat penting saat mengirimkan build APEX bawaan yang ditandatangani sebelumnya untuk project seperti Mainline. APEX yang tidak ditandatangani sebelumnya (yaitu, dibuat dari sumber) juga harus tidak diratakan dan ditandatangani dengan kunci yang tepat. Perangkat harus mewarisi dari updatable_apex.mk seperti yang dijelaskan dalam Mengupdate layanan dengan APEX.

APEX terkompresi

Android 12 dan yang lebih baru memiliki fitur kompresi APEX untuk mengurangi dampak penyimpanan paket APEX yang dapat diperbarui. Setelah update untuk APEX diinstal, meskipun versi bawaannya tidak digunakan lagi, versi tersebut masih menempati jumlah ruang yang sama. Ruang yang ditempati tersebut tetap tidak tersedia.

Kompresi APEX meminimalkan dampak penyimpanan ini dengan menggunakan kumpulan file APEX yang sangat terkompresi pada partisi hanya baca (seperti partisi /system). Android 12 dan yang lebih baru menggunakan algoritma kompresi zip DEFLATE.

Kompresi tidak memberikan pengoptimalan untuk hal berikut:

• APEX Bootstrap yang harus dipasang sangat awal dalam urutan booting.

• APEX yang tidak dapat diupdate. Kompresi hanya bermanfaat jika versi APEX yang diupdate diinstal di partisi /data. Daftar lengkap APEX yang dapat diupdate tersedia di halaman Modular System Components.

• APEX library bersama dinamis. Karena apexd selalu mengaktifkan kedua versi APEX tersebut (diinstal sebelumnya dan diupgrade), mengompresi keduanya tidak akan menambah nilai.

Format file APEX yang dikompresi

Ini adalah format file APEX yang dikompresi.

Gambar 2. Format file APEX terkompresi

Di tingkat teratas, file APEX yang dikompresi adalah file zip yang berisi file apex asli dalam bentuk yang dipecah dengan tingkat kompresi 9, dan dengan file lain yang disimpan tanpa kompresi.

Empat file terdiri dari file APEX:

• original_apex: dikempiskan dengan tingkat kompresi 9 Ini adalah file APEX asli yang tidak dikompresi.
• apex_manifest.pb: hanya disimpan
• AndroidManifest.xml: hanya disimpan
• apex_pubkey: hanya disimpan

File apex_manifest.pb, AndroidManifest.xml, dan apex_pubkey adalah salinan file yang sesuai di original_apex.

Membangun APEX terkompresi

APEX yang dikompresi dapat dibuat menggunakan alat apex_compression_tool.py yang terletak di system/apex/tools.

Beberapa parameter yang terkait dengan kompresi APEX tersedia dalam sistem build.

Di Android.bp, apakah file APEX dapat dikompresi atau tidak dikontrol oleh properti compressible:

apex {
    name: "apex.test",
    manifest: "apex_manifest.json",
    file_contexts: "file_contexts",
    compressible: true,
}

Flag produk PRODUCT_COMPRESSED_APEX mengontrol apakah image sistem yang di-build dari sumber harus berisi file APEX yang dikompresi.

Untuk eksperimen lokal, Anda dapat memaksa build untuk mengompresi APEX dengan menetapkan OVERRIDE_PRODUCT_COMPRESSED_APEX= ke true.

File APEX yang dikompresi yang dihasilkan oleh sistem build memiliki ekstensi .capex. Ekstensi ini memudahkan membedakan antara versi file APEX yang dikompresi dan yang tidak dikompresi.

Algoritma kompresi yang didukung

Android 12 hanya mendukung kompresi deflate-zip.

Mengaktifkan file APEX yang dikompresi selama booting

Sebelum APEX yang dikompresi dapat diaktifkan, file original_apex di dalamnya akan didekompresi ke dalam direktori /data/apex/decompressed. File APEX yang didekompresi yang dihasilkan akan ditautkan ke direktori /data/apex/active.

Perhatikan contoh berikut sebagai ilustrasi proses yang dijelaskan di atas.

Pertimbangkan /system/apex/com.android.foo.capex sebagai APEX terkompresi yang diaktifkan, dengan versionCode 37.

1. File original_apex di dalam /system/apex/com.android.foo.capex didekompresi menjadi /data/apex/decompressed/com.android.foo@37.apex.
2. restorecon /data/apex/decompressed/com.android.foo@37.apex dilakukan untuk memverifikasi bahwa aplikasi memiliki label SELinux yang benar.
3. Pemeriksaan verifikasi dilakukan pada /data/apex/decompressed/com.android.foo@37.apex untuk memastikan validitasnya: apexd memeriksa kunci publik yang dipaketkan dalam /data/apex/decompressed/com.android.foo@37.apex untuk memverifikasi bahwa kunci publik tersebut sama dengan yang dipaketkan dalam /system/apex/com.android.foo.capex.
4. File /data/apex/decompressed/com.android.foo@37.apex ditautkan secara hard ke direktori /data/apex/active/com.android.foo@37.apex.
5. Logika aktivasi reguler untuk file APEX yang tidak dikompresi dilakukan pada /data/apex/active/com.android.foo@37.apex.

Interaksi dengan OTA

File APEX yang dikompresi memiliki implikasi pada pengiriman dan penerapan OTA. Karena update OTA mungkin berisi file APEX yang dikompresi dengan level versi yang lebih tinggi dari yang aktif di perangkat, sejumlah ruang kosong harus dicadangkan sebelum perangkat dimulai ulang untuk menerapkan update OTA.

Untuk mendukung sistem OTA, apexd mengekspos dua API binder ini:

• calculateSizeForCompressedApex - menghitung ukuran yang diperlukan untuk mendekompresi file APEX dalam paket OTA. Metode ini dapat digunakan untuk memverifikasi bahwa perangkat memiliki cukup ruang sebelum OTA didownload.
• reserveSpaceForCompressedApex - mencadangkan ruang pada disk untuk digunakan nanti oleh apexd guna mendekompresi file APEX terkompresi di dalam paket OTA.

Dalam kasus update OTA A/B, apexd mencoba dekompresi di latar belakang sebagai bagian dari rutinitas OTA pasca-penginstalan. Jika dekompresi gagal, apexd akan melakukan dekompresi selama booting yang menerapkan update OTA.

Alternatif yang dipertimbangkan saat mengembangkan APEX

Berikut adalah beberapa opsi yang dipertimbangkan AOSP saat mendesain format file APEX, dan alasan opsi tersebut disertakan atau dikecualikan.

Sistem pengelolaan paket reguler

Distribusi Linux memiliki sistem pengelolaan paket seperti dpkg dan rpm, yang canggih, matang, dan andal. Namun, keduanya tidak diadopsi untuk APEX karena tidak dapat melindungi paket setelah penginstalan. Verifikasi hanya dilakukan ketika paket sedang diinstal. Penyerang dapat merusak integritas paket yang diinstal, tanpa diketahui. Ini adalah regresi untuk Android saat semua komponen sistem disimpan dalam sistem file hanya-baca yang integritasnya dilindungi oleh dm-verity untuk setiap I/O. Gangguan apa pun pada komponen sistem harus dilarang atau dapat dideteksi sehingga perangkat dapat menolak untuk melakukan booting jika disusupi.

dm-crypt untuk integritas

File dalam penampung APEX berasal dari partisi bawaan (misalnya, partisi /system) yang dilindungi oleh dm-verity, dengan modifikasi apa pun pada file dilarang bahkan setelah partisi dipasang. Untuk memberikan tingkat keamanan yang sama pada file, semua file dalam APEX disimpan dalam image sistem file yang disambungkan dengan hierarki hash dan deskriptor vbmeta. Tanpa dm-verity, APEX di partisi /data rentan terhadap perubahan yang tidak disengaja yang dilakukan setelah diverifikasi dan diinstal.

Bahkan, partisi /data juga dilindungi oleh lapisan enkripsi seperti dm-crypt. Meskipun hal ini memberikan tingkat perlindungan tertentu dari modifikasi tidak sah, tujuan utamanya adalah privasi, bukan integritas. Saat penyerang mendapatkan akses ke partisi /data, tidak akan ada perlindungan lebih lanjut, dan ini lagi-lagi merupakan regresi dibandingkan dengan setiap komponen sistem yang berada di partisi /system. Hierarki hash di dalam file APEX bersama dengan dm-verity memberikan tingkat perlindungan konten yang sama.

Mengalihkan jalur dari /system ke /apex

File komponen sistem yang dikemas dalam APEX dapat diakses melalui jalur baru seperti /apex/<name>/lib/libfoo.so. Saat file merupakan bagian dari partisi /system, file tersebut dapat diakses melalui jalur seperti /system/lib/libfoo.so. Klien file APEX (file APEX lain atau platform) harus menggunakan jalur baru. Anda mungkin perlu memperbarui kode yang ada karena perubahan jalur.

Meskipun salah satu cara untuk menghindari perubahan jalur adalah dengan menempatkan konten file dalam file APEX ke dalam partisi /system, tim Android memutuskan untuk tidak menempatkan file di partisi /system karena hal ini dapat memengaruhi performa seiring meningkatnya jumlah file yang di-overlay (bahkan mungkin ditumpuk satu per satu).

Opsi lainnya adalah membajak fungsi akses file seperti open, stat, dan readlink, sehingga jalur yang diawali dengan /system dialihkan ke jalur yang sesuai pada /apex. Tim Android menghapus opsi ini karena tidak mungkin mengubah semua fungsi yang menerima jalur. Misalnya, beberapa aplikasi menautkan Bionic secara statis, yang mengimplementasikan fungsi tersebut. Dalam kasus tersebut, aplikasi tersebut tidak dialihkan.