2026'dan itibaren, kararlı ana geliştirme modelimizle uyumlu olmak ve ekosistem için platform kararlılığını sağlamak amacıyla kaynak kodunu 2. ve 4. çeyreklerde AOSP'de yayınlayacağız. AOSP'yi oluşturmak ve AOSP'ye katkıda bulunmak için aosp-main yerine android-latest-release kullanmanızı öneririz. android-latest-release manifest dalı her zaman AOSP'ye gönderilen en son sürümü referans alır. Daha fazla bilgi için AOSP'de yapılan değişiklikler başlıklı makaleye bakın.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Hizmet paketi güncellemeleri

Hizmet paketleri, tam sistem güncellemelerinden bağımsız olarak APEX paketleri şeklinde güncellenebilir. SDV'de bu güncelleme süreci SDV güncelleme yöneticisi tarafından yönetilir. Güncellemenin geçerli olması için cihazı yeniden başlatmanız gerekir.

Hizmet paketi güncellemeleri için iki tür APEX desteklenir:

Önceden yüklenmiş APEX: APEX paketinin eski bir sürümü, salt okunur bölümlerden birinde (/system, /system_ext, /product, /vendor ve /odm) zaten mevcut.
Yeni APEX: Salt okunur bölümlerin hiçbirinde aynı ada sahip (apex_manifest.json içinde belirtildiği gibi) APEX paketi bulunmuyor.

Önceden yüklenmiş APEX

Bu, hizmet paketlerini güncellemek için en yaygın ve önerilen yöntemdir. Bu güncellemenin geçerli olması için yeni APEX paketinin aşağıdaki koşulları karşılaması gerekir:

apex_manifest.json içinde, önceden yüklenmiş APEX ile aynı paket adına sahip olmalıdır.
apex_manifest.json içinde, önceden yüklenmiş APEX'ten daha yüksek bir sürüm kodu bildirin.

Not: Önceden yüklenmiş APEX, 0 sürüm kodunu kullanmamalıdır.
APEX'i, önceden yüklenmiş APEX ile aynı anahtar çiftiyle imzalayın.

Yeni APEX

Önceden yüklenmiş APEX'leri kullanmak güvenlik açısından en iyi uygulama olsa da yeni APEX'ler desteklenir. Bu yaklaşımı kullanırken iş ortakları kapsamlı güvenlik protokollerini sürdürmekten sorumludur. Bu sorumluluklar şunlardır:

Bu APEX'ler için kullanılan imzalama anahtarlarını güvenli bir şekilde yönetme.
Kötü amaçlı paketleri tanımlamak ve engellemek için sağlam bir süreç oluşturma.
Mümkün olduğunda sonraki sistem güncellemelerinde yeni APEX'leri önceden yüklenmiş APEX'lere dönüştürme.

Yeni bir APEX'i yüklemek veya güncellemek için aşağıdaki yapılandırmalar gerekir.

Güvenilen ortak anahtarları önceden yükleme

Yeni bir APEX'in yüklenebilmesi için ortak imzalama anahtarının hedef bölüme önceden yüklenmiş olması gerekir. Ortak anahtarı /partition/etc/brand_new_apex/ konumuna yerleştirin. Burada /partition/, Treble kuralları kapsamında APEX'in ilişkilendirildiği bölümü temsil eder. Örneğin, bir APEX'in imzası /vendor/etc/brand_new_apex/ içindeki bir ortak anahtara göre doğrulanırsa bu APEX, tedarikçi APEX'i gibi davranır. Sistem, önceden yüklenmiş bir ortak anahtara karşılık gelen bir anahtarla imzalanmamış yeni APEX'leri reddeder.

Kötü amaçlı yeni bir APEX'i engelleme

Yükleme işleminden sonra yeni bir APEX'in kötü amaçlı olduğu tespit edilirse sistem güncellemesi kullanılarak engellenmesi gerekir. Bunu yapmak için APEX paket adını /partition/etc/brand_new_apex/blocklist.json içindeki bir engellenenler listesi dosyasına ekleyin. Bu engellenenler listesi, APEX'in hedef bölümüne (ortak anahtarının önceden yüklendiği bölüm) yerleştirilmelidir. Her bölümün kendi özel engellenenler listesi dosyası vardır.