Android'de APEX S: Project Treble'dan Bu Yana En Büyük Şey mi?

Google APEX üzerinde çalışıyor: sistem kitaplıklarını standart bir Linux dağıtımı gibi güncellemek. Android Q'da beklenen APEX, Project Treble'dan bu yana en büyük şey olabilir.

APEX'i uygulamak muhtemelen Project Treble'ın piyasaya sürülmesinden bu yana Google'ın karşılaştığı en büyük baş ağrısıdır. APEX nedir ve tanıtımı Android'i nasıl değiştirecek?

APEX'in arkasındaki fikir, günlük GNU/Linux dağıtımlarında oldukça yaygındır: Linux kütüphane setinin belirli bölümlerini hedefleyen paket güncellemeleri. Ancak Android'in tüm sistem kitaplıklarının ve kitaplıklarının bulunduğu bir RO (salt okunur) bölümü kullandığı göz önüne alındığında bu, Google'ın asla yapmaya çalışmadığı bir şeydi. çerçeveler, çoğu Linux dağıtımında kullanılan olağan RW (okuma-yazma) bölümlerine göre depolanır ve standart yükseltme işlemini gerçekleştirir uygun değil.

Kitaplıklar, diğer programlarda kullanılabilen önceden derlenmiş kodlardır. Yaygın olarak kullanılan yöntemler, Android uygulamalarının çağırabileceği kitaplıklara dönüştürülebilir; aynı kodun birden fazla uygulamada yeniden uygulanması gerekmeyeceğinden APK'ların boyutu azaltılabilir. Önceden yüklenmiş birçok sistem kütüphanesini /system/lib ve /system/lib64 dizinlerinde bulabilirsiniz. Android sistem kitaplıkları genellikle ayrı ayrı güncellenmez; bunun yerine, bir OTA güncellemesi aracılığıyla Android platformu yükseltmelerinin bir parçası olarak güncellenirler. Öte yandan Linux dağıtımlarındaki kütüphaneler ayrı ayrı güncellenebilir. APEX'in kullanıma sunulmasıyla birlikte Android'deki sistem kitaplıkları, Android uygulamaları gibi ayrı ayrı güncellenebilmektedir. Bunun temel faydası, uygulama geliştiricilerinin, bir OEM'in tam sistem yükseltmesini kullanıma sunmasını beklemeden güncellenmiş kitaplıklardan yararlanabilmesidir. APEX'in nasıl çalıştığı hakkında daha fazla teknik ayrıntıya girelim.

APEX kitaplıkların güncellenme şeklini nasıl değiştirecek?

APEX, Google'ı, Android'in tüm kitaplıkları ve dosyaları /system'den farklı, standart olmayan bir bölümden yükleme biçimini yeniden düşünmeye zorlayan (veya daha doğrusu zorlayan) bir ekosistemdir.

Öncelikle paylaşımlı kütüphane ile statik kütüphane arasındaki farkı belirtmemiz gerekiyor. Paylaşılan kitaplık, kendi içinde çalışması için gereken tüm kodu içermeyen ancak aslında diğer kitaplıklara "bağlı" olan bir kitaplıktır (genellikle libkind.so adlı bir dosyadır) kodu sağlarken, statik bir kitaplık, tahmin edebileceğiniz gibi, başka hiçbir kitaplığa bağlı olmayan ve her şeyin statik olarak içinde yer aldığı bir kitaplıktır. dosya.

Android, tarihsel olarak kütüphane yolunu (Linux dünyasında LD_LIBRARY_PATH olarak bilinir) tek bir dosyayla yapılandırmıştır. İkili veya başka bir sistemin ihtiyaç duyduğu paylaşılan kitaplıklar için izin verilen arama yollarını yapılandırmak üzere ld.config.txt [0] adı verilir kütüphane. Bu yollar yapılandırmada sabit kodlanmıştır ve genişletilemez. Salt okunur sistem bölümünü de içeren bu düzen, kullanıcı bir OTA Android güncellemesi yüklemediği sürece güncellenemeyen kitaplıklara yol açar. Google, tek APEX paketlerinin, içinde bulunan ekstra (ve güncellenmiş) kitaplık yollarını içeren kendi ld.config.txt dosyasını sağlamasına izin vererek arama yolunun genişletilmesine olanak tanıyarak bu sorunu düzeltti.

Bu hamle ana sorunlardan birini çözse de hâlâ aşılması gereken birkaç ciddi sorun vardı. Her şeyden önce: ABI (uygulama ikili arayüzü) kararlılığı. Diğer uygulamaların ve kitaplıkların yükseltilmiş kitaplıkla bile aynı protokolle çalışmaya devam etmesine izin vermek için kitaplıklar her zaman kararlı bir arayüz kümesini dışa aktarmalıdır. Google, APEXed kitaplıkları arasında kararlı bir C arayüzü oluşturmaya çalışarak bunun üzerinde aktif olarak çalışıyor.

Ancak bir APEX yalnızca kitaplıklar ve ikili dosyalar ile sınırlı değildir. Aslında yapılandırma dosyalarını, saat dilimi güncellemelerini ve bazı Java çerçevelerini (yazma sırasında şifrelenmiş) içerebilir.

AOSP tarafından sağlanan mevcut APEX paketlerine birkaç örnek:

  • com.android.runtime: ART ve biyonik çalışma zamanı (ikili dosyalar ve kütüphaneler)
  • com.android.tzdata: TimeZone ve ICU verileri (kitaplıklar ve yapılandırma verileri)
  • com.android.resolv: Android tarafından ağla ilgili istekleri çözmek için kullanılan kitaplık (kütüphaneler)
  • com.android.conscrypt: Bir Java Güvenlik Sağlayıcısı (Java çerçevesi)

