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ı bir modül güncelleme mekanizmasıyla değiştirir. AOSP 8.1 ila 13, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gerekli platform kodunu hâlâ içermektedir; böylece Android 10'a yükseltilen cihazlar, APK aracılığıyla iş ortakları 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 göz ardı edeceğinden) APK güncelleme mekanizması, modül güncellemelerini de alan bir üretim cihazında 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 gün ışığından yararlanma saatini (DST) ve saat dilimlerini güncelleyerek dini, politik ve jeopolitik nedenlerle sık sık değişebilen verileri standart hale getirir.
Güncellemeler aşağıdaki işlemi kullanır:
- IANA, Zaman Dilimi Veritabanında bir güncelleme yayınladı, bir veya daha fazla hükümetin kendi ülkelerindeki 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 ve ardından cihazın saat dilimi verileri, güncellemedeki yeni saat dilimi verilerini içerir.
Modüller hakkında 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 14 ve sonrasında tamamen kaldırılmıştır ve kaynak kodunda bulunamamaktadır. İş ortakları , Saat Dilimi Ana Hattı modülüne tamamen geçiş yapmalıdır.
Android 8.1 ve Android 9'da OEM'ler, güncellenmiş saat dilimi kuralları verilerini sistem güncellemesi gerektirmeden cihazlara göndermek için APK tabanlı bir mekanizma kullanabilir. Bu mekanizma, kullanıcıların güncellemeleri zamanında almasını sağlar (böylece bir Android cihazının kullanım ömrünü uzatır) ve Android iş ortaklarının saat dilimi güncellemelerini sistem görüntüsü güncellemelerinden bağımsız olarak test etmesine olanak tanır.
Android çekirdek kitaplıkları ekibi, hazır bir 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
Bu özelliği kullanmayanlar da dahil olmak üzere tüm stok Android cihazları, saat dilimi kuralları verilerine ihtiyaç duyar ve /system
bölümünde varsayılan bir saat dilimi kuralları verileri kümesiyle birlikte gönderilmelidir. Bu veriler daha sonra Android kaynak ağacındaki aşağıdaki kitaplıklardaki kodlar tarafından kullanılır:
-
libcore/
dan yönetilen kod (örneğin,java.util.TimeZone
),tzdata
vetzlookup.xml
dosyalarını kullanır. -
bionic/
dosyasındaki yerel kitaplık kodu (örneğin,mktime
için yerel zamanlı sistem çağrıları)tzdata
dosyasını kullanır. -
external/icu/
dosyasındaki ICU4J/ICU4C kitaplık kodu, icu.dat
dosyasını kullanır.
Bu kitaplıklar /data/misc/zoneinfo/current
dizininde mevcut olabilecek yer paylaşımlı dosyaların kaydını tutar. Yer paylaşımı dosyalarının iyileştirilmiş saat dilimi kuralları verilerini içermesi ve böylece cihazların /system
değiştirilmeden güncellenmesine olanak sağlanması bekleniyor.
Saat dilimi kuralı verilerine ihtiyaç duyan Android sistem bileşenleri öncelikle aşağıdaki konumları kontrol eder:
-
libcore/
vebionic/
code,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
dizinini 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 de içerir.
İçerik ICU sürümüne, Android platformu gereksinimlerine ve diğer sürüm değişikliklerine göre değiştiği için dağıtım dosyası formatı Android sürümüne bağlıdır. Android, her IANA güncellemesi için desteklenen Android sürümlerine yönelik dağıtım dosyaları sağlar (platform sistem dosyalarının güncellenmesine 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ını oluşturmak için gereken komut dosyalarını ve diğer dosyaları içerir) kullanarak kendi dağıtım dosyalarını oluşturabilir.
Saat dilimi güncelleme bileşenleri
Saat dilimi kuralları güncellemesi, dağıtım dosyalarının bir cihaza iletilmesini ve içindeki dosyaların güvenli bir şekilde kurulmasını içerir. Aktarım ve kurulum aşağıdakileri gerektirir:
- Varsayılan olarak devre dışı olan platform hizmeti işlevi (
timezone.RulesManagerService
). OEM'lerin yapılandırma yoluyla işlevselliği etkinleştirmesi gerekir.RulesManagerService
sistem sunucusu işleminde çalışır ve/data/misc/zoneinfo/staged
dosyasına yazarak saat dilimi güncelleme işlemlerini aşamalar.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 eklemelidir. - 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 eklemelidir. -
tzdatacheck
, saat dilimi güncellemelerinin doğru ve güvenli çalışması için gereken bir önyükleme zamanı ikili programıdır.
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 özelliği doğru şekilde etkinleştirip etkinleştirmediklerini otomatik olarak kontrol edebilmelerini sağlamak için test kodu sağlanmıştı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ından indirme 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 özel Veri uygulaması paketi adındaki değişiklikleri izler.Şekil 1. Veri uygulaması güncellemeleri - Sistem sunucusu işlemi, hedeflenen amacı benzersiz, tek kullanımlık bir belirteçle Güncelleyici Uygulamasına yayınlayarak bir güncelleme kontrolünü tetikler . Sistem sunucusu, tetiklediği en son kontrolün ne zaman tamamlandığını belirleyebilmek için ürettiği en son jetonu takip eder; diğer belirteçler göz ardı edilir.
Şekil 2. Tetikleyici 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 cihaz durumunu sorgular.
Şekil 3. Veri uygulaması güncellemeleri, RulesManagerService'in çağrılması - 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 alma
- RulesManagerService'i çağırarak geçerli cihaz durumunu sorgular.
- Updater uygulaması, sahip olduğu bilgilere göre uygun eylemi gerçekleştirir . Mevcut eylemler şunları içerir:
- Kurulum talebinde bulunun. Dağıtım verileri Data uygulamasından okunur ve sistem sunucusundaki RulesManagerService'e iletilir. RulesManagerService, dağıtım formatı sürümünün ve içeriğinin cihaz için uygun olduğunu yeniden doğrular ve kurulumu aşamalandırır.
- Kaldırma talebinde bulunun (bu nadir görülen bir durumdur). Örneğin,
/data
güncellenmiş APK devre dışı bırakılıyorsa veya kaldırılıyorsa ve cihaz,/system
bulunan sürüme geri dönüyorsa. - Hiçbir şey yapma. Data uygulaması dağıtımının geçersiz olduğu tespit edildiğinde gerçekleşir.
Şekil 5. Kontrol tamamlandı - Yeniden başlatın ve tzdatacheck. Cihaz bir sonraki önyüklemesinde, tzdatacheck ikili dosyası 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çılıp dosyaları kullanmaya başlamadan önce
/data/misc/zoneinfo/current
dosyalarının oluşturulmasını, değiştirilmesini ve/veya silinmesini gerçekleştirerek aşamalı işlemi gerçekleştirin. -
/data
içindeki dosyaların geçerli platform sürümü için doğru olup olmadığını kontrol edin; bu durum, cihazın yeni bir sistem güncellemesi alması ve dağıtım biçimi sürümünün değişmesi durumunda geçerli olmayabilir. - IANA kuralları sürümünün
/system
içindeki sürümle aynı veya daha yeni olduğundan emin olun. Bu, bir sistem güncellemesinin, cihazı/system
görüntüsünde mevcut olandan daha eski saat dilimi kuralları verilerine sahip bırakmasına karşı koruma sağlar.
- Diğer sistem bileşenleri açılıp dosyaları kullanmaya başlamadan önce
Güvenilirlik
Uçtan uca kurulum işlemi eş zamanlı değildir ve üç işletim sistemi işlemine bölünmüştür. Yükleme sırasında herhangi bir noktada aygıtta güç kaybı yaşanabilir, disk alanı tükenebilir veya başka sorunlarla karşılaşılabilir ve bu durum yükleme denetiminin eksik kalmasına neden olabilir. En iyi başarısız durumda, Güncelleyici uygulaması sistem sunucusuna işlemin başarısız olduğunu bildirir; en kötü başarısız durumda RulesManagerService hiçbir çağrı almaz.
Bunu gerçekleştirmek için sistem sunucusu kodu, tetiklenen bir güncelleme denetiminin tamamlanıp tamamlanmadığını ve Data App'in son kontrol edilen sürüm kodunun ne olduğunu takip eder. Cihaz boştayken ve şarj olurken sistem sunucusu kodu mevcut durumu kontrol edebilir. Eksik bir güncelleme kontrolü veya beklenmeyen bir Data App sürümü tespit ederse anında bir güncelleme kontrolü tetikler.
Güvenlik
Etkinleştirildiğinde, sistem sunucusundaki RulesManagerService kodu, sistemin kullanımının güvenli olduğundan emin olmak için çeşitli kontroller gerçekleştirir.
- Kötü yapılandırılmış bir sistem görüntüsünü gösteren sorunlar, aygıtın önyüklenmesini 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, cihazın önyüklenmesini engellemez ancak bir güncelleme kontrolünün tetiklenmesini engeller; örnekler, gerekli sistem izinlerinin eksikliğini veya Veri 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. Tüm APK'larda olduğu gibi Data uygulamasının da /system/priv-app
sürümünü imzalamak için kullanılan anahtarla imzalanması gerekir. Data uygulamasının özel, OEM'e özel bir paket adına ve anahtarına sahip olması bekleniyor.
Saat dilimi güncellemelerini entegre etme
Saat dilimi güncelleme özelliğini etkinleştirmek için OEM'ler genellikle:
- Kendi Veri uygulamalarını oluşturun.
- Güncelleyici ve Veri uygulamalarını sistem görüntüsü oluşturmaya ekleyin.
- RulesManagerService'i etkinleştirmek için sistem sunucusunu yapılandırın.
Hazırlanıyor
Başlamadan önce OEM'ler aşağıdaki politikayı, kalite güvencesini ve güvenlik hususlarını incelemelidir:
- Veri uygulamaları için uygulamaya özel özel bir imzalama anahtarı oluşturun.
- Hangi cihazların güncelleneceğini ve güncellemelerin yalnızca onlara ihtiyaç duyan cihazlara yüklenmesini nasıl sağlayabileceklerini anlamak amacıyla saat dilimi güncellemeleri için bir yayın 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 QA stratejisini etkiler.
- AOSP'den stok Android saat dilimi verilerini mi kullanmak istediklerini, yoksa kendilerininkini mi oluşturmak istediklerini anlayın.
Veri uygulaması oluşturma
AOSP packages/apps/TimeZoneData
konumunda bir Veri uygulaması oluşturmak için gereken tüm kaynak kodunu ve derleme kurallarını, AndroidManifest.xml
ve packages/apps/TimeZoneData/oem_template
konumunda bulunan diğer dosyalar için talimatlar ve örnek şablonlarla birlikte içerir. Örnek şablonlar, hem gerçek Veri uygulaması APK'sı için bir derleme hedefi hem de Veri uygulamasının test sürümlerini oluşturmaya yönelik ekstra 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ığı için 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çlanmaktadır. Tapas kullanımına ilişkin 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. OEM'ler, önceden oluşturulmuş APK'ları (tapas oluşturma işlemi tarafından oluşturulan) sistem görüntüsüne dahil etmek için packages/apps/TimeZoneData/oem_template/data_app_prebuilt
içindeki örnek dosyaları kopyalayabilir. Örnek şablonlar ayrıca Veri uygulamasının test sürümlerini test paketlerine dahil etmeye yönelik derleme hedeflerini de 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ü derlemesinin Güncelleyici uygulamasını ve Veri uygulaması önceden oluşturulmuş hedeflerini açıkça içermesi gerekir.
Güncelleyici uygulaması platform anahtarıyla imzalanmalı ve diğer herhangi bir sistem uygulamasına dahil edilmelidir. Hedef, packages/apps/TimeZoneUpdater
dosyasında TimeZoneUpdater
olarak tanımlanır. Data 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
dosyasında 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ında yapılan değişiklikleri dinlemesi için true olarak ayarlanması gerekir. | 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ılmıştır. Yalnızca farklı bir Güncelleyici uygulaması uygulaması sağlarken değiştirin. | HAYIR |
config_timeZoneRulesCheckTimeMillisAllowed | RulesManagerService tarafından tetiklenen güncelleme kontrolü ile yükleme, kaldırma veya hiçbir şey yapmama yanıtı arasında izin verilen süre. Bu noktadan sonra kendiliğinden bir güvenilirlik tetikleyicisi oluşturulabilir. | HAYIR |
config_timeZoneRulesCheckRetryCount | RulesManagerService daha fazla üretmeyi durdurmadan önce izin verilen ardışık başarısız güncelleme kontrollerinin sayısı. | HAYIR |
Yanlış yapılandırılmış bir aygıt önyüklemeyi reddedebileceğinden, yapılandırma geçersiz kılmaları sistem görüntüsünde (satıcı veya başka bir şey değil) olmalıdır. Yapılandırma geçersiz kılmaları satıcı görüntüsünde olsaydı, Veri uygulaması olmadan (veya farklı Veri uygulaması/Güncelleyici uygulaması paket adlarıyla) bir sistem görüntüsüne güncelleme yapmak yanlış yapılandırma olarak kabul edilir.
xTS testi
xTS, Tradefed'i (CTS ve VTS gibi) kullanan standart Android test paketlerine benzer, OEM'e özgü herhangi bir test paketini ifade eder. 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 otomatik işlevsel testler için gereken kodu içerir. -
packages/apps/TimeZoneData/oem_template/xts
Tradefed benzeri bir xTS paketindeki testleri dahil etmek için örnek bir dizin yapısı içerir. Diğer şablon dizinlerinde olduğu gibi, OEM'lerin de kopyalayıp ihtiyaçlarına göre özelleştirmeleri bekleniyor. -
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 kuralları kümesi 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, bunları 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 istiyorsa işlemi üç kez tamamlaması gerekir.
1. Adım: Sistem/saat dilimini ve harici/icu veri dosyalarını güncelleme
Bu adımda, OEM'ler system/timezone
ve external/icu
için AOSP'deki sürüm -dev dallarından stok Android taahhütlerini alır ve bu taahhütleri 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, ardından system/timezone/input_data
ve external/icu
içindeki dosyaları kullanarak output_data
içinde dosyalar oluşturabilir.
En önemli dosya, Data uygulaması APK'sı oluşturulduğunda otomatik olarak dahil edilen system/timezone/output_data/distro/distro.zip
dosyasıdır.
2. Adım: Data uygulamasının sürüm kodunu güncelleme
Bu adımda OEM'ler Data uygulamasının sürüm kodunu günceller. Derleme otomatik olarak distro.zip
dosyasını alır, ancak Veri uygulamasının yeni sürümünün yeni bir sürüm koduna sahip olması gerekir; böylece yeni olarak tanınır 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ılır.
package/apps/TimeZoneData/oem_template/data_app
dosyasından kopyalanan dosyaları kullanarak Veri uygulamasını oluştururken, APK'ya uygulanan sürüm kodunu/sürüm adını Android.mk
bulabilirsiniz:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Benzer girişler testing/Android.mk
dosyasında 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 stratejisi şemasına bakın; örnek şema veya benzer bir şema kullanılırsa test sürümü kodlarının güncellenmesine gerek yoktur çünkü bunların gerçek sürüm kodlarından daha yüksek olacağı garanti edilir.
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'yı 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ı Data app önceden oluşturulmuş dizinine gönderin. OEM'lerin yeni dosyanın doğru çalıştığını (yani CTS'yi ve OEM'e özel otomatik ve manuel testleri geçtiğini) test etmesi gerekir.
- Artık sistem güncellemelerini almayan, piyasaya sürülen cihazlar için imzalı APK yalnızca bir uygulama mağazası aracılığıyla yayınlanabilir.
OEM'ler, kalite güvencesinden ve güncellenen Veri uygulamasının yayınlanmadan önce cihazlarında test edilmesinden sorumludur.
Veri uygulaması sürüm kodu stratejisi
Veri uygulamasının, cihazların doğru APK'ları almasını sağlamak için uygun bir sürüm oluşturma stratejisine sahip 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:
- Distro formatı sürümü (majör + minör)
- Artan (opak) 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 ICU'nun yeni bir sürümüyle ilişkilendirilir (bu da dağıtım dosyalarını uyumsuz hale getirir). Gelecekte Android, bir dağıtım dosyasının birden çok Android platformu sürümünde çalışabilmesi için bunu değiştirebilir (ve Veri uygulaması sürüm kodu şemasında API düzeyi kullanılmaz).
Örnek sürüm kodu stratejisi
Bu örnek sürüm 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 işleyebileceklerinden 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ç |
---|---|---|
e | Rezerve | Gelecekteki alternatif şemalara/test APK'larına izin verir. Başlangıçta (örtük olarak) 0'dır. Temel tür imzalı bir 32 bit int türü olduğundan, bu şema gelecekteki en fazla iki numaralandırma şeması revizyonunu destekler. |
01 | Ana format sürümü | 3 ondalık basamaklı ana format sürümünü izler. Dağıtım formatı 3 ondalık basamağı destekler ancak burada yalnızca 2 basamak kullanılır. API düzeyi başına beklenen büyük artış dikkate alındığında 100'e ulaşması pek olası değildir. Ana sürüm 1, API düzeyi 27'ye eşdeğerdir. |
1 | Küçük formatlı versiyon | 3 ondalık basamaklı küçük formatlı sürümü izler. Dağıtım formatı 3 ondalık basamağı destekler ancak burada yalnızca 1 basamak kullanılır. 10'a ulaşması 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ı. Gerektiğinde geçiş güncellemesi yapılmasına olanak sağlayacak boşluklar içerir. |
Ondalık sayı yerine ikili sayı kullanılsaydı şema daha iyi paketlenebilirdi, ancak bu şemanın insan tarafından okunabilir olma avantajı vardır. Tam sayı aralığı tükenirse Veri uygulaması paketinin 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österilmektedir.
# | Sürüm kodu | minSdkVersiyonu | {Ana biçim sürümü},{Küçük biçim sürümü},{IANA kuralları sürümü},{Revizyon} |
---|---|---|---|
1 | 11000010 | O-MR1 | majör=001,minör=001,iana=2017a,revizyon=1 |
2 | 21000010 | P | majör=002,minör=001,iana=2017a,revizyon=1 |
3 | 11000020 | O-MR1 | majör=001,minör=001,iana=2017a,revizyon=2 |
4 | 11000030 | O-MR1 | majör=001,minör=001,iana=2017b,revizyon=1 |
5 | 21000020 | P | majör=002,minör=001,iana=2017b,revizyon=1 |
6 | 11000040 | O-MR1 | majör=001,minör=001,iana=2018a,revizyon=1 |
7 | 21000030 | P | majör=002,minör=001,iana=2018a,revizyon=1 |
8 | 1123456789 | - | - |
9 | 11000021 | O-MR1 | majör=001,minör=001,iana=2017a,revizyon=2,respin=2 |
- Örnek 1 ve 2, aynı 2017a IANA sürümü için farklı ana format 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 yüksektir.
- Örnek 4 ve 5, O-MR1 ve P'nin 2017b sürümlerini göstermektedir. Sayısal olarak daha yüksek olduklarından, ilgili öncüllerin önceki IANA sürümlerinin/Android revizyonlarının yerine geçerler.
- Ö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östermektedir.
- Örnek 9, apk'yi yeniden döndürmek için 3 ile 4 arasında kalan boşluğun kullanımını göstermektedir.
Her cihaz, sistem görüntüsünde varsayılan, uygun şekilde sürümlendirilmiş bir APK ile birlikte gönderildiğinden, 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. /data
O-MR1 sürümü yüklü olan ve daha sonra P'ye sistem güncellemesi alan bir cihaz /data
O-MR1 sürümü yerine /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 Verileri 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çlanmaktadır.
Tapas, uygulamaların dağıtılabilir sürümlerini üretmek için azaltılmış bir kaynak ağacı kullanan Android derleme sisteminin zayıflatılmış bir sürümüdür. Normal Android derleme sistemine aşina olan OEM'ler, normal Android platformu derlemesindeki derleme dosyalarını tanımalıdır.
Manifesto oluşturma
Azaltılmış bir kaynak ağacı genellikle yalnızca derleme sisteminin ve uygulamayı oluşturmak için ihtiyaç duyulan Git projelerine atıfta bulunan özel bir bildirim dosyasıyla elde edilir. Veri uygulaması oluşturma bölümündeki talimatları izledikten sonra OEM'lerin packages/apps/TimeZoneData/oem_template
altındaki şablon dosyaları kullanılarak oluşturulmuş en az iki OEM'e özgü Git projesine sahip olması gerekir:
- Bir Git projesi, manifest gibi uygulama dosyalarını ve uygulama APK dosyasını oluşturmak için gereken derleme dosyalarını içerir (örneğin,
vendor/ oem /apps/TimeZoneData
). Bu proje aynı zamanda xTS testleri tarafından kullanılabilecek test APK'ları için derleme kuralları da 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 birçok Git projesinden yararlanır.
Aşağıdaki bildirim parçacığı, saat dilimi Veri uygulamasının O-MR1 yapısını desteklemek için gereken minimum Git projesi kümesini içerir. OEM'ler, OEM'e özgü Git projelerini (genellikle imzalama sertifikasını içeren bir projeyi içerir) bu bildirime eklemelidir ve farklı dalları buna göre 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="main" clone_depth="1" /> <repo-hooks in-project="platform/tools/repohooks" enabled-list="pre-upload" />
Tapas yapısını çalıştırma
Kaynak ağacı oluşturulduktan sonra aşağıdaki komutları kullanarak tapas yapısını ç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 eklenmek üzere önceden oluşturulmuş dizine yerleştirilebilir ve/veya uyumlu cihazlar için bir uygulama mağazası aracılığıyla dağıtılabilir.