Android 10, APK tabanlı saat dilimi veri güncelleme mekanizmasını (Android 8.1 ve Android 9'da mevcuttur) kullanımdan kaldırır ve onu APEX tabanlı modül güncelleme mekanizmasıyla değiştirir. AOSP 8.1 ila 13, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gereken platform kodunu hala içerir, böylece Android 10'a yükseltme yapan cihazlar, APK aracılığıyla iş ortağı tarafından sağlanan saat dilimi veri güncellemelerini almaya devam edebilir. Ancak, APK tabanlı bir güncelleme APEX tabanlı bir güncellemenin yerini aldığından (yani APK güncellemesi alan bir cihaz APEX tabanlı güncellemeleri yok sayacağından) modül güncellemelerini de alan bir üretim cihazında APK güncelleme mekanizması kullanılmamalıdır. ).
Saat dilimi güncellemeleri (Android 10+)
Android 10 ve sonraki sürümlerde desteklenen Saat Dilimi Verileri modülü, Android cihazlarda yaz saatini (DST) ve saat dilimlerini güncelleyerek dini, siyasi ve jeopolitik nedenlerle sık sık değişebilen verileri standart hale getirir.
Güncellemeler aşağıdaki süreci kullanır:
- IANA , Saat Dilimi Veritabanı için bir güncelleme yayınladı Bir veya daha fazla hükümetin kendi ülkelerinde bir saat dilimi kuralını değiştirmesine yanıt olarak bir güncelleme yayınladı.
- Google veya Android iş ortağı, güncellenmiş saat dilimlerini içeren bir Saat Dilimi Veri modülü güncellemesi (APEX dosyası) hazırlar.
- Son kullanıcı cihazı güncellemeyi indirir, yeniden başlatır, ardından değişiklikleri uygular, ardından cihazın saat dilimi verileri güncellemeden yeni saat dilimi verilerini içerir.
Modüllerle ilgili ayrıntılar için, bkz. Modüler Sistem Bileşenleri .
Saat dilimi güncellemeleri (Android 8.1–9)
Not: APK tabanlı saat dilimi veri güncelleme mekanizması özelliği, Android U'dan itibaren tamamen kaldırılmıştır ve kaynak kodunda bulunamaz. İş ortakları, Time Zone Mainline modülüne tamamen geçiş yapmalıdır.
Android 8.1 ve Android 9'da OEM'ler, güncellenmiş saat dilimi kuralları verilerini bir sistem güncellemesi gerektirmeden cihazlara göndermek için APK tabanlı bir mekanizma kullanabilir. Bu mekanizma, kullanıcıların güncellemeleri zamanında almalarını sağlar (böylece bir Android cihazının kullanım ömrünü uzatır) ve Android ortaklarının sistem görüntüsü güncellemelerinden bağımsız olarak saat dilimi güncellemelerini test etmelerini sağlar.
Android çekirdek kitaplıkları ekibi, stok Android cihazında saat dilimi kurallarını güncellemek için gerekli veri dosyalarını sağlar. OEM'ler, cihazları için saat dilimi güncellemeleri oluştururken bu veri dosyalarını kullanmayı seçebilir veya tercih edilirse kendi veri dosyalarını oluşturabilir. Her durumda, OEM'ler, desteklenen cihazları için kalite güvencesi/testi, zamanlaması ve saat dilimi kuralı güncellemelerinin başlatılması üzerindeki kontrolü elinde tutar.
Android saat dilimi kaynak kodu ve verileri
Tüm stok Android cihazları, bu özelliği kullanmayanlar bile, saat dilimi kuralları verilerine ihtiyaç duyar ve /system
bölümünde varsayılan bir saat dilimi kuralı verileri kümesiyle gönderilmelidir. Bu veriler daha sonra Android kaynak ağacındaki aşağıdaki kitaplıklardan gelen kod tarafından kullanılır:
-
libcore/
'dan yönetilen kod (örneğin,java.util.TimeZone
)tzdata
vetzlookup.xml
dosyalarını kullanır. -
bionic/
içindeki yerel kitaplık kodu (örneğin,mktime
, localtime sistem çağrıları için)tzdata
dosyasını kullanır. -
external/icu/
/icu/ içindeki ICU4J/ICU4C kitaplık kodu, icu.dat
dosyasını kullanır.
Bu kitaplıklar /data/misc/zoneinfo/current
dizininde bulunabilecek bindirme dosyalarının kaydını tutar. Bindirme dosyalarının, geliştirilmiş saat dilimi kuralları verilerini içermesi ve böylece cihazların /system
değiştirilmeden güncellenmesine olanak sağlaması beklenir.
Saat dilimi kuralı verilerine ihtiyaç duyan Android sistem bileşenleri, önce aşağıdaki konumları kontrol edin:
-
libcore/
vebionic/
kodu,tzdata
vetzlookup.xml
dosyalarının/data
kopyasını kullanır. - ICU4J/ICU4C kodu
/data
içindeki dosyaları kullanır ve mevcut olmayan veriler için (formatlar, yerelleştirilmiş dizeler vb. için)/system
dosyalarına geri döner.
Dağıtım dosyaları
Distro .zip
dosyaları, /data/misc/zoneinfo/current
dizini doldurmak için gereken veri dosyalarını içerir. Dağıtım dosyaları ayrıca, cihazların sürüm oluşturma sorunlarını algılamasına olanak tanıyan meta veriler içerir.
ICU sürümü, Android platform gereksinimleri ve diğer sürüm değişiklikleri ile içerik değiştiğinden, dağıtım dosyası biçimi Android sürümüne bağlıdır. Android, her IANA güncellemesi için desteklenen Android sürümleri için dağıtım dosyaları sağlar (platform sistem dosyalarını güncellemeye ek olarak). OEM'ler cihazlarını güncel tutmak için bu dağıtım dosyalarını kullanabilir veya Android kaynak ağacını (dağıtım dosyaları oluşturmak için gereken komut dosyalarını ve diğer dosyaları içeren) kullanarak kendi dağıtım dosyalarını oluşturabilir.
Saat dilimi güncelleme bileşenleri
Zaman dilimi kuralları güncellemesi, dağıtım dosyalarının bir cihaza iletilmesini ve içerdiği dosyaların güvenli kurulumunu içerir. Aktarım ve kurulum aşağıdakileri gerektirir:
- Varsayılan olarak devre dışı bırakılan platform hizmeti işlevi (
timezone.RulesManagerService
). OEM'ler, yapılandırma yoluyla işlevselliği etkinleştirmelidir.RulesManagerService
, sistem sunucusu işleminde çalışır ve/data/misc/zoneinfo/staged
öğesine yazarak saat dilimi güncelleme işlemlerini gerçekleştirir.RulesManagerService
ayrıca önceden hazırlanmış işlemleri değiştirebilir veya silebilir. -
TimeZoneUpdater
, güncellenemeyen bir sistem uygulaması (diğer adıyla Updater uygulaması ). OEM'ler, bu uygulamayı, özelliği kullanan cihazların sistem görüntüsüne dahil etmelidir. - OEM
TimeZoneData
, dağıtım dosyalarını cihaza taşıyan ve bunları Güncelleyici uygulamasında kullanılabilir hale getiren güncellenebilir bir sistem uygulaması (diğer adıyla Veri uygulaması ). OEM'ler, bu uygulamayı, özelliği kullanan cihazların sistem görüntüsüne dahil etmelidir. -
tzdatacheck
, saat dilimi güncellemelerinin doğru ve güvenli çalışması için gereken bir önyükleme zamanı ikili dosyası.
Android kaynak ağacı, OEM'in değişiklik yapmadan kullanmayı seçebileceği yukarıdaki bileşenler için genel kaynak kodunu içerir. OEM'lerin bu özelliği doğru şekilde etkinleştirip etkinleştirmediklerini otomatik olarak kontrol etmelerini sağlamak için test kodu sağlanır.
Dağıtım kurulumu
Dağıtım yükleme işlemi aşağıdaki adımları içerir:
- Veri uygulaması, bir uygulama mağazası indirmesi veya yandan yükleme yoluyla güncellenir . Sistem sunucusu işlemi (
timezone.RulesManagerServer/timezone.PackageTracker
sınıfları aracılığıyla), yapılandırılmış, OEM'e özgü Veri uygulaması paketi adındaki değişiklikleri izler.Şekil 1. Veri uygulaması güncellemeleri - Sistem sunucusu işlemi, Güncelleyici Uygulamasına benzersiz, tek kullanımlık bir belirteçle hedeflenen bir amacı yayınlayarak bir güncelleme kontrolünü tetikler . Sistem sunucusu, tetiklediği en son kontrolün ne zaman tamamlandığını belirleyebilmesi için oluşturduğu en son belirteci takip eder; diğer belirteçler yoksayılır.
Şekil 2. Tetik güncelleme kontrolü - Güncelleme kontrolü sırasında Güncelleyici uygulaması aşağıdaki görevleri gerçekleştirir:
- RulesManagerService'i çağırarak geçerli aygıt durumunu sorgular.
Şekil 3. Data uygulaması güncellemeleri, RulesManagerService'i çağırma - Dağıtım hakkında bilgi almak için iyi tanımlanmış bir ContentProvider URL'sini ve sütun özelliklerini sorgulayarak Veri uygulamasını sorgular.
Şekil 4. Veri uygulaması güncellemeleri, dağıtım hakkında bilgi alın
- RulesManagerService'i çağırarak geçerli aygıt durumunu sorgular.
- Güncelleyici uygulaması, sahip olduğu bilgilere göre uygun eylemi gerçekleştirir . Kullanılabilir eylemler şunları içerir:
- Kurulum talep edin. Dağıtım verileri, Veri uygulamasından okunur ve sistem sunucusundaki RulesManagerService'e iletilir. RulesManagerService, dağıtım biçimi sürümünün ve içeriğinin aygıt için uygun olduğunu yeniden onaylar ve yüklemeyi gerçekleştirir.
- Kaldırma isteğinde bulunun (bu nadirdir). Örneğin,
/data
içindeki güncellenmiş APK devre dışı bırakılıyor veya kaldırılıyorsa ve cihaz/system
içinde bulunan sürüme dönüyorsa. - Hiçbir şey yapma. Veri uygulaması dağıtımının geçersiz olduğu tespit edildiğinde gerçekleşir.
Şekil 5. Kontrol tamamlandı - Yeniden başlat ve tzdatacheck. Aygıt yeniden başlatıldığında, tzdatacheck ikili herhangi bir aşamalı işlemi yürütür. tzdatacheck ikili dosyası aşağıdaki görevleri gerçekleştirebilir:
- Diğer sistem bileşenleri açılmadan ve dosyaları kullanmaya başlamadan önce
/data/misc/zoneinfo/current
dosyalarının oluşturulmasını, değiştirilmesini ve/veya silinmesini işleyerek aşamalı işlemi gerçekleştirin. -
/data
içindeki dosyaların mevcut platform sürümü için doğru olup olmadığını kontrol edin; cihaz henüz bir sistem güncellemesi aldıysa ve dağıtım biçimi sürümü değiştiyse durum böyle olmayabilir. - IANA kuralları sürümünün
/system
içindeki sürümle aynı veya daha yeni olduğundan emin olun. Bu,/system
görüntüsünde mevcut olandan daha eski saat dilimi kuralları verileriyle bir cihazdan ayrılan bir sistem güncellemesine karşı koruma sağlar.
- Diğer sistem bileşenleri açılmadan ve dosyaları kullanmaya başlamadan önce
Güvenilirlik
Uçtan uca yükleme işlemi eşzamansızdır ve üç işletim sistemi işlemine bölünür. Kurulum sırasında herhangi bir noktada, cihaz güç kaybedebilir, disk alanı tükenebilir veya kurulum kontrolünün tamamlanmamasına neden olacak başka sorunlarla karşılaşabilir. En iyi başarısız durumda, Güncelleyici uygulaması sistem sunucusuna başarısız olduğunu bildirir; En kötü başarısız durumda, RulesManagerService hiçbir çağrı almaz.
Bunu halletmek için sistem sunucusu kodu, tetiklenen bir güncelleme kontrolünün tamamlanıp tamamlanmadığını ve Data App'in en son kontrol edilen sürüm kodunun ne olduğunu takip eder. Cihaz boştayken ve şarj olurken, sistem sunucu kodu mevcut durumu kontrol edebilir. Eksik bir güncelleme denetimi veya beklenmeyen bir Veri Uygulaması sürümü tespit ederse, kendiliğinden bir güncelleme denetimini tetikler.
Güvenlik
Etkinleştirildiğinde, sistem sunucusundaki RulesManagerService kodu, sistemin kullanımının güvenli olduğundan emin olmak için birkaç kontrol gerçekleştirir.
- Kötü yapılandırılmış bir sistem görüntüsünü gösteren sorunlar, aygıtın önyüklemesini engeller; Örnekler arasında hatalı bir Güncelleyici veya Veri uygulaması yapılandırması veya Güncelleyici veya Veri uygulamasının
/system/priv-app
içinde olmaması yer alır. - Kötü bir Veri uygulamasının yüklendiğini gösteren sorunlar, bir aygıtın önyüklenmesini engellemez, ancak bir güncelleme denetiminin tetiklenmesini engeller; örnekler, gerekli sistem izinlerinin olmamasını veya Data uygulamasının, beklenen URI'de bir ContentProvider göstermemesini içerir.
/data/misc/zoneinfo
dizinleri için dosya izinleri SELinux kuralları kullanılarak uygulanır. Herhangi bir APK'da olduğu gibi, Veri uygulaması, /system/priv-app
sürümünü imzalamak için kullanılan anahtarla imzalanmalıdır. Veri uygulamasının özel, OEM'e özgü bir paket adına ve anahtarına sahip olması bekleniyor.
Saat dilimi güncellemelerini entegre etme
OEM'ler, saat dilimi güncelleme özelliğini etkinleştirmek için genellikle:
- Kendi Veri uygulamasını oluşturun.
- Güncelleyici ve Veri uygulamalarını sistem görüntüsü derlemesine dahil edin.
- RulesManagerService'i etkinleştirmek için sistem sunucusunu yapılandırın.
hazırlanıyor
Başlamadan önce OEM'ler aşağıdaki politika, kalite güvencesi ve güvenlik hususlarını gözden geçirmelidir:
- Veri uygulamaları için uygulamaya özel özel bir imzalama anahtarı oluşturun.
- Hangi cihazların güncelleneceğini ve güncellemelerin yalnızca bunlara ihtiyaç duyan cihazlara yüklenmesini nasıl sağlayabileceklerini anlamak için saat dilimi güncellemeleri için bir sürüm ve sürüm oluşturma stratejisi oluşturun. Örneğin, OEM'ler tüm cihazları için tek bir Veri uygulamasına sahip olmak isteyebilir veya farklı cihazlar için farklı Veri uygulamalarına sahip olmayı seçebilir. Karar, paket adı seçimini, muhtemelen kullanılan sürüm kodlarını ve KG stratejisini etkiler.
- AOSP'den stok Android saat dilimi verilerini kullanmak mı yoksa kendilerininkini oluşturmak mı istediklerini anlayın.
Veri uygulaması oluşturma
AOSP, AndroidManifest.xml
ve package packages/apps/TimeZoneData/oem_template
içinde bulunan diğer dosyalar için talimatlar ve örnek şablonlar ile package packages/apps/TimeZoneData
içinde bir Veri uygulaması oluşturmak için gereken tüm kaynak kodunu ve yapı kurallarını içerir. Örnek şablonlar, hem gerçek Veri uygulaması APK'sı için bir yapı hedefi hem de Veri uygulamasının test sürümlerini oluşturmak için ek hedefler içerir.
OEM'ler, Veri uygulamasını kendi simgeleri, adları, çevirileri ve diğer ayrıntılarıyla özelleştirebilir. Ancak Veri uygulaması başlatılamadığından simge yalnızca Ayarlar > Uygulamalar ekranında görünür.
Veri uygulamasının, sistem görüntüsüne eklenmeye (ilk sürüm için) ve bir uygulama mağazası aracılığıyla imzalanıp dağıtılmaya (sonraki güncellemeler için) uygun APK'lar üreten bir tapas yapısıyla oluşturulması amaçlanmıştır. Tapas kullanmayla ilgili ayrıntılar için bkz. Tapas kullanarak Veri uygulamasını oluşturma.
OEM'ler, /system/priv-app
içindeki bir cihazın sistem görüntüsünde önceden oluşturulmuş Veri uygulamasını yüklemelidir. Önceden oluşturulmuş APK'ları (tapas oluşturma işlemi tarafından oluşturulan) sistem görüntüsüne dahil etmek için OEM'ler, örnek dosyaları packages/apps/TimeZoneData/oem_template/data_app_prebuilt
. Örnek şablonlar ayrıca Data uygulamasının test sürümlerini test paketlerine dahil etmek için derleme hedefleri içerir.
Güncelleyici ve Veri uygulamalarını sistem görüntüsüne dahil etme
OEM'ler, Güncelleyici ve Veri uygulaması APK'larını sistem görüntüsünün /system/priv-app
dizinine yerleştirmelidir. Bunu yapmak için sistem görüntüsü derlemesi, Updater uygulamasını ve Data uygulaması önceden oluşturulmuş hedeflerini açıkça içermelidir.
Güncelleyici uygulaması, platform anahtarıyla imzalanmalı ve diğer herhangi bir sistem uygulaması olarak dahil edilmelidir. Hedef, packages/apps/TimeZoneUpdater
içinde TimeZoneUpdater
olarak tanımlanır. Veri uygulamasının dahil edilmesi OEM'e özeldir ve ön derleme için seçilen hedef adına bağlıdır.
Sistem sunucusunu yapılandırma
Saat dilimi güncellemelerini etkinleştirmek için OEM'ler, frameworks/base/core/res/res/values/config.xml
içinde tanımlanan yapılandırma özelliklerini geçersiz kılarak sistem sunucusunu yapılandırabilir.
Mülk | Tanım | Geçersiz Kılma Gerekli mi? |
---|---|---|
config_enableUpdateableTimeZoneRules | RulesManagerService'i etkinleştirmek için true olarak ayarlanmalıdır. | Evet |
config_timeZoneRulesUpdateTrackingEnabled | Sistemin Veri uygulamasındaki değişiklikleri dinlemesi için true olarak ayarlanmalıdır. | Evet |
config_timeZoneRulesDataPackage | OEM'e özel Veri uygulamasının paket adı. | Evet |
config_timeZoneRulesUpdaterPackage | Varsayılan Güncelleyici uygulaması için yapılandırıldı. Yalnızca farklı bir Updater uygulaması uygulaması sağlarken değiştirin. | Numara |
config_timeZoneRulesCheckTimeMillisAllowed | RulesManagerService tarafından tetiklenen bir güncelleme denetimi ile yükleme, kaldırma veya hiçbir şey yapma yanıtı arasında izin verilen süre. Bu noktadan sonra, kendiliğinden bir güvenilirlik tetikleyicisi oluşturulabilir. | Numara |
config_timeZoneRulesCheckRetryCount | RulesManagerService daha fazlasını oluşturmayı durdurmadan önce izin verilen sıralı başarısız güncelleme denetimlerinin sayısı. | Numara |
Yanlış yapılandırılmış bir aygıt önyüklemeyi reddedebileceğinden, yapılandırma geçersiz kılma işlemleri sistem görüntüsünde (satıcı veya diğer değil) olmalıdır. Yapılandırma geçersiz kılmaları satıcı görüntüsündeyse, Veri uygulaması olmayan (veya farklı Veri uygulaması/Updater uygulaması paket adlarına sahip) bir sistem görüntüsüne güncelleme yapmak yanlış yapılandırma olarak kabul edilir.
xTS testi
xTS, Tradefed (CTS ve VTS gibi) kullanan standart Android test takımlarına benzeyen OEM'e özel herhangi bir test takımı anlamına gelir. Bu tür test paketlerine sahip OEM'ler, aşağıdaki konumlarda sağlanan Android saat dilimi güncelleme testlerini ekleyebilir:
-
packages/apps/TimeZoneData/testing/xts
, temel otomatikleştirilmiş işlevsel testler için gereken kodu içerir. - package
packages/apps/TimeZoneData/oem_template/xts
xts, testleri Tradefed benzeri bir xTS paketine dahil etmek için örnek bir dizin yapısı içerir. Diğer şablon dizinlerinde olduğu gibi, OEM'lerin kendi ihtiyaçlarına göre kopyalaması ve özelleştirmesi beklenir. -
packages/apps/TimeZoneData/oem_template/data_app_prebuilt
, testin gerektirdiği önceden oluşturulmuş test APK'larını dahil etmek için derleme zamanı yapılandırmasını içerir.
Saat dilimi güncellemeleri oluşturma
IANA yeni bir saat dilimi kuralı seti yayınladığında, Android çekirdek kitaplıkları ekibi AOSP'deki sürümleri güncellemek için yamalar oluşturur. Stok Android sistemini ve dağıtım dosyalarını kullanan OEM'ler bu taahhütleri alabilir, Veri uygulamalarının yeni bir sürümünü oluşturmak için kullanabilir ve ardından üretimdeki cihazlarını güncellemek için yeni sürümü yayınlayabilir.
Veri uygulamaları Android sürümlerine yakından bağlı dağıtım dosyaları içerdiğinden, OEM'lerin bir OEM'in güncellemek istediği desteklenen her Android sürümü için Veri uygulamasının yeni bir sürümünü oluşturması gerekir. Örneğin, bir OEM Android 8.1, 9 ve 10 cihazlar için güncellemeler sağlamak isterse işlemi üç kez tamamlamalıdır.
1. Adım: Sistem/zaman dilimi ve harici/icu veri dosyalarının güncellenmesi
Bu adımda, OEM'ler AOSP'deki sürüm -dev dallarından system/timezone
ve external/icu
icu için stok Android taahhütlerini alır ve bu taahhütleri kendi Android kaynak kodu kopyalarına uygular.
system/timezone AOSP yaması system/timezone/input_data
ve system/timezone/output_data
içindeki güncellenmiş dosyaları içerir. Ek yerel düzeltmeler yapması gereken OEM'ler giriş dosyalarını değiştirebilir ve ardından system/timezone/input_data
ve external/icu
icu içindeki dosyaları output_data
içinde dosya oluşturmak için kullanabilir.
En önemli dosya, Data uygulaması APK oluşturulduğunda otomatik olarak dahil edilen system/timezone/output_data/distro/distro.zip
.
2. Adım: Veri uygulamasının sürüm kodunu güncelleme
Bu adımda OEM'ler, Veri uygulamasının sürüm kodunu günceller. Derleme otomatik olarak distro.zip
alır, ancak Veri uygulamasının yeni sürümünün yeni olarak tanınması ve önceden yüklenmiş bir Veri uygulamasını veya bir cihaza yüklenmiş bir Veri uygulamasını önceki bir güncellemeyle değiştirmek için kullanılması için yeni bir sürüm koduna sahip olması gerekir.
package/apps/TimeZoneData/oem_template/data_app
kopyalanan dosyaları kullanarak Data uygulamasını oluştururken, APK'ya uygulanan sürüm kodunu/sürüm adını Android.mk
:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Benzer girişler testing/Android.mk
içinde bulunabilir (ancak test sürümü kodları sistem görüntüsü sürümünden daha yüksek olmalıdır). Ayrıntılar için, örnek sürüm kodu strateji şemasına bakın; örnek şema veya benzer bir şema kullanılıyorsa, gerçek sürüm kodlarından daha yüksek olmaları garanti edildiğinden test sürüm kodlarının güncellenmesi gerekmez.
3. Adım: Yeniden oluşturma, imzalama, test etme ve yayınlama
Bu adımda, OEM'ler tapas kullanarak APK'yı yeniden oluşturur, oluşturulan APK'yi imzalar ve ardından APK'yı test edip yayınlar:
- Yayınlanmamış cihazlar için (veya piyasaya sürülen bir cihaz için sistem güncellemesi hazırlarken), sistem görüntüsünün ve xTS testlerinin en son APK'lara sahip olduğundan emin olmak için yeni APK'ları Veri uygulaması önceden oluşturulmuş dizinine gönderin. OEM'ler, yeni dosyanın doğru çalışıp çalışmadığını test etmelidir (yani, CTS'yi ve OEM'e özgü tüm otomatik ve manuel testleri geçer).
- Artık sistem güncellemelerini almayan piyasaya sürülen cihazlar için imzalanan APK yalnızca bir uygulama mağazası aracılığıyla yayınlanabilir.
OEM'ler, kalite güvencesinden ve güncellenmiş Veri uygulamasını piyasaya çıkmadan önce cihazlarında test etmekten sorumludur.
Veri uygulaması sürüm kodu stratejisi
Cihazların doğru APK'ları almasını sağlamak için Veri uygulamasının uygun bir sürüm oluşturma stratejisi olması gerekir. Örneğin, uygulama mağazasından indirilenden daha eski bir APK içeren bir sistem güncellemesi alınırsa, uygulama mağazası sürümü korunmalıdır.
APK sürüm kodu aşağıdaki bilgileri içermelidir:
- Dağıtım biçimi sürümü (majör + minör)
- Artan (opak) bir sürüm numarası
Şu anda platform API düzeyi, dağıtım biçimi sürümüyle güçlü bir şekilde ilişkilidir, çünkü her API düzeyi genellikle yeni bir YBÜ sürümüyle ilişkilendirilir (bu, dağıtım dosyalarını uyumsuz hale getirir). Gelecekte, Android bunu bir dağıtım dosyasının birden çok Android platformu sürümünde çalışabilmesi için değiştirebilir (ve Veri uygulaması sürüm kod şemasında API düzeyi kullanılmaz).
Örnek sürüm kodu stratejisi
Bu örnek sürüm oluşturma numarası şeması, daha yüksek dağıtım biçimi sürümlerinin daha düşük dağıtım biçimi sürümlerinin yerini almasını sağlar. AndroidManifest.xml
, eski cihazların kaldırabileceklerinden daha yüksek dağıtım biçimi sürümüne sahip sürümleri almamasını sağlamak için android:minSdkVersion
kullanır.

Örnek | Değer | Amaç |
---|---|---|
Y | Rezerve | Gelecekteki alternatif şemalara/test APK'larına izin verir. Başlangıçta (dolaylı olarak) 0'dır. Temeldeki tür, imzalı bir 32-bit int türü olduğundan, bu şema iki adede kadar gelecekteki numaralandırma şeması revizyonunu destekler. |
01 | Ana biçim sürümü | 3 ondalık basamaklı ana biçim sürümünü izler. Dağıtım biçimi 3 ondalık basamağı destekler, ancak burada yalnızca 2 basamak kullanılır. API düzeyi başına beklenen büyük artış göz önüne alındığında, 100'e ulaşması olası değildir. Ana sürüm 1, API düzeyi 27'ye eşdeğerdir. |
1 | Küçük biçimli sürüm | 3 ondalık basamaklı ikincil biçim sürümünü izler. Dağıtım biçimi 3 ondalık basamağı destekler, ancak burada yalnızca 1 basamak kullanılır. 10'a ulaşmak pek mümkün değil. |
X | Rezerve | Üretim sürümleri için 0'dır (ve test APK'ları için farklı olabilir). |
ZZZZZ | Opak sürüm numarası | Talep üzerine tahsis edilen ondalık sayı. Gerekirse geçiş reklamı güncellemelerinin yapılmasına izin vermek için boşluklar içerir. |
Ondalık sayı yerine ikili sayı kullanılsaydı şema daha iyi paketlenebilirdi, ancak bu şema insan tarafından okunabilir olma avantajına sahiptir. Tam sayı aralığı tükenirse Veri uygulaması paketi adı değişebilir.
Sürüm adı, ayrıntıların insan tarafından okunabilir bir temsilidir, örneğin: major=001,minor=001,iana=2017a, revision=1,respin=2
. Örnekler aşağıdaki tabloda gösterilmiştir.
# | Sürüm kodu | minSdkVersion | {Ana biçim sürümü},{Alt biçim sürümü},{IANA kuralları sürümü},{Revizyon} |
---|---|---|---|
1 | 11000010 | O-MR1 | büyük=001,küçük=001,iana=2017a,revizyon=1 |
2 | 21000010 | P | majör=002,minor=001,iana=2017a,revizyon=1 |
3 | 11000020 | O-MR1 | büyük=001,küçük=001,iana=2017a,revizyon=2 |
4 | 11000030 | O-MR1 | büyük=001,küçük=001,iana=2017b,revizyon=1 |
5 | 21000020 | P | majör=002,minor=001,iana=2017b,revizyon=1 |
6 | 11000040 | O-MR1 | büyük=001,küçük=001,iana=2018a,revizyon=1 |
7 | 21000030 | P | majör=002,minor=001,iana=2018a,revizyon=1 |
8 | 1123456789 | - | - |
9 | 11000021 | O-MR1 | majör=001,minor=001,iana=2017a,revizyon=2,respin=2 |
- Örnek 1 ve 2, aynı 2017a IANA sürümü için farklı ana biçim sürümlerine sahip iki APK sürümünü göstermektedir. 2, sayısal olarak 1'den yüksektir; bu, daha yeni cihazların daha yüksek formatlı sürümleri almasını sağlamak için gereklidir. minSdkVersion, P sürümünün O cihazlarına sağlanmamasını sağlar.
- Örnek 3, 1 için bir revizyon/düzeltmedir ve sayısal olarak 1'den büyüktür.
- Örnek 4 ve 5, O-MR1 ve P için 2017b sürümlerini göstermektedir. Sayısal olarak daha yüksek olduklarından, ilgili öncüllerinin önceki IANA sürümlerinin/Android revizyonlarının yerini alırlar.
- Örnek 6 ve 7, O-MR1 ve P için 2018a sürümlerini göstermektedir.
- Örnek 8, Y=0 şemasını tamamen değiştirmek için Y'nin kullanımını gösterir.
- Örnek 9, apk'yi yeniden döndürmek için 3 ile 4 arasında kalan boşluğun kullanımını gösterir.
Her cihaz, sistem görüntüsünde varsayılan, uygun şekilde sürümlendirilmiş bir APK ile birlikte gönderildiğinden, bir P sistem görüntüsü sürümünden daha düşük bir sürüm numarasına sahip olduğundan, bir P cihazına O-MR1 sürümünün yüklenmesi riski yoktur. O-MR1 sürümü /data
içinde kurulu olan ve daha sonra P için bir sistem güncellemesi alan bir cihaz / /data
içindeki O-MR1 sürümüne tercihli olarak /system
sürümünü kullanır çünkü P sürümü her zaman O- için tasarlanan herhangi bir uygulamadan daha yüksektir. MR1.
Tapas kullanarak Veri uygulamasını oluşturma
OEM'ler, saat dilimi Data uygulamasının çoğu yönünü yönetmekten ve sistem görüntüsünü doğru şekilde yapılandırmaktan sorumludur. Veri uygulamasının, sistem görüntüsüne eklenmeye (ilk sürüm için) ve bir uygulama mağazası aracılığıyla imzalanıp dağıtılmaya (sonraki güncellemeler için) uygun APK'lar üreten bir tapas yapısıyla oluşturulması amaçlanmıştır.
Tapas , uygulamaların dağıtılabilir sürümlerini üretmek için azaltılmış bir kaynak ağacı kullanan Android yapı sisteminin inceltilmiş bir sürümüdür. Normal Android derleme sistemine aşina olan OEM'ler, normal Android platform derlemesindeki derleme dosyalarını tanımalıdır.
Manifest oluşturma
Azaltılmış bir kaynak ağacı, genellikle yalnızca derleme sistemi ve uygulamayı oluşturmak için ihtiyaç duyulan Git projelerine atıfta bulunan özel bir bildirim dosyasıyla elde edilir. Bir Veri uygulaması oluşturma bölümündeki talimatları uyguladıktan sonra, OEM'ler, packages/apps/TimeZoneData/oem_template
altındaki şablon dosyaları kullanılarak oluşturulmuş en az iki OEM'e özgü Git projesine sahip olmalıdır:
- Bir Git projesi, uygulama APK dosyasını oluşturmak için gereken bildirim ve derleme dosyaları gibi uygulama dosyalarını içerir (örneğin,
vendor/ oem /apps/TimeZoneData
). Bu proje ayrıca, xTS testleri tarafından kullanılabilecek test APK'ları için derleme kuralları içerir. - Bir Git projesi, sistem görüntüsü derlemesine ve xTS testlerine dahil edilmek üzere uygulama derlemesi tarafından üretilen imzalı APK'ları içerir.
Uygulama derlemesi, platform derlemesiyle paylaşılan veya OEM'den bağımsız kod kitaplıkları içeren diğer birkaç Git projesinden yararlanır.
Aşağıdaki bildirim snippet'i, saat dilimi Data uygulamasının O-MR1 derlemesini desteklemek için gereken minimum Git projeleri grubunu içerir. OEM'ler, OEM'e özgü Git projelerini (genellikle imzalama sertifikasını içeren bir projeyi içerir) bu bildirime eklemelidir ve buna göre farklı dallar yapılandırabilir.
<!-- Tapas Build --> <project path="build" name="platform/build"> <copyfile src="core/root.mk" dest="Makefile" /> </project> <project path="prebuilts/build-tools" name="platform/prebuilts/build-tools" clone-depth="1" /> <project path="prebuilts/go/linux-x86" name="platform/prebuilts/go/linux-x86" clone-depth="1" /> <project path="build/blueprint" name="platform/build/blueprint" /> <project path="build/kati" name="platform/build/kati" /> <project path="build/soong" name="platform/build/soong"> <linkfile src="root.bp" dest="Android.bp" /> <linkfile src="bootstrap.bash" dest="bootstrap.bash" /> </project> <!-- SDK for system / public API stubs --> <project path="prebuilts/sdk" name="platform/prebuilts/sdk" clone-depth="1" /> <!-- App source --> <project path="system/timezone" name="platform/system/timezone" /> <project path="packages/apps/TimeZoneData" name="platform/packages/apps/TimeZoneData" /> <!-- Enable repohooks --> <project path="tools/repohooks" name="platform/tools/repohooks" revision="master" clone_depth="1" /> <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
Tapas yapısını çalıştırma
Kaynak ağaç oluşturulduktan sonra, aşağıdaki komutları kullanarak tapas derlemesini çağırın:
source build/envsetup.sh
tapas
make -j30 showcommands dist TARGET_BUILD_APPS='TimeZoneData TimeZoneData_test1 TimeZoneData_test2' TARGET_BUILD_VARIANT=userdebug
Başarılı bir derleme, test için out/dist
dizininde dosyalar oluşturur. Bu dosyalar, sistem görüntüsüne dahil edilmek üzere önceden oluşturulmuş dizine yerleştirilebilir ve/veya uyumlu cihazlar için bir uygulama mağazası aracılığıyla dağıtılabilir.