Google sedang mengerjakan APEX: memperbarui perpustakaan sistem seperti distro Linux standar. Diharapkan di Android Q, APEX mungkin menjadi yang terbesar sejak Project Treble.
Penerapan APEX mungkin merupakan masalah terbesar yang dihadapi Google sejak diperkenalkannya Project Treble. Apa itu APEX dan bagaimana pengenalannya akan mengubah Android?
Ide di balik APEX sendiri cukup umum dalam distribusi GNU/Linux sehari-hari: pembaruan paket menargetkan bagian tertentu dari kumpulan perpustakaan Linux. Tapi itu adalah sesuatu yang Google tidak pernah coba lakukan mengingat Android telah menggunakan partisi RO (read-only) di mana semua perpustakaan sistem dan kerangka kerja disimpan versus partisi RW (baca-tulis) yang biasa digunakan di sebagian besar distribusi Linux, menjadikan proses peningkatan standar tidak cocok.
Perpustakaan adalah kode yang telah dikompilasi sebelumnya dan dapat digunakan di program lain. Metode yang umum digunakan dapat dijadikan pustaka untuk dipanggil oleh aplikasi Android, sehingga mengurangi ukuran APK karena kode yang sama tidak perlu diimplementasikan ulang di beberapa aplikasi. Anda dapat menemukan banyak perpustakaan sistem pra-instal di direktori /system/lib dan /system/lib64. Pustaka sistem Android biasanya tidak diperbarui satu per satu—melainkan, pustaka tersebut diperbarui sebagai bagian dari peningkatan platform Android melalui pembaruan OTA. Di sisi lain, perpustakaan di distro Linux dapat diperbarui satu per satu. Dengan diperkenalkannya APEX, perpustakaan sistem di Android dapat diperbarui secara individual seperti aplikasi Android. Manfaat utama dari hal ini adalah pengembang aplikasi akan dapat memanfaatkan perpustakaan yang diperbarui tanpa menunggu OEM meluncurkan pemutakhiran sistem secara penuh. Mari selami lebih banyak detail teknis tentang cara kerja APEX.
Bagaimana APEX mengubah cara perpustakaan diperbarui?
APEX adalah ekosistem yang memaksa (atau lebih tepatnya, memaksa) Google untuk mempertimbangkan kembali cara Android memuat semua perpustakaan dan file dari partisi non-standar yang berbeda dari /sistem.
Pertama-tama, kita harus menentukan perbedaan antara perpustakaan bersama dan perpustakaan statis. Pustaka bersama adalah pustaka (biasanya file bernama libkind.so) yang tidak menyertakan semua kode yang diperlukan untuk menjalankannya sendiri tetapi sebenarnya “terhubung” ke pustaka lain menyediakan kode, sedangkan perpustakaan statis, seperti yang bisa Anda tebak, adalah perpustakaan yang tidak bergantung pada perpustakaan lain dan semuanya disertakan secara statis di dalam mengajukan.
Android secara historis telah mengonfigurasi jalur perpustakaan (dikenal sebagai LD_LIBRARY_PATH di dunia Linux) dengan satu file disebut ld.config.txt [0] untuk mengonfigurasi jalur pencarian yang diizinkan untuk perpustakaan bersama yang diperlukan baik biner atau lainnya perpustakaan. Jalur ini dikodekan secara hardcode dalam konfigurasi dan tidak dapat diperluas. Tata letak ini, termasuk partisi sistem read-only, menyebabkan perpustakaan tidak dapat diupdate kecuali pengguna menginstal pembaruan Android OTA. Google memperbaiki masalah ini sehingga memungkinkan untuk memperluas jalur pencarian dengan membiarkan paket APEX tunggal menyediakan ld.config.txt mereka sendiri yang menyertakan jalur perpustakaan tambahan (dan diperbarui) yang terkandung di dalamnya.
Meskipun langkah ini telah menyelesaikan salah satu masalah utama, masih ada beberapa masalah serius yang harus diatasi. Pertama-tama: stabilitas ABI (antarmuka biner aplikasi). Perpustakaan harus selalu mengekspor serangkaian antarmuka yang stabil untuk memungkinkan aplikasi dan perpustakaan lain terus bekerja dengan protokol yang sama bahkan dengan perpustakaan yang ditingkatkan. Google secara aktif mengerjakannya dengan mencoba membuat antarmuka C yang stabil antara perpustakaan APEX.
Namun APEX tidak terbatas pada perpustakaan dan biner saja. Faktanya, ini dapat berisi file konfigurasi, pembaruan zona waktu, dan beberapa kerangka kerja Java (dikonskripsi pada saat penulisan).
Berikut adalah beberapa contoh paket APEX saat ini yang disediakan oleh AOSP:
- com.android.runtime: ART dan bionic runtime (biner dan perpustakaan)
- com.android.tzdata: Data TimeZone dan ICU (perpustakaan dan data konfigurasi)
- com.Android.resolv: Perpustakaan yang digunakan oleh Android untuk menyelesaikan permintaan terkait jaringan (perpustakaan)
- com.android.conscrypt: Penyedia Keamanan Java (kerangka Java)
Bagaimana paket APEX diinstal dan disusun?
Paket APEX adalah arsip zip sederhana (seperti APK) yang dapat diinstal oleh ADB kami yang praktis (saat ini dalam pengembangan) dan, nantinya, oleh pengguna sendiri melalui pengelola paket (seperti Google Play atau secara manual melalui paket Android pemasang).
Tata letak ZIP adalah sebagai berikut:
Mari selami hal itu.
apex_manifest.json menentukan nama paket dan versinya.
apex_payload.img adalah image sistem file mikro (diformat sebagai EXT4).
File lainnya adalah bagian dari proses verifikasi yang digunakan untuk menginstal paket. Mari kita lihat.
Kehadiran dari AndroidManifest.xml, meskipun digunakan terutama dalam aplikasi, membantu kita memahami bahwa sebagian besar implementasi yang digunakan untuk instalasi APK standar digunakan kembali bahkan untuk paket-paket ini. Faktanya, hanya ekstensi yang diperiksa untuk membedakannya.
Itu META-INF/ direktori memiliki sertifikat paket dan menggunakan mekanisme yang sama seperti APK biasa. Jadi paket-paket ini diverifikasi oleh pasangan kunci pribadi/publik pada waktu proses sebelum pengguna diizinkan untuk menginstal pembaruan. Namun itu tidak cukup bagi Google, jadi mereka menambahkan 2 lapisan keamanan lagi. Mereka menggunakan dm-verity untuk memeriksa integritas gambar dan verifikasi AVB (Android Verified Boot) untuk memastikan gambar berasal dari sumber tepercaya. Dalam skenario terburuk, paket APEX akan ditolak.
Jika semua langkah verifikasi berhasil, gambar akan ditandai sebagai valid dan akan menggantikan varian sistem pada reboot berikutnya.
Bagaimana cara menginstal gambar saat boot?
Mari kita mulai dengan melihat APEX yang saat ini terinstal di perangkat saya (emulator)
Seperti yang Anda lihat, paket pra-instal disimpan di /system/apex/ dan semuanya saat ini berada pada versi nomor 1. Namun apa yang terjadi jika APEX diaktifkan? Kami akan kembali menggunakan com.android.tzdata sebagai contoh.
Mari kita reboot perangkat dan menganalisis logcat.
Dua baris pertama memberikan informasi yang cukup untuk memahami asal paket dan di mana tujuannya diinstal: /apex/, direktori baru yang diperkenalkan di Android Q yang akan digunakan untuk menyimpan file yang diaktifkan paket.
Setelah paket berhasil diverifikasi dengan AVB dan kunci publiknya cocok, APEX dipasang menggunakan perangkat loop ke /dev/block/loop0, membuat sistem file EXT4 dapat diakses oleh sistem. Perangkat loop adalah perangkat semu yang membuat file dapat diakses sebagai perangkat blok, membuat konten file tersebut dapat diakses sebagai titik pemasangan.
Pada titik ini, APEX masih belum digunakan karena akhiran @1 (yang menunjukkan versi paket). Untuk akhirnya memberi tahu sistem bahwa paket kami telah berhasil diaktifkan, paket tersebut akan diikat ke /apex/com.android.tzdata tempat Android secara aktif mengharapkan tzdata untuk aktif. Bind mount melapisi direktori atau file yang ada di bawah titik yang berbeda. [1]
Implementasi APEX seluruhnya terdapat dalam satu repositori di bawah AOSP. [2] Direktori apexd (APEX daemon) memiliki kode yang berjalan di Android. Direktori apexer memiliki kode yang digunakan oleh sistem build untuk membuat paket APEX.
Apa tujuannya?
Saat ini, yang bisa saya lakukan hanyalah berspekulasi. Tebakan terbaik saya adalah bahwa Google sedang mencoba membuat kumpulan inti paket APEX yang dapat diperbarui oleh Google agar dapat dibuat inti dasar terpadu Android yang dibagikan antar vendor, membuat pembaruan hanya “sistem” yang mungkin dilakukan, tetapi menggunakan paket tunggal pembaruan.
Apakah semua perangkat akan mendukung APEX?
Tidak. Misalnya, apexd mengharuskan /data/apex tersedia segera setelah boot untuk memperbarui semua modul Android. Dengan FDE (Enkripsi Disk Penuh), /data/apex dienkripsi hingga perangkat dibuka kuncinya oleh pengguna, menjadikan APEX pada dasarnya tidak berguna karena hanya varian sistem APEX yang akan dimuat saat boot. Selain itu, semua perangkat harus mendukung APEX, namun memerlukan beberapa patch kernel (banyak di antaranya merupakan perbaikan yang ditemukan oleh Google saat bermain dengan perangkat loop). [3] [4]
Sumber [0], [1], [2], [3], [4]