Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Format File APEXEX

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 contoh komponen layanan asli dan perpustakaan, 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.

Desain

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

Untuk informasi lebih lanjut tentang mengapa desain ini untuk APEX terpilih, lihat Alternatif dipertimbangkan ketika mengembangkan APEX .

format APEX

Ini adalah format file APEX.

format file APEX

Format file Gambar 1. 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

The apex_manifest.json file berisi nama paket dan versi, yang mengidentifikasi file APEX.

The AndroidManifest.xml berkas memungkinkan file APEX untuk penggunaan alat-alat terkait APK-dan infrastruktur seperti ADB, PackageManager, dan aplikasi paket installer (seperti Play Store). Sebagai contoh, file APEX dapat menggunakan alat yang 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 dianjurkan lebih AndroidManifest.xml untuk kode baru dan sistem yang berhubungan dengan APEX. AndroidManifest.xml mungkin berisi informasi penargetan tambahan yang dapat digunakan oleh alat publikasi aplikasi yang sudah ada.

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

apex_pubkey adalah kunci publik yang digunakan untuk menandatangani sistem file gambar. 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 bertanggung jawab untuk memverifikasi, menginstal, dan menghapus file APEX. Proses ini diluncurkan dan siap di awal urutan boot. File APEX biasanya pra-instal pada perangkat di bawah /system/apex . Manajer APEX default untuk menggunakan paket-paket ini jika tidak ada pembaruan yang tersedia.

Update urutan 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. Tunggangan perangkat blok perangkat mapper ke jalur yang 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 valid karena mereka masuk zip arsip (menggunakan skema tanda tangan APK) mengandung AndroidManifest.xml berkas. Ini memungkinkan file APEX menggunakan infrastruktur untuk file APK, seperti aplikasi penginstal paket, utilitas penandatanganan, dan pengelola paket.

The AndroidManifest.xml file di file APEX minimal, yang terdiri dari paket name , versionCode , dan opsional targetSdkVersion , minSdkVersion , dan maxSdkVersion untuk fine-grained penargetan. 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, apex_payload.img (khusus, deskriptor vbmeta ditambahkan ke apex_payload.img ) file yang 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 terletak di built-in partisi seperti /system . Partisi sudah melebihi dm-verity, jadi file APEX dipasang langsung melalui perangkat loopback.

Jika APEX ada 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 dalam /data dan, mirip dengan APK, yang baru diinstal versi bayangan versi sudah ada di partisi built-in. 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, turun-gabungan dari android-4.4 cabang sangat dianjurkan. Berikut ini adalah daftar patch individual yang diperlukan untuk kernel versi 4.4.

  • HULU: lingkaran: menambahkan ioctl untuk mengubah ukuran blok logis ( 4.4 )
  • Backport: block / lingkaran: set hw_sectors ( 4.4 )
  • HULU: lingkaran: Tambah LOOP_SET_BLOCK_SIZE di ioctl compat ( 4.4 )
  • ANDROID: mnt: Fix next_descendent ( 4.4 )
  • ANDROID: mnt: remount harus merambat ke budak budak ( 4.4 )
  • ANDROID: mnt: Menyebarkan remount benar ( 4.4 )
  • Kembalikan "ANDROID: dm kejujuran: menambahkan ukuran prefetch minimum" ( 4.4 )
  • HULU: lingkaran: penurunan cache jika offset atau block_size berubah ( 4.4 )

Versi kernel 4.9/4.14/4.19

Untuk mendapatkan patch yang diperlukan untuk versi kernel 4.9 / 4.14 / 4.19, turun-merge dari android-common cabang.

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 set
  • loop.max_part harus <= 8

Membangun APEX

Bagian ini menjelaskan cara membangun APEX menggunakan sistem pembangunan Android. Berikut ini adalah contoh dari 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",
}

apex_manifest.json contoh:

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

file_contexts contoh:

(/.*)?           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 diterjemahkan dalam x86)
executable /bin
perpustakaan Java /javalib
Prebuilt /etc

Ketergantungan transitif

File APEX secara otomatis menyertakan dependensi transitif dari lib bersama asli atau yang dapat dieksekusi. Sebagai contoh, jika libFoo tergantung pada libBar , dua libs termasuk ketika hanya libFoo tercantum dalam native_shared_libs properti.

Menangani beberapa ABI

Instal native_shared_libs properti untuk kedua antarmuka aplikasi biner primer dan sekunder (ABI) dari 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 binaries properti hanya untuk ABI utama perangkat seperti 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 fine-grained atas ABI perpustakaan asli dan binari, gunakan multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] properti.

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

The java , libraries , dan prebuilts sifat yang ABI-agnostik.

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. Ketika kunci baru diperlukan, menciptakan sepasang kunci publik-swasta dan membuat apex_key modul. Gunakan key properti untuk menandatangani APEX menggunakan kunci. Kunci publik secara otomatis termasuk 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. Pada saat runtime, apexd memverifikasi APEX menggunakan kunci publik dengan ID yang sama di perangkat.

Penandatanganan ZIP

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

Untuk menandatangani APEX di file-level, mengatur certificate properti di salah satu dari tiga cara:

  • Tidak diatur: Jika tidak ada nilai yang ditetapkan, APEX ditandatangani dengan sertifikat yang terletak di PRODUCT_DEFAULT_DEV_CERTIFICATE . Jika tidak ada bendera diatur, default path untuk build/target/product/security/testkey .
  • <name> : The APEX ditandatangani dengan <name> sertifikat dalam direktori yang sama seperti PRODUCT_DEFAULT_DEV_CERTIFICATE .
  • :<name> : The 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)
}

Memasang APEX

Untuk menginstal APEX, gunakan ADB.

adb install apex_file_name
adb reboot

Menggunakan APEX

Setelah reboot, APEX dipasang di /apex/<apex_name>@<version> direktori. Beberapa versi dari APEX yang sama dapat dipasang pada waktu yang sama. Di antara gunung jalur, salah satu yang berkorespondensi ke versi terbaru adalah mengikat-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 preloads APEX bawah /system/apex bila perangkat dikirimkan.
  2. File di APEX diakses melalui /apex/<apex_name>/ path.
  3. Ketika versi terbaru dari APEX dipasang di /data/apex , jalan poin ke APEX baru setelah reboot.

Memperbarui layanan dengan APEX

Untuk memperbarui layanan menggunakan APEX:

  1. Tandai layanan di partisi sistem sebagai dapat diperbarui. Tambahkan pilihan yang updatable dengan definisi layanan.

    /system/etc/init/myservice.rc:
    
    service myservice /system/bin/myservice
        class core
        user system
        ...
        updatable
    
  2. Buat baru .rc file untuk layanan diperbarui. Gunakan override pilihan untuk mendefinisikan kembali layanan yang ada.

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

Definisi layanan hanya dapat didefinisikan dalam .rc file 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

Mengatur properti sistem berikut untuk true mendukung file update 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. Sebagai contoh, kernel mungkin telah dibangun tanpa CONFIG_BLK_DEV_LOOP=Y , yang sangat penting untuk mounting sistem file gambar dalam sebuah 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 pipih APEX my.apex dipasang untuk /system/apex/my.apex/lib/libFoo.so .

Mengaktifkan APEX yang diratakan tidak melibatkan perangkat loop. Seluruh direktori /system/apex/my.apex langsung mengikat-mount 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. Ini sangat penting saat mengirimkan pra-penandatanganan APEX prebuilt untuk proyek seperti Mainline. APEX yang tidak ditentukan 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 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 satu set yang sangat dikompresi file APEX pada partisi read-only (seperti /system partisi). 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 ini hanya bermanfaat jika versi terbaru dari APEX diinstal pada /data partisi. Daftar lengkap apexes diupdate tersedia pada Modular Sistem Komponen halaman.

  • APEX lib bersama dinamis. Sejak apexd selalu mengaktifkan kedua versi apexes seperti (pra-instal dan upgrade), mengompresi mereka tidak menambah nilai.

Format file APEX terkompresi

Ini adalah format file APEX terkompresi.

Diagram shows the format of a compressed APEX file

Format file gambar 2. Compressed APEX

Di tingkat atas, file APEX terkompresi adalah file zip yang berisi file apex asli dalam bentuk kempes 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 asli, terkompresi berkas APEX .
  • apex_manifest.pb : disimpan hanya
  • AndroidManifest.xml : disimpan hanya
  • apex_pubkey : disimpan hanya

The apex_manifest.pb , AndroidManifest.xml , dan apex_pubkey file salinan yang sesuai file mereka di original_apex .

Membangun APEX terkompresi

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

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

Dalam Android.bp apakah file APEX adalah kompresibel dikendalikan oleh compressible properti:

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

Sebuah PRODUCT_COMPRESSED_APEX pengendalian produk bendera apakah gambar sistem dibangun dari sumber harus berisi file terkompresi APEX.

Untuk eksperimen lokal Anda dapat memaksa membangun untuk apexes kompres dengan menetapkan OVERRIDE_PRODUCT_COMPRESSED_APEX= untuk true .

Compressed APEX file yang dihasilkan oleh sistem build memiliki .capex ekstensi. 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, original_apex berkas di dalamnya yang didekompresi ke dalam /data/apex/decompressed direktori. Dihasilkan didekompresi file APEX adalah hard-terkait dengan /data/apex/active direktori.

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. The original_apex file di /system/apex/com.android.foo.capex didekompresi ke /data/apex/decompressed/com.android.foo@37.apex .
  2. restorecon /data/apex/decompressed/com.android.foo@37.apex dilakukan untuk memverifikasi bahwa ia memiliki label SELinux yang benar.
  3. Verifikasi pemeriksaan yang dilakukan pada /data/apex/decompressed/com.android.foo@37.apex untuk memastikan validitasnya: apexd cek kunci publik dibundel dalam /data/apex/decompressed/com.android.foo@37.apex ke memverifikasi bahwa itu sama dengan satu paket di /system/apex/com.android.foo.capex .
  4. The /data/apex/decompressed/com.android.foo@37.apex file keras terkait dengan /data/apex/active/com.android.foo@37.apex direktori.
  5. Logika aktivasi biasa untuk file APEX terkompresi dilakukan pada /data/apex/active/com.android.foo@37.apex .

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 menghadapkan dua API pengikat ini:

  • calculateSizeForCompressedApex - menghitung ukuran yang dibutuhkan untuk dekompresi 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 depan dengan apexd untuk dekompresi file APEX dikompresi dalam paket OTA.

Dalam kasus update A / B OTA, apexd upaya dekompresi di latar belakang sebagai bagian dari postinstall OTA rutin. Jika dekompresi gagal, apexd Melakukan dekompresi selama boot yang berlaku update OTA.

Alternatif dipertimbangkan saat mengembangkan APEX

Berikut adalah beberapa opsi yang dipertimbangkan AOSP saat mendesain 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 kuat. 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-file dalam wadah APEX berasal dari built-in partisi (misalnya, /system partisi) yang dilindungi oleh dm-kejujuran, di mana ada modifikasi pada file dilarang bahkan setelah partisi yang 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-kejujuran, APEX dalam /data partisi rentan terhadap modifikasi yang tidak diinginkan yang dibuat setelah itu sudah diverifikasi dan diinstal.

Bahkan, /data partisi juga dilindungi oleh lapisan enkripsi seperti dm-crypt. Meskipun ini memberikan beberapa tingkat perlindungan terhadap gangguan, tujuan utamanya adalah privasi, bukan integritas. Ketika keuntungan penyerang akses ke /data partisi, tidak ada perlindungan lebih lanjut, dan ini lagi adalah regresi dibandingkan dengan setiap komponen sistem berada di /system partisi. 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 dikemas dalam APEX dapat diakses melalui jalur baru seperti /apex/<name>/lib/libfoo.so . Ketika file adalah bagian dari /system partisi, mereka 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 sebagai akibat dari perubahan jalur.

Meskipun salah satu cara untuk menghindari perubahan jalur ini untuk overlay isi file dalam file APEX ke /system partisi, tim Android memutuskan untuk tidak file overlay pada /system partisi karena ini bisa mempengaruhi kinerja sebagai jumlah file yang overlayed ( bahkan mungkin ditumpuk satu demi satu) meningkat.

Pilihan lain adalah untuk membajak fungsi akses file seperti open , stat , dan readlink , sehingga jalur yang dimulai dengan /system yang diarahkan ke jalur yang sesuai mereka 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.