APEX paketi nasıl kurulur ve yapılandırılır?

APEX paketi, kullanışlı ADB'miz tarafından yüklenebilen basit bir zip arşividir (APK gibi) (geliştirme aşamasındadır) ve daha sonra kullanıcının kendisi tarafından bir paket yöneticisi aracılığıyla (Google Play gibi veya Android paketi aracılığıyla manuel olarak) yükleyici).

ZIP düzeni aşağıdaki gibidir:

Hadi buna dalalım.

apex_manifest.json paket adını ve sürümünü belirtir.

apex_payload.img bir mikro dosya sistemi görüntüsüdür (EXT4 olarak biçimlendirilmiş).

Diğer dosyalar, paketi yüklemek için kullanılan doğrulama sürecinin bir parçasıdır. Bir bakalım.

Varlığı AndroidManifest.xml, esas olarak uygulamalarda kullanılsa bile, standart bir APK kurulumu için kullanılan uygulamaların çoğunun bu paketler için bile yeniden kullanıldığını anlamamıza yardımcı olur. Aslında aralarında ayrım yapmak için yalnızca uzantı kontrol ediliyor.

META-INF/ dizin paket sertifikasına sahiptir ve normal APK'larla aynı mekanizmayı kullanır. Peki bu paketler Kullanıcının bir güncelleme yüklemesine izin verilmeden önce, çalışma zamanında özel/genel anahtar çifti tarafından doğrulanır. Ancak bu Google için yeterli olmadı ve 2 güvenlik katmanı daha eklediler. Görüntünün bütünlüğünü kontrol etmek için dm-verity ve görüntünün güvenilir bir kaynaktan geldiğinden emin olmak için AVB (Android Doğrulanmış Önyükleme) doğrulamalarını kullanıyorlar. En kötü senaryoda APEX paketi reddedilecek.

Tüm doğrulama adımları başarılı olursa görüntü geçerli olarak işaretlenecek ve bir sonraki yeniden başlatmada sistem varyantının yerini alacaktır.

Bir görüntü önyükleme sırasında nasıl yüklenir?

Şu anda cihazımda yüklü olan APEX'lere (bir emülatör) göz atarak başlayalım

Gördüğünüz gibi önceden kurulmuş paketler /system/apex/ dizininde saklanıyor ve hepsi şu anda 1 numaralı sürümde. Peki bir APEX etkinleştirildiğinde ne olur? Örnek olarak yine com.android.tzdata'yı kullanacağız.

Cihazı yeniden başlatalım ve logcat'i analiz edelim.

İlk 2 satır paketin menşeini ve nereye gideceğini anlamak için yeterli bilgi sağlar yüklü: /apex/, Android Q'da etkinleştirilenleri depolamak için kullanılacak yeni bir dizin paketler.

Paket AVB ile başarıyla doğrulandıktan ve genel anahtar eşleştikten sonra APEX, bir döngü cihazı kullanılarak /dev/block/loop0'a bağlanır ve EXT4 dosya sisteminin sistem tarafından erişilebilir olmasını sağlar. Döngü aygıtı, bir dosyayı blok aygıt olarak erişilebilir hale getiren ve o dosyanın içeriğinin bir bağlama noktası olarak erişilebilir olmasını sağlayan sahte bir aygıttır.

Bu noktada, @1 son eki (paket sürümünü belirten) nedeniyle APEX hala kullanılmıyor. Sonunda sisteme paketimizin başarıyla etkinleştirildiğini bildirmek için, Android'in aktif olarak tzdata'nın yaşamasını beklediği /apex/com.android.tzdata'ya bağlanacak. Bağlama bağlaması, mevcut bir dizini veya dosyayı farklı bir noktanın altına yerleştirir. [1]

APEX uygulaması tamamen AOSP kapsamında tek bir depoda bulunur. [2] Apexd (APEX arka plan programı) dizini Android'de çalışan koda sahiptir. Apexer dizini, derleme sistemi tarafından APEX paketlerini oluşturmak için kullanılan kodu içerir.

Amaç nedir?

Bu noktada yapabileceğim tek şey spekülasyon yapmak. En iyi tahminim, Google'ın, Google tarafından güncellenebilecek bir çekirdek APEX paketleri seti oluşturmaya çalıştığıdır. Satıcılar arasında paylaşılan, yalnızca "sistem" güncellemelerini mümkün kılan, ancak tek bir paket kullanan birleşik bir Android temel çekirdeği güncellemeler.

Tüm cihazlar APEX'i destekleyecek mi?

Hayır. Örneğin apexd, tüm Android modüllerini güncellemek için önyüklemeden hemen sonra /data/apex'in kullanılabilir olmasını gerektirir. FDE (Tam Disk Şifreleme) ile /data/apex, cihazın kilidi kullanıcı tarafından açılana kadar şifrelenir ve önyükleme sırasında yalnızca sistem APEX varyantları yükleneceği için APEX'i temelde işe yaramaz hale getirir. Bunun dışında, tüm cihazların APEX'i desteklemesi gerekir, ancak birkaç çekirdek yamasına ihtiyaçları vardır (bunların çoğu, döngü cihazlarıyla oynarken Google tarafından bulunan düzeltmelerdir). [3] [4]


Kaynaklar [0], [1], [2], [3], [4]