APEX Dosya Biçimi

Android Pony EXpress (APEX) kapsayıcı biçimi, Android 10'da tanıtıldı ve alt düzey sistem modülleri için yükleme akışında kullanıldı. Bu biçim, standart Android uygulama modeline uymayan sistem bileşenlerinin güncellemelerini kolaylaştırır. Bazı örnek parçaları yerli hizmet ve kütüphane, donanım özet tabakalar (vardır HAL'lere ), çalışma zamanı ( ART ), ve sınıf kütüphaneleri.

"APEX" terimi ayrıca bir APEX dosyasına atıfta bulunabilir.

Arka plan

Android, paket yükleyici uygulamaları (Google Play Store uygulaması gibi) aracılığıyla standart uygulama modeline (örneğin hizmetler, etkinlikler) uyan modüllerin güncellemelerini desteklese de, daha düşük düzeyli işletim sistemi bileşenleri için benzer bir model kullanmanın aşağıdaki dezavantajları vardır:

  • APK tabanlı modüller, önyükleme sırasında erken kullanılamaz. Paket yöneticisi, uygulamalar hakkında merkezi bilgi deposudur ve yalnızca, önyükleme prosedürünün sonraki bir aşamasında hazır hale gelen etkinlik yöneticisinden başlatılabilir.
  • APK formatı (özellikle manifesto), Android uygulamaları için tasarlanmıştır ve sistem modülleri her zaman uygun değildir.

Tasarım

Bu bölüm, APEX dosya formatının üst düzey tasarımını ve APEX dosyalarını yöneten bir hizmet olan APEX yöneticisini açıklar.

APEX için bu tasarım seçilmiş nedeniyle ilgili daha fazla bilgi için, bkz Alternatifleri APEX geliştirirken dikkate .

APEX formatı

Bu, bir APEX dosyasının biçimidir.

APEX dosya biçimi

Şekil 1. APEX dosya biçimi

En üst düzeyde, bir APEX dosyası, dosyaların sıkıştırılmamış olarak depolandığı ve 4 KB sınırlarında yer aldığı bir zip dosyasıdır.

Bir APEX dosyasındaki dört dosya şunlardır:

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

apex_manifest.json dosyası bir APEX dosyayı tanımlamak paket adını ve sürümünü içerir.

AndroidManifest.xml dosya kullanımı APK-ilgili araç ve böyle ADB, PackageManager olarak altyapısı ve (örneğin Play Store'dan gibi) paket yükleyicisi uygulamalara APEX dosyasını sağlar. Örneğin, APEX dosyası gibi varolan aracını kullanabilirsiniz aapt dosyadan temel meta verileri incelemek için. Dosya, paket adı ve sürüm bilgilerini içerir. Bu bilgiler ayrıca, genel olarak mevcuttur apex_manifest.json .

apex_manifest.json üzerinde önerilir AndroidManifest.xml yeni kodu ve APEX başa sistemler için. AndroidManifest.xml mevcut uygulama yayınlama araçları tarafından kullanılabilecek ek hedefleme bilgileri yer alabilir.

apex_payload.img dm-verity da desteklediği bir ext4 dosya sistemi resimdir. Görüntü, bir geri döngü aygıtı aracılığıyla çalışma zamanında monte edilir. Özellikle, karma ağaç ve meta veri bloğu kullanılarak oluşturulur libavb kütüphanesi. Dosya sistemi yükü ayrıştırılmaz (çünkü görüntünün yerine monte edilebilir olması gerekir). Düzenli dosyaları içine dahil edilmiştir apex_payload.img dosyası.

apex_pubkey dosya sistemi görüntüsü imzalamak için kullanılan kamu anahtarıdır. Çalışma zamanında, bu anahtar, indirilen APEX'in yerleşik bölümlerde aynı APEX'i imzalayan aynı varlıkla imzalanmasını sağlar.

APEX yöneticisi

APEX yöneticisi (veya apexd ) APEX dosyaları Doğrulama, yükleme ve kaldırma sorumlu bağımsız bir yerli bir süreçtir. Bu işlem başlatılır ve önyükleme sırasında erkenden hazırdır. APEX dosyaları normalde altında cihazda önceden yüklenmiş olan /system/apex . APEX yöneticisi, güncelleme yoksa varsayılan olarak bu paketleri kullanır.

Bir APEX'in güncelleştirme sıra kullanan PackageManager sınıfı ve aşağıdaki gibidir.

  1. Bir APEX dosyası, bir paket yükleyici uygulaması, ADB veya başka bir kaynak aracılığıyla indirilir.
  2. Paket yöneticisi kurulum prosedürünü başlatır. Dosyanın bir APEX olduğunu anladıktan sonra, paket yöneticisi kontrolü APEX yöneticisine aktarır.
  3. APEX yöneticisi APEX dosyasını doğrular.
  4. APEX dosyası doğrulanırsa, APEX yöneticisinin dahili veritabanı, APEX dosyasının bir sonraki önyüklemede etkinleştirildiğini yansıtacak şekilde güncellenir.
  5. Yükleme isteğinde bulunan kişi, başarılı paket doğrulamasının ardından bir yayın alır.
  6. Kuruluma devam etmek için sistem yeniden başlatılmalıdır.
  7. Bir sonraki önyüklemede, APEX yöneticisi başlar, dahili veritabanını okur ve listelenen her APEX dosyası için aşağıdakileri yapar:

    1. APEX dosyasını doğrular.
    2. APEX dosyasından bir geri döngü aygıtı oluşturur.
    3. Geri döngü cihazının üstünde bir cihaz eşleyici blok cihazı oluşturur.
    4. Tek bir yol üzerine monte edilir aygıt eşleyici blok aygıtı (örneğin, /apex/ name @ ver ).

Dahili veritabanında listelenen tüm APEX dosyaları bağlandığında, APEX yöneticisi diğer sistem bileşenlerinin kurulu APEX dosyaları hakkında bilgi sorgulaması için bir bağlayıcı hizmeti sağlar. Örneğin, diğer sistem bileşenleri, cihazda kurulu APEX dosyalarının listesini sorgulayabilir veya belirli bir APEX'in monte edildiği tam yolu sorgulayabilir, böylece dosyalara erişilebilir.

APEX dosyaları APK dosyalarıdır

Onlar içeren (APK imza şemasını kullanarak) zip arşivleri imzalanan çünkü APEX dosyaları geçerli APK dosyaları AndroidManifest.xml dosyasını. Bu, APEX dosyalarının paket yükleyici uygulaması, imzalama yardımcı programı ve paket yöneticisi gibi APK dosyaları için altyapıyı kullanmasına olanak tanır.

AndroidManifest.xml APEX dosyası içinde dosya paketi oluşan en az bir name , versionCode ve isteğe bağlı targetSdkVersion , minSdkVersion ve maxSdkVersion ince daneli hedefleme için. Bu bilgi, APEX dosyalarının paket yükleyici uygulamaları ve ADB gibi mevcut kanallar aracılığıyla teslim edilmesini sağlar.

Desteklenen dosya türleri

APEX formatı şu dosya türlerini destekler:

  • Yerel paylaşılan kitaplıklar
  • Yerel yürütülebilir dosyalar
  • JAR dosyaları
  • Veri dosyaları
  • Yapılandırma dosyaları

Bu, APEX'in tüm bu dosya türlerini güncelleyebileceği anlamına gelmez. Bir dosya türünün güncellenip güncellenemeyeceği, platforma ve dosya türleri için arayüz tanımlarının ne kadar kararlı olduğuna bağlıdır.

imza

APEX dosyaları iki şekilde imzalanır. İlk olarak, apex_payload.img (özellikle, eklenen vbmeta açıklayıcısı apex_payload.img ) dosyası bir anahtarla imzalanır. Ardından, tüm APEX kullanılarak imzalanır APK imza şeması v3 . Bu işlemde iki farklı anahtar kullanılır.

Cihaz tarafında, vbmeta tanımlayıcısını imzalamak için kullanılan özel anahtara karşılık gelen bir genel anahtar kurulur. APEX yöneticisi, yüklenmesi istenen APEX'leri doğrulamak için ortak anahtarı kullanır. Her APEX farklı anahtarlarla imzalanmalıdır ve hem derleme zamanında hem de çalışma zamanında uygulanır.

APEX yerleşik bölümlerde

APEX dosyaları yerleşik bölümleri gibi yer alabilir /system . Bölüm zaten dm-verity'nin üzerindedir, bu nedenle APEX dosyaları doğrudan geri döngü aygıtının üzerine monte edilir.

Yerleşik bir bölümde bir APEX varsa, APEX, aynı paket adına ve sürüm kodundan büyük veya ona eşit bir APEX paketi sağlanarak güncellenebilir. Yeni APEX saklanır /data APK'lerinize benzer ve yerleşik bölüm zaten mevcut yeni yüklenen versiyon gölgeler sürümü. Ancak APK'ların aksine, APEX'in yeni yüklenen sürümü yalnızca yeniden başlatıldıktan sonra etkinleştirilir.

Çekirdek gereksinimleri

Bir Android cihazda APEX ana hat modüllerini desteklemek için aşağıdaki Linux çekirdeği özellikleri gereklidir: geri döngü sürücüsü ve dm-verity. Geri döngü sürücüsü, dosya sistemi görüntüsünü bir APEX modülüne bağlar ve dm-verity, APEX modülünü doğrular.

APEX modüllerini kullanırken iyi bir sistem performansı elde etmek için geri döngü sürücüsünün ve dm-verity'nin performansı önemlidir.

Desteklenen çekirdek sürümleri

APEX ana hat modülleri, 4.4 veya üzeri çekirdek sürümleri kullanan cihazlarda desteklenir. Android 10 veya üzeri ile piyasaya sürülen yeni cihazlar, APEX modüllerini desteklemek için çekirdek sürüm 4.9 veya üzerini kullanmalıdır.

Gerekli çekirdek yamaları

APEX modüllerini desteklemek için gerekli çekirdek yamaları Android ortak ağacında bulunur. Yamaların APEX'i desteklemesini sağlamak için Android ortak ağacının en son sürümünü kullanın.

Çekirdek sürümü 4.4

Bu sürüm yalnızca Android 9'dan Android 10'a yükseltilen ve APEX modüllerini desteklemek isteyen cihazlar için desteklenir. Gerekli eklenti almak için, bir aşağı-birleştirme android-4.4 dalı şiddetle tavsiye edilir. Aşağıda, çekirdek sürüm 4.4 için gerekli olan tek tek yamaların bir listesi bulunmaktadır.

  • GİRİŞ: döngü: mantıksal blok boyutunu değiştirmek için ioctl ekleyin ( 4.4 )
  • Backport: blok / döngü: set hw_sectors ( 4.4 )
  • UPSTREAM: döngü: compat ioctl Add LOOP_SET_BLOCK_SIZE ( 4.4 )
  • ANDROID: mnt: Düzeltme next_descendent ( 4.4 )
  • ANDROID: mnt: remount köle kölelere yaymak gerekir ( 4.4 )
  • ANDROID: mnt: Yay'ı doğru yeniden monte ( 4.4 )
  • Geri Al "ANDROID: dm verity: Minimum Önalım boyutunun add" ( 4.4 )
  • GİRİŞ: döngü: damla önbelleğe ofset veya block_size (değiştirilir ise 4.4 )

Çekirdek sürümleri 4.9/4.14/4.19

Dan çekirdek sürümleri 4.9 / 4.14 / 4.19, aşağı-birleştirme için gerekli eklenti almak için android-common dalı.

Gerekli çekirdek yapılandırma seçenekleri

Aşağıdaki liste, Android 10'da tanıtılan APEX modüllerini desteklemek için temel yapılandırma gereksinimlerini gösterir. Yıldız (*) içeren öğeler, Android 9 ve daha düşük sürümlerde mevcut gereksinimlerdir.

(*) 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

Çekirdek komut satırı parametre gereksinimleri

APEX'i desteklemek için çekirdek komut satırı parametrelerinin aşağıdaki gereksinimleri karşıladığından emin olun:

  • loop.max_loop seti OLMAMALIDIR
  • loop.max_part olmalıdır <= 8

APEX inşa etmek

Bu bölüm, Android derleme sistemini kullanarak bir APEX'in nasıl oluşturulacağını açıklar. Aşağıdaki örneğidir Android.bp bir APEX adlı için 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 Örnek:

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

file_contexts örnek:

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

APEX'teki dosya türleri ve konumları

Dosya tipi APEX'teki konum
Paylaşılan kitaplıklar /lib ve /lib64 ( /lib/arm x 86 tercüme kolu için)
Yürütülebilir dosyalar /bin
Java kitaplıkları /javalib
önceden oluşturulmuş /etc

Geçişli bağımlılıklar

APEX dosyaları, yerel paylaşılan kitaplıkların veya yürütülebilir dosyaların geçişli bağımlılıklarını otomatik olarak içerir. Örneğin, libFoo bağlıdır libBar sadece iki kütüphaneleri dahildir libFoo listelenen native_shared_libs özelliği.

Birden çok ABI'yi işleme

Yükleme native_shared_libs cihazın hem birincil hem de ikincil bir uygulama ikili arabirimleri (ABI) için özelliği. Bir APEX, tek bir ABI'ye sahip cihazları hedefliyorsa (yani, yalnızca 32 bit veya yalnızca 64 bit), yalnızca ilgili ABI'ye sahip kitaplıklar yüklenir.

Yükleme binaries aşağıda tarif edildiği gibi, sadece cihazın birincil ABI için özellik:

  • Aygıt yalnızca 32 bit ise, ikili programın yalnızca 32 bitlik sürümü kurulur.
  • Aygıt yalnızca 64 bit ise, ikili programın yalnızca 64 bit çeşidi yüklenir.

Yerli kütüphaneler ve ikili dosyaların Abis üzerinde ince taneli Denetim eklemek için kullanın multilib.[first|lib32|lib64|prefer32|both].[native_shared_libs|binaries] özellikleri.

  • first : Cihazın birinci ABI eşleşir. Bu, ikili dosyalar için varsayılandır.
  • lib32 : destekleniyorsa, cihaz, 32-bit, ABI, eşleşir.
  • lib64 : cihazın 64-bit ABI eşleşir desteklenen.
  • prefer32 : destekleniyorsa, cihazın 32 bit ABI eşleşir. 32 bit ABI desteklenmiyorsa 64 bit ABI ile eşleşir.
  • both : Her iki ABI eşleşir. Bu varsayılan olan native_shared_libraries .

java , libraries ve prebuilts özellikleri, ABI-agnostik.

Bu örnek, 32/64'ü destekleyen ve 32'yi tercih etmeyen bir cihaz içindir:

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
        },
    },
}

vbmeta imzalama

Her APEX'i farklı tuşlarla imzalayın. Yeni bir anahtar gerektiğinde, bir kamu-özel anahtar çifti oluşturmak ve bir hale apex_key modülü. Kullanım key tuşunu kullanarak APEX imzalamak için özellik. Genel anahtar otomatik ismi ile APEX dahildir 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",
}

Yukarıdaki örnekte, genel anahtar (adı foo ) anahtarın numarası olur. Bir APEX'i imzalamak için kullanılan anahtarın kimliği APEX'te yazılmıştır. Çalışma zamanında, apexd cihazda aynı kimliğe sahip bir ortak anahtarı kullanılarak doğrular APEX.

posta imzalama

APEX'leri APK'ları imzaladığınız gibi imzalayın. APEX'leri iki kez imzalayın; Mini dosya sistemi (bir kez apex_payload.img dosyası) ve tüm dosya için bir kez.

Dosya düzeyinde bir APEX imzalamak için set certificate bu üç yoldan birini kullanarak özellik:

  • Ayarlanmamış: hiçbir değer ayarlanırsa, APEX bulunan sertifika ile imzalanmış olan PRODUCT_DEFAULT_DEV_CERTIFICATE . Hiçbir bayrak için, yol varsayılan ayarlanırsa build/target/product/security/testkey .
  • <name> : APEX ile imzalanmış <name> aynı dizinde sertifikası PRODUCT_DEFAULT_DEV_CERTIFICATE .
  • :<name> : APEX adlı Soong modülü tarafından tanımlanan sertifika ile imzalanmış <name> . Sertifika modülü aşağıdaki gibi tanımlanabilir.
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)
}

APEX yükleme

Bir APEX kurmak için ADB'yi kullanın.

adb install apex_file_name
adb reboot

APEX kullanma

Yeniden başlatıldıktan sonra, APEX monte edilir /apex/<apex_name>@<version> dizin. Aynı APEX'in birden fazla versiyonu aynı anda monte edilebilir. Monte yolları arasında, son sürüme karşılık olduğuna biri de bağlama monte /apex/<apex_name> .

İstemciler, APEX'ten dosya okumak veya yürütmek için bağlama bağlantılı yolu kullanabilir.

APEX'ler tipik olarak şu şekilde kullanılır:

  1. Bir OEM ve ODM ön yüklemeler APEX altında /system/apex cihaz sevk edildiğinde.
  2. APEX Dosyalar aracılığıyla erişilir /apex/<apex_name>/ yolunda.
  3. APEX güncellenmiş bir sürümü yüklü olduğunda /data/apex yeniden yükleme sonrasında yeni APEX, yol noktaları.

APEX ile bir hizmeti güncelleme

APEX kullanarak bir hizmeti güncellemek için:

  1. Hizmeti sistem bölümünde güncellenebilir olarak işaretleyin. Ekle seçeneğini updatable hizmet tanımına.

    /system/etc/init/myservice.rc:
    
    service myservice /system/bin/myservice
        class core
        user system
        ...
        updatable
    
  2. Yeni oluştur .rc güncellenmiş hizmet için dosyayı. Kullanım override mevcut hizmet yeniden tanımlama seçeneği.

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

Servis tanımları yalnızca tanımlanabilir .rc bir APEX'in dosyası. Eylem tetikleyicileri APEX'lerde desteklenmez.

APEX'ler etkinleştirilmeden önce güncellenebilir olarak işaretlenen bir hizmet başlarsa, başlatma APEX'lerin etkinleştirilmesi tamamlanana kadar ertelenir.

APEX güncellemelerini desteklemek için sistemi yapılandırma

Aşağıdaki sistem özelliğini ayarlayın true APEX dosya güncellemelerini destekleyecek.

<device.mk>:

PRODUCT_PROPERTY_OVERRIDES += ro.apex.updatable=true

BoardConfig.mk:
TARGET_FLATTEN_APEX := false

ya da sadece

<device.mk>:

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

Düzleştirilmiş APEX

Eski cihazlar için, eski çekirdeği APEX'i tam olarak destekleyecek şekilde güncellemek bazen imkansız veya mümkün değildir. Örneğin, çekirdek olmadan inşa edilmiş olabilir CONFIG_BLK_DEV_LOOP=Y bir APEX içindeki dosya sistemi görüntüsü montaj için çok önemlidir.

Flattened APEX, eski bir çekirdeğe sahip cihazlarda etkinleştirilebilen özel olarak oluşturulmuş bir APEX'tir. Düzleştirilmiş bir APEX'teki dosyalar, yerleşik bölümün altındaki bir dizine doğrudan yüklenir. Örneğin, lib/libFoo.so bir duz APEX my.apex yüklenir /system/apex/my.apex/lib/libFoo.so .

Düzleştirilmiş bir APEX'in etkinleştirilmesi, döngü cihazını içermez. Bütün dizin /system/apex/my.apex doğrudan bağlama monte edilir /apex/name@ver .

İndirilen APEX'ler düzleştirilemediğinden, düzleştirilmiş APEX'ler ağdan APEX'lerin güncel sürümleri indirilerek güncellenemez. Düzleştirilmiş APEX'ler yalnızca normal bir OTA aracılığıyla güncellenebilir.

Düzleştirilmiş APEX varsayılan yapılandırmadır. Bu, cihazınızı APEX güncellemelerini desteklemek için (yukarıda açıklandığı gibi) düzleştirilmemiş APEX'ler oluşturacak şekilde açıkça yapılandırmadığınız sürece, tüm APEX'lerin varsayılan olarak düzleştirildiği anlamına gelir.

Bir cihazda düzleştirilmiş ve düzleştirilmemiş APEX'lerin karıştırılması DESTEKLENMEZ. Bir cihazdaki APEX'lerin tümü düzleştirilmemiş veya tümü düzleştirilmiş olmalıdır. Bu, özellikle Mainline gibi projeler için önceden imzalanmış APEX ön kurulumlarını gönderirken önemlidir. Önceden imzalanmamış (yani kaynaktan oluşturulmuş) APEX'ler de düzleştirilmemeli ve uygun anahtarlarla imzalanmalıdır. Cihaz devralan gerektiğini updatable_apex.mk açıklandığı gibi bir APEX ile bir hizmeti güncellenmesi .

Sıkıştırılmış APEX'ler

Android 12 ve sonraki sürümleri, güncellenebilir APEX paketlerinin depolama etkisini azaltmak için APEX sıkıştırma özelliğine sahiptir. Bir APEX güncellemesi yüklendikten sonra, önceden yüklenmiş sürümü artık kullanılmasa da, yine de aynı miktarda yer kaplar. Bu işgal edilen alan kullanılamaz durumda kalır.

APEX sıkıştırma (örneğin, salt okunur bölümleri üzerinde APEX dosyalarının yüksek oranda sıkıştırılmış dizi kullanarak bu depolama etkisini minimize /system bölümü). Android 12 ve sonraki sürümleri bir DEFLATE zip sıkıştırma algoritması kullanır.

Sıkıştırma, aşağıdakiler için optimizasyon sağlamaz:

  • Önyükleme sırasında çok erken monte edilmesi gereken önyükleme APEX'leri.

  • Güncellenemeyen APEX'ler. Bir APEX güncellenmiş bir sürümü yüklüyse Sıkıştırma yalnızca faydalıdır /data bölümü. Güncellenebilir apexes tam listesi mevcuttur Modüler Sistem Bileşenleri sayfa.

  • Dinamik paylaşılan kütüphaneler APEX'ler. Yana apexd hep böyle apexes her iki sürümünü aktive onları değer katmıyor sıkıştırarak, (önceden yüklenmiş ve yükseltilmiş).

Sıkıştırılmış APEX dosya biçimi

Bu, sıkıştırılmış bir APEX dosyasının biçimidir.

Diagram shows the format of a compressed APEX file

Şekil 2. Sıkıştırılmış APEX dosya biçimi

En üst düzeyde, sıkıştırılmış bir APEX dosyası, sıkıştırma düzeyi 9 olan orijinal apex dosyasını sönük biçimde ve sıkıştırılmamış olarak depolanan diğer dosyaları içeren bir zip dosyasıdır.

Dört dosya bir APEX dosyasından oluşur:

  • original_apex : 9 Bu sıkıştırma düzeyi ile sönük orijinal sıkıştırılmamış olan APEX dosyası .
  • apex_manifest.pb : Sadece saklanan
  • AndroidManifest.xml : Sadece saklanan
  • apex_pubkey : Sadece saklanan

apex_manifest.pb , AndroidManifest.xml ve apex_pubkey dosyaları bunlara karşılık gelen dosyaların kopyalarıdır original_apex .

Sıkıştırılmış APEX oluşturma

Sıkıştırılmış APEX kullanılarak inşa edilebilir apex_compression_tool.py bulunan aracı system/apex/tools .

APEX sıkıştırmasıyla ilgili çeşitli parametreler, derleme sisteminde mevcuttur.

In Android.bp APEX dosyası tarafından kontrol edilir sıkıştırılabilir olup olmadığı compressible özellik:

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

Bir PRODUCT_COMPRESSED_APEX ürün bayrak kontrolleri kaynağından inşa edilmiş bir sistem görüntüsü APEX dosyalarını sıkıştırılmış içeren gerekip gerekmediğini.

Yerel deney için, ayarlayarak kompres apexes bir yapı zorlayabilir OVERRIDE_PRODUCT_COMPRESSED_APEX= için true .

Sıkıştırılmış APEX sahip yapı sistemi tarafından oluşturulan dosyaları .capex uzantısı. Uzantı, bir APEX dosyasının sıkıştırılmış ve sıkıştırılmamış sürümleri arasında ayrım yapmayı kolaylaştırır.

Desteklenen sıkıştırma algoritmaları

Android 12 yalnızca deflate-zip sıkıştırmasını destekler.

Önyükleme sırasında sıkıştırılmış bir APEX dosyasını etkinleştirme

Sıkıştırılmış bir APEX aktif hale getirilebilir önce original_apex içindeki dosya içine sıkıştırılmış oluyor /data/apex/decompressed dizininde. Sonuçta elde edilen sıkıştırılmamış APEX dosyası için sert bağlantılıdır /data/apex/active dizin.

Aşağıdaki örneği, yukarıda açıklanan işlemin bir örneği olarak düşünün.

Düşünün /system/apex/com.android.foo.capex sıkıştırılmış APEX versionCode 37 ile aktive edilmiş olarak.

  1. original_apex içindeki dosya /system/apex/com.android.foo.capex çözünürlüğe sahiptir, ve /data/apex/decompressed/com.android.foo@37.apex .
  2. restorecon /data/apex/decompressed/com.android.foo@37.apex doğru bir SELinux'un etiketi var olduğunu doğrulamak için yapılır.
  3. Doğrulama denetimleri yapılmaktadır /data/apex/decompressed/com.android.foo@37.apex , geçerliliğini sağlamak için: apexd denetler genel anahtarı Paket içeriğinde verilen yılında /data/apex/decompressed/com.android.foo@37.apex için içeri paketlenmiş birine eşit olduğunu doğrulamak /system/apex/com.android.foo.capex .
  4. /data/apex/decompressed/com.android.foo@37.apex dosya sabit bağlı olan /data/apex/active/com.android.foo@37.apex dizinde.
  5. Sıkıştırılmamış APEX dosyaları için düzenli aktivasyon mantığı gerçekleştirilir /data/apex/active/com.android.foo@37.apex .

OTA ile etkileşim

Sıkıştırılmış APEX dosyalarının OTA dağıtımı ve uygulaması üzerinde etkileri vardır. Bir OTA güncellemesi, bir cihazda etkin olandan daha yüksek bir sürüm düzeyine sahip sıkıştırılmış bir APEX dosyası içerebileceğinden, bir OTA güncellemesini uygulamak için bir cihaz yeniden başlatılmadan önce belirli bir miktarda boş alan ayrılmalıdır.

OTA sistemini desteklemek için, apexd bu iki bağlayıcı API'leri ortaya çıkarır:

  • calculateSizeForCompressedApex - OTA paketinde kaldırmakta APEX dosyalarına gerekli boyutu hesaplar. Bu, bir OTA indirilmeden önce bir cihazın yeterli alana sahip olduğunu doğrulamak için kullanılabilir.
  • reserveSpaceForCompressedApex - tarafından ileride kullanılmak üzere diskte yer ayırır apexd OTA paket içerisinde sıkıştırılmış APEX dosyalarını açmaya yönelik.

A / B OTA güncelleme durumunda, apexd postInstall OTA rutininin bir kısmı olarak arka planda girişimleri dekompresyon. Dekompresyon, başarısız olursa apexd OTA güncellemesini geçerlidir açılışı sırasında gerçekleştirdiği dekompresyon.

APEX geliştirirken dikkate alınan alternatifler

AOSP'nin APEX dosya biçimini tasarlarken göz önünde bulundurduğu bazı seçenekler ve bunların neden dahil edilip edilmediğini burada bulabilirsiniz.

Düzenli paket yönetim sistemleri

Linux dağıtımları gibi paket yönetim sistemlerine sahip dpkg ve rpm olgun, güçlü ve sağlam. Ancak, kurulumdan sonra paketleri koruyamadıkları için APEX için kabul edilmediler. Doğrulama yalnızca paketler kurulurken gerçekleştirilir. Saldırganlar, fark edilmeden kurulu paketlerin bütünlüğünü bozabilir. Bu, tüm sistem bileşenlerinin bütünlüğü her G/Ç için dm-verity tarafından korunan salt okunur dosya sistemlerinde depolandığı Android için bir gerilemedir. Sistem bileşenlerine yapılacak herhangi bir kurcalama ya yasaklanmalı ya da aygıtın güvenliği ihlal edildiğinde önyüklemeyi reddedebilmesi için algılanabilir olmalıdır.

bütünlük için dm-crypt

APEX kap içinde dosya vardır dahili bölmeler (örneğin, /system bölümü) dosyalarına herhangi bir değişiklik bölümleri monte sonra bile yasaktır dm-gerçeklik ile korunmaktadır. Dosyalara aynı düzeyde güvenlik sağlamak için, bir APEX'teki tüm dosyalar, bir hash ağacı ve bir vbmeta tanımlayıcısı ile eşleştirilmiş bir dosya sistemi görüntüsünde saklanır. Dm-verity olmadan, bir APEX /data bölümü doğrulanması ve kurulu geçirildikten sonra yapılan İstenmeyen değişiklikler savunmasızdır.

Aslında, /data bölümü, aynı zamanda, dm-mahzen şifreleme tabakaları ile korunmaktadır. Bu, kurcalamaya karşı bir düzeyde koruma sağlasa da, birincil amacı bütünlük değil gizliliktir. Bir saldırgan erişim zaman /data bölümü, başka bir koruma söz konusu olabilir ve bu tekrar olmak her sistem bileşeni kıyasla gerileme /system bölümü. APEX dosyasının içindeki hash ağacı, dm-verity ile birlikte aynı düzeyde içerik koruması sağlar.

Yolları /system'den /apex'e yönlendirme

Bir APEX paketlenmiş Sistem bileşen dosyaları gibi yeni yolları üzerinden erişilebilir /apex/<name>/lib/libfoo.so . Dosyaları bir parçası olduğunu ne zaman /system bölümü, onlar gibi yolları üzerinden erişilebilir olduğunu /system/lib/libfoo.so . Bir APEX dosyasının istemcisi (diğer APEX dosyaları veya platform) yeni yolları kullanmalıdır. Yol değişikliğinin bir sonucu olarak mevcut kodu güncellemeniz gerekebilir.

Yol değişikliğini önlemek için bir yol üzerine bir APEX dosyasında dosya içeriğini bindirmek için olsa /system bölümü, Android ekibi üzerindeki bindirme dosyaları karar /system bu (dosya sayısı yerleştirilmiştir edilmiş olarak performansını etkileyebilir çünkü bölüm muhtemelen birbiri ardına istiflenmiş bile) arttı.

Başka bir seçenek gibi dosya erişim işlevlerini kaçırmak oldu open , stat ve readlink ile başlayan yolları böylece, /system altında bunlara karşılık gelen yollara yönlendirildi /apex . Android ekibi, yolları kabul eden tüm işlevleri değiştirmek mümkün olmadığı için bu seçeneği reddetti. Örneğin, bazı uygulamalar, işlevleri uygulayan Bionic'i statik olarak bağlar. Bu gibi durumlarda, bu uygulamalar yeniden yönlendirilmez.