Format File APEX

Format container Android Pony EXpress (APEX) diperkenalkan di Android 10 dan digunakan dalam alur penginstalan untuk modul sistem tingkat rendah. Format ini memfasilitasi pembaruan komponen sistem yang tidak sesuai dengan model aplikasi Android standar. Beberapa komponen contoh adalah layanan dan perpustakaan asli, lapisan abstraksi perangkat keras ( HAL ), runtime ( ART ), dan perpustakaan kelas.

Istilah "APEX" juga dapat merujuk ke file APEX.

Latar belakang

Meskipun Android mendukung pembaruan 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 boot. Manajer paket adalah pusat penyimpanan informasi tentang aplikasi dan hanya dapat dimulai dari manajer aktivitas, yang siap pada tahap selanjutnya dari prosedur boot.
• Format APK (terutama manifes) dirancang untuk aplikasi Android dan modul sistem tidak selalu cocok.

Rancangan

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

Untuk informasi selengkapnya tentang mengapa desain untuk APEX ini dipilih, lihat Alternatif yang dipertimbangkan saat mengembangkan APEX .

format APEX

Ini adalah format file APEX.

Gambar 1. Format file APEX

Di tingkat atas, file APEX adalah file zip di mana file disimpan tidak terkompresi dan terletak pada batas 4 KB.

Empat 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.

File AndroidManifest.xml memungkinkan file APEX untuk menggunakan alat dan infrastruktur terkait APK seperti ADB, PackageManager, dan aplikasi penginstal paket (seperti Play Store). Misalnya, file APEX dapat menggunakan alat yang sudah ada seperti aapt untuk memeriksa metadata dasar dari file. File 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 penerbitan aplikasi yang ada.

apex_payload.img adalah gambar sistem file ext4 yang didukung oleh dm-verity. Gambar dipasang saat runtime melalui perangkat loopback. Secara khusus, pohon hash dan blok metadata dibuat menggunakan pustaka libavb . Payload sistem file tidak diuraikan (karena gambar harus dapat dipasang di tempatnya). File biasa disertakan di dalam file apex_payload.img .

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

Manajer APEX

Manajer APEX (atau apexd ) adalah proses asli mandiri yang bertanggung jawab untuk memverifikasi, menginstal, dan menghapus file APEX. Proses ini diluncurkan dan siap di awal urutan boot. File APEX biasanya sudah diinstal sebelumnya pada perangkat di bawah /system/apex . Manajer APEX secara default menggunakan paket-paket ini jika tidak ada pembaruan yang tersedia.

Urutan pembaruan APEX menggunakan kelas PackageManager dan adalah sebagai berikut.

1. File APEX diunduh melalui aplikasi penginstal paket, ADB, atau sumber lain.
2. Manajer paket memulai prosedur instalasi. Setelah mengenali bahwa file tersebut adalah APEX, manajer paket mentransfer kontrol ke manajer APEX.
3. Manajer APEX memverifikasi file APEX.
4. Jika file APEX diverifikasi, database internal manajer APEX diperbarui untuk mencerminkan bahwa file APEX diaktifkan pada boot berikutnya.
5. Pemohon instal menerima siaran setelah verifikasi paket berhasil.
6. Untuk melanjutkan instalasi, sistem harus di-boot ulang.

7. Pada boot berikutnya, manajer APEX memulai, membaca database internal, dan melakukan hal berikut untuk setiap file APEX yang terdaftar:

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

Ketika semua file APEX yang terdaftar di database internal sudah terpasang, manajer APEX menyediakan layanan pengikat untuk komponen sistem lain untuk menanyakan informasi tentang file APEX yang diinstal. Misalnya, komponen sistem lainnya dapat menanyakan daftar file APEX yang diinstal di perangkat atau menanyakan jalur yang tepat di mana 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 . Ini memungkinkan file APEX menggunakan infrastruktur untuk file APK, seperti aplikasi penginstal paket, utilitas penandatanganan, dan pengelola paket.

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

Jenis file yang didukung

Format APEX mendukung jenis file ini:

• lib bersama asli
• Eksekusi asli
• file JAR
• file data
• File konfigurasi

Ini tidak berarti bahwa APEX dapat memperbarui semua jenis file ini. Apakah jenis file dapat diperbarui tergantung pada platform dan seberapa stabil definisi antarmuka untuk jenis file tersebut.

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 skema tanda tangan APK 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. Manajer APEX menggunakan kunci publik untuk memverifikasi APEX yang diminta untuk diinstal. Setiap APEX harus ditandatangani dengan kunci yang berbeda dan diterapkan pada waktu pembuatan dan waktu proses.

APEX di partisi bawaan

File APEX dapat ditemukan di partisi bawaan seperti /system . Partisi sudah melebihi dm-verity, jadi file APEX dipasang langsung melalui perangkat loopback.

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

Persyaratan kernel

Untuk mendukung modul arus utama APEX pada perangkat Android, fitur kernel Linux berikut diperlukan: driver loopback dan dm-verity. Driver loopback memasang citra sistem file dalam modul APEX dan dm-verity memverifikasi modul APEX.

Kinerja driver loopback dan dm-verity penting dalam mencapai kinerja sistem yang baik saat menggunakan modul APEX.

Versi kernel yang didukung

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

Patch kernel yang diperlukan

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

Kernel versi 4.4

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

• HULU: loop: tambahkan ioctl untuk mengubah ukuran blok logis ( 4.4 )
• BACKPORT: blok/loop: set hw_sectors ( 4.4 )
• HULU: loop: Tambahkan LOOP_SET_BLOCK_SIZE di compat ioctl ( 4.4 )
• ANDROID: mnt: Perbaiki next_descendent ( 4.4 )
• ANDROID: mnt: remount harus disebarkan ke budak dari budak ( 4.4 )
• ANDROID: mnt: Menyebarkan remount dengan benar ( 4.4 )
• Kembalikan "ANDROID: dm verity: tambahkan ukuran prefetch minimum" ( 4.4 )
• HULU: loop: jatuhkan cache jika offset atau block_size diubah ( 4.4 )

Versi kernel 4.9/4.14/4.19

Untuk mendapatkan patch yang diperlukan untuk kernel versi 4.9/4.14/4.19, gabungkan 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 dari Android 9 dan yang lebih rendah.

(*) 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 baris perintah kernel

Untuk mendukung APEX, pastikan parameter baris perintah kernel memenuhi persyaratan berikut:

• loop.max_loop TIDAK harus disetel
• loop.max_part harus <= 8

Membangun APEX

Bagian ini menjelaskan cara membangun APEX menggunakan sistem pembangunan Android. Berikut ini 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

Jenis berkas	Lokasi di APEX
Pustaka bersama	/lib dan /lib64 ( /lib/arm untuk lengan yang diterjemahkan di x86)
executable	/bin
perpustakaan Jawa	/javalib
bawaan	/etc

Ketergantungan transitif

File APEX secara otomatis menyertakan dependensi transitif dari lib atau executable asli yang dibagikan. Misalnya, jika libFoo bergantung pada libBar , kedua lib disertakan ketika hanya libFoo yang terdaftar di properti native_shared_libs .

Menangani beberapa ABI

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

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

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

Untuk menambahkan kontrol mendetail atas ABI library dan binari asli, gunakan properti multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] .

• first : Cocok dengan ABI utama perangkat. Ini adalah default untuk binari.
• lib32 : Cocok dengan ABI 32-bit perangkat, jika didukung.
• lib64 : Cocok dengan ABI 64-bit perangkat, yang didukungnya.
• prefer32 : Cocok dengan ABI 32-bit perangkat, jika didukung. Jika ABI 32-bit tidak didukung, cocokkan dengan ABI 64-bit.
• both : Cocok dengan kedua ABI. Ini adalah default untuk native_shared_libraries .

Properti java , libraries , dan prebuilts adalah agnostik ABI.

Contoh ini untuk perangkat yang mendukung 32/64 dan tidak menyukai 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. Saat kunci baru diperlukan, buat pasangan kunci publik-swasta 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",
}

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

penandatanganan ZIP

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

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

• Tidak disetel: Jika tidak ada nilai yang disetel, APEX ditandatangani dengan sertifikat yang terletak di PRODUCT_DEFAULT_DEV_CERTIFICATE . Jika tidak ada tanda yang disetel, jalur defaultnya adalah 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 didefinisikan 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)
}

Catatan: Nilai key dan certificate TIDAK perlu diturunkan dari pasangan kunci publik/pribadi yang sama. Penandatanganan APK (ditentukan oleh certificate ) diperlukan karena APEX adalah APK.

Memasang APEX

Untuk menginstal APEX, gunakan ADB.

adb install apex_file_name
adb reboot

Menggunakan APEX

Setelah reboot, APEX dipasang di direktori /apex/<apex_name>@<version> . Beberapa versi dari APEX yang sama dapat dipasang pada waktu yang sama. Di antara jalur mount, salah satu yang sesuai dengan versi terbaru adalah bind-mount di /apex/<apex_name> .

Klien dapat menggunakan jalur pengikatan untuk membaca atau mengeksekusi file dari APEX.

APEX biasanya digunakan sebagai berikut:

1. OEM atau ODM memuat APEX di bawah /system/apex saat perangkat dikirimkan.
2. File di APEX diakses melalui jalur /apex/<apex_name>/ .
3. Ketika versi APEX yang diperbarui diinstal di /data/apex , jalur menunjuk ke APEX baru setelah reboot.

Memperbarui layanan dengan APEX

Untuk memperbarui layanan menggunakan APEX:

1. Tandai layanan di partisi sistem sebagai dapat diperbarui. Tambahkan opsi yang 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 diperbarui. Gunakan opsi override untuk mendefinisikan 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 diperbarui dimulai sebelum APEX diaktifkan, mulainya akan ditunda hingga aktivasi APEX selesai.

Mengonfigurasi sistem untuk mendukung pembaruan APEX

Atur 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 mungkin untuk memperbarui kernel lama untuk mendukung APEX sepenuhnya. Misalnya, kernel mungkin dibuat tanpa CONFIG_BLK_DEV_LOOP=Y , yang sangat penting untuk memasang citra sistem file di dalam APEX.

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

Mengaktifkan APEX yang diratakan tidak melibatkan perangkat loop. Seluruh direktori /system/apex/my.apex secara langsung diikat ke /apex/name@ver .

APEX yang diratakan tidak dapat diperbarui dengan mengunduh versi APEX yang diperbarui dari jaringan karena APEX yang diunduh tidak dapat diratakan. APEX yang diratakan hanya dapat diperbarui melalui OTA biasa.

APEX yang diratakan adalah konfigurasi default. Ini berarti bahwa semua APEX secara default diratakan kecuali Anda secara eksplisit mengonfigurasi perangkat Anda untuk membuat APEX yang tidak diratakan untuk mendukung pembaruan APEX (seperti yang dijelaskan di atas).

Mencampur APEX yang rata dan tidak rata dalam perangkat TIDAK didukung. APEX dalam perangkat harus semuanya tidak rata atau semuanya rata. Hal ini sangat penting saat mengirimkan pra-penandatanganan APEX prebuilt untuk proyek seperti Mainline. APEX yang tidak ditentukan sebelumnya (yaitu, dibuat dari sumbernya) juga harus tidak diratakan dan ditandatangani dengan kunci yang tepat. Perangkat harus mewarisi dari updatable_apex.mk seperti yang dijelaskan dalam Memperbarui layanan dengan APEX .

APEX terkompresi

Android 12 dan yang lebih baru menampilkan kompresi APEX untuk mengurangi dampak penyimpanan paket APEX yang dapat diperbarui. Setelah pembaruan ke APEX diinstal, meskipun versi pra-instalnya tidak digunakan lagi, itu masih menempati jumlah ruang yang sama. Ruang yang ditempati itu 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 algoritme kompresi zip DEFLATE.

Kompresi tidak memberikan pengoptimalan untuk hal-hal berikut:

• Bootstrap APEX yang diperlukan untuk dipasang sangat awal dalam urutan boot.

• APEX yang tidak dapat diperbarui. Kompresi hanya bermanfaat jika versi terbaru dari APEX diinstal pada partisi /data . Daftar lengkap APEX yang dapat diperbarui tersedia di halaman Komponen Sistem Modular .

• APEX lib bersama dinamis. Karena apexd selalu mengaktifkan kedua versi APEX tersebut (pra-instal dan upgrade), mengompresinya tidak menambah nilai.

Format file APEX terkompresi

Ini adalah format file APEX terkompresi.

Gambar 2. Format file APEX terkompresi

Di tingkat atas, file APEX terkompresi adalah file zip yang berisi file apex asli dalam bentuk kempis dengan tingkat kompresi 9, dan dengan file lain yang disimpan tidak terkompresi.

Empat file terdiri dari file APEX:

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

File apex_manifest.pb , AndroidManifest.xml , dan apex_pubkey adalah salinan dari file terkait di original_apex .

Membangun APEX terkompresi

APEX terkompresi dapat dibangun menggunakan alat apex_compression_tool.py yang terletak di system/apex/tools .

Catatan: Wadah apk luar dari file APEX terkompresi yang dihasilkan tidak ditandatangani secara otomatis. Anda harus menandatanganinya secara manual, dan menggunakan sertifikat yang benar. Lihat Menandatangani Build untuk Rilis .

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

Di Android.bp apakah file APEX dapat dikompresi dikendalikan oleh properti yang dapat compressible :

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

Catatan: Ini berfungsi untuk memberi sinyal ke sistem build bahwa APEX ini dapat dikompresi. Ini diperlukan karena tidak semua APEX dapat dikompresi, seperti yang disebutkan di bagian APEX Terkompresi .

Bendera produk PRODUCT_COMPRESSED_APEX mengontrol apakah citra sistem yang dibuat dari sumber harus berisi file APEX terkompresi.

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

File APEX terkompresi yang dihasilkan oleh sistem build memiliki ekstensi .capex . Ekstensi membuatnya lebih mudah untuk membedakan antara versi terkompresi dan tidak terkompresi dari file APEX.

Algoritma kompresi yang didukung

Android 12 hanya mendukung kompresi deflate-zip.

Mengaktifkan file APEX terkompresi saat boot

Sebelum APEX terkompresi dapat diaktifkan, file original_apex di dalamnya didekompresi ke direktori /data/apex/decompressed . Hasil dekompresi file APEX ditautkan ke direktori /data/apex/active .

Catatan: Karena file APEX yang didekompresi ditautkan ke direktori /data/apex/active , file di bawah /data/apex/decompressed harus memiliki label SELinux yang sama dengan file di bawah direktori /data/apex/active .

Perhatikan contoh berikut sebagai ilustrasi dari 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/[e-mail] .
2. restorecon /data/apex/decompressed/[e-mail] dilakukan untuk memverifikasi bahwa ia memiliki label SELinux yang benar.
3. Pemeriksaan verifikasi dilakukan di /data/apex/decompressed/[e-mail] untuk memastikan validitasnya: apexd memeriksa kunci publik yang dibundel dalam /data/apex/decompressed/[e-mail] ke verifikasi bahwa itu sama dengan yang dibundel di /system/apex/com.android.foo.capex .
4. File /data/apex/decompressed/[e-mail] ditautkan ke direktori /data/apex/active/[e-mail] .
5. Logika aktivasi reguler untuk file APEX yang tidak terkompresi dilakukan di /data/apex/active/[e-mail] .

Interaksi dengan OTA

File APEX terkompresi memiliki implikasi pada pengiriman dan aplikasi OTA. Karena pembaruan OTA mungkin berisi file APEX terkompresi dengan tingkat versi yang lebih tinggi daripada yang aktif di perangkat, sejumlah ruang kosong harus dicadangkan sebelum perangkat di-boot ulang untuk menerapkan pembaruan OTA.

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

• calculateSizeForCompressedApex - menghitung ukuran yang diperlukan untuk mendekompresi file APEX dalam paket OTA. Ini dapat digunakan untuk memverifikasi bahwa perangkat memiliki cukup ruang sebelum OTA diunduh.
• reserveSpaceForCompressedApex - cadangan ruang pada disk untuk digunakan di masa mendatang oleh apexd untuk mendekompresi file APEX terkompresi di dalam paket OTA.

Dalam kasus pembaruan OTA A/B, apexd mencoba dekompresi di latar belakang sebagai bagian dari rutinitas OTA pasca pemasangan. Jika dekompresi gagal, apexd melakukan dekompresi selama boot yang menerapkan pembaruan OTA.

Alternatif dipertimbangkan saat mengembangkan APEX

Berikut adalah beberapa opsi yang dipertimbangkan AOSP saat merancang format file APEX, dan mengapa mereka disertakan atau dikecualikan.

Sistem manajemen paket reguler

Distribusi Linux memiliki sistem manajemen paket seperti dpkg dan rpm , yang kuat, matang, dan tangguh. Namun, mereka tidak diadopsi untuk APEX karena mereka tidak dapat melindungi paket setelah instalasi. Verifikasi dilakukan hanya ketika paket sedang diinstal. Penyerang dapat merusak integritas paket yang diinstal, tanpa disadari. Ini adalah regresi untuk Android di mana semua komponen sistem disimpan dalam sistem file hanya-baca yang integritasnya dilindungi oleh dm-verity untuk setiap I/O. Setiap gangguan pada komponen sistem harus dilarang, atau dapat dideteksi sehingga perangkat dapat menolak untuk melakukan booting jika disusupi.

dm-crypt untuk integritas

File dalam wadah APEX berasal dari partisi bawaan (misalnya, partisi /system ) yang dilindungi oleh dm-verity, di mana modifikasi apa pun pada file dilarang bahkan setelah partisi dipasang. Untuk memberikan tingkat keamanan yang sama ke file, semua file dalam APEX disimpan dalam gambar sistem file yang dipasangkan dengan pohon hash dan deskriptor vbmeta. Tanpa dm-verity, APEX di partisi /data rentan terhadap modifikasi yang tidak diinginkan yang dibuat setelah diverifikasi dan diinstal.

Bahkan, partisi /data juga dilindungi oleh lapisan enkripsi seperti dm-crypt. Meskipun ini memberikan beberapa tingkat perlindungan terhadap gangguan, tujuan utamanya adalah privasi, bukan integritas. Ketika penyerang memperoleh akses ke partisi /data , tidak ada perlindungan lebih lanjut, dan ini lagi-lagi merupakan regresi dibandingkan dengan setiap komponen sistem yang ada di partisi /system . Pohon hash di dalam file APEX bersama dengan dm-verity memberikan tingkat perlindungan konten yang sama.

Mengarahkan jalur dari /sistem ke /apex

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

Meskipun salah satu cara untuk menghindari perubahan jalur adalah dengan melapisi konten file dalam file APEX ke partisi /system , tim Android memutuskan untuk tidak melapisi file pada partisi /system karena ini dapat memengaruhi kinerja karena jumlah file yang di-overlay ( bahkan mungkin ditumpuk satu demi satu) meningkat.

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