Android 10, APK tabanlı saat dilimi veri güncelleme mekanizmasını (Android 8.1 ve Android 9'da kullanılabilir) kullanımdan kaldırır ve APEX tabanlı bir modül güncelleme mekanizmasıyla değiştirir. AOSP 8.1 ile 13, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gereken platform kodunu hâlâ içerir. Bu nedenle, Android 10'a yükseltilen cihazlar, iş ortağı tarafından sağlanan saat dilimi veri güncellemelerini APK üzerinden almaya devam edebilir. Ancak APK güncelleme mekanizması, aynı zamanda modül güncellemelerini APK tabanlı bir güncelleme olarak alan üretim cihazlarında, APEX tabanlı güncellemelerin yerini alan üretim cihazlarında (yani APK güncellemesi alan bir cihaz, APEX tabanlı güncellemeleri yoksayar) kullanılmamalıdır.
Saat dilimi güncellemeleri (Android 10 ve sonraki sürümler)
Android 10 ve sonraki sürümlerde desteklenen Saat Dilimi Verileri modülü, Android cihazlarda yaz saatini 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, bir veya daha fazla hükümetin ülkelerindeki saat dilimi kuralını değiştirmesine yanıt olarak Saat Dilimi Veritabanı'nda güncelleme yayınlar.
- Google veya Android iş ortağı, güncellenmiş saat dilimlerini içeren bir Saat Dilimi Verileri modülü güncellemesi (APEX dosyası) hazırlar.
- Son kullanıcı cihazı güncellemeyi indirir, yeniden başlatır ve değişiklikleri uygular. Ardından cihazın saat dilimi verileri, güncellemedeki yeni saat dilimi verilerini içerir.
Modüller hakkında ayrıntılı bilgi için Modüler Sistem Bileşenleri başlıklı makaleyi inceleyin.
Saat dilimi güncellemeleri (Android 8.1-9)
Not: APK tabanlı saat dilimi verilerini güncelleme mekanizması özelliği, Android 14 ve sonraki sürümlerden tamamen kaldırılmıştır ve kaynak kodunda bulunamıyor. İş ortakları, Saat Dilimi Ana modülüne tamamen taşınmalıdır.
Android 8.1 ve Android 9'da OEM'ler, sistem güncellemesi gerekmeden güncellenmiş saat dilimi kuralları verilerini cihazlara göndermek için APK tabanlı bir mekanizma kullanabilir. Bu mekanizma, kullanıcıların zamanında güncelleme almasını (böylece Android cihazın kullanım süresini uzatmasını) ve Android iş ortaklarının saat dilimi güncellemelerini sistem resmi güncellemelerinden bağımsız olarak test etmesini sağlar.
Android temel kitaplıklar ekibi, stok Android cihazda 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 ederlerse kendi veri dosyalarını oluşturabilirler. OEM'ler, desteklenen cihazlarının saat dilimi kural güncellemelerinin kalite güvencesi/testi, zamanlaması ve lansmanı üzerinde her durumda kontrol sahibidir.
Android saat dilimi kaynak kodu ve verileri
Bu özelliği kullanmayan cihazlar da dahil olmak üzere tüm stok Android cihazlarda saat dilimi kuralları verileri gerekir ve /system bölümünde varsayılan bir saat dilimi kuralları veri grubuyla birlikte gönderilmelidir. Bu veriler daha sonra Android kaynak ağacındaki aşağıdaki kitaplıklardaki kod tarafından kullanılır:
libcore/'ten gelen yönetilen kod (ör.java.util.TimeZone),tzdatavetzlookup.xmldosyalarını kullanır.bionic/içindeki yerel kitaplık kodu (ör.mktime, localtime sistem çağrıları için),tzdatadosyasını kullanır.external/icu/içindeki ICU4J/ICU4C kitaplık kodu, icu.datdosyasını kullanır.
Bu kitaplıklar, /data/misc/zoneinfo/current dizininde bulunabilecek yer paylaşımı dosyalarını izler. Yer paylaşımı dosyalarının, iyileştirilmiş saat dilimi kuralları verileri içermesi ve böylece cihazların /system değiştirilmeden güncellenmesini sağlaması beklenir.
Saat dilimi kuralı verilerine ihtiyaç duyan Android sistem bileşenleri öncelikle aşağıdaki konumları kontrol eder:
libcore/vebionic/kodu,tzdatavetzlookup.xmldosyalarının/datakopyasını kullanır.- ICU4J/ICU4C kodu,
/dataiçindeki dosyaları kullanır ve mevcut olmayan veriler için (biçimler, yerelleştirilmiş dizeler vb.)/systemdosyalarına geçer.
Distro dosyaları
Distro .zip dosyaları, /data/misc/zoneinfo/current dizinini doldurmak için gereken veri dosyalarını içerir. Dağıtım dosyaları, cihazların sürüm sorunlarını algılamasına olanak tanıyan meta veriler de içerir.
Distro dosya biçimi Android sürümüne bağlıdır çünkü içeriğin ICU sürümüne, Android platform şartlarına ve sürümdeki diğer değişikliklere göre değişmesidir. Android, her IANA güncellemesi için (platform sistem dosyalarını güncellemenin yanı sıra) desteklenen Android sürümleri için dağıtım dosyaları sağlar. 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 aktarılmasını ve içindeki dosyaların güvenli bir şekilde yüklenmesini içerir. Aktarım ve kurulum için aşağıdakiler gereklidir:
- Varsayılan olarak devre dışı olan platform hizmeti işlevi (
timezone.RulesManagerService). OEM'ler bu işlevi yapılandırma üzerinden etkinleştirmelidir.RulesManagerService, sistem sunucusu işleminde çalışır ve saat dilimi güncelleme işlemlerini/data/misc/zoneinfo/stagedadresine yazarak aşamalar.RulesManagerService, önceden aşamalandırılmış işlemleri de değiştirebilir veya silebilir. -
Güncellenemeyecek bir sistem uygulaması olan
TimeZoneUpdater(diğer adıyla Güncelleme uygulaması). OEM'ler bu uygulamayı, özelliği kullanan cihazların sistem resmine eklemelidir. - OEM
TimeZoneData, dağıtım dosyalarını cihaza taşıyan ve Yükleyici uygulamasına sunan güncellenebilir bir sistem uygulamasıdır (diğer adıyla Veri uygulaması). OEM'ler bu uygulamayı, özelliği kullanan cihazların sistem resmine eklemelidir. -
tzdatacheck, saat dilimi güncellemelerinin doğru ve güvenli bir şekilde çalışması için gereken önyükleme zamanı ikili dosyası.
Android kaynak ağacı, yukarıdaki bileşenler için OEM'nin değişiklik yapmadan kullanabileceği genel kaynak kod içerir. Test kodu, OEM'lerin özelliği doğru şekilde etkinleştirip etkinleştirmediklerini otomatik olarak kontrol etmelerini sağlamak için sağlanır.
Dağıtım kurulumu
Dağıtım yükleme işlemi aşağıdaki adımları içerir:
- Veri uygulaması, uygulama mağazasından indirme veya harici yükleme yoluyla güncellenir. Sistem sunucusu işlemi (
timezone.RulesManagerServer/timezone.PackageTrackersınıfları aracılığıyla), yapılandırılmış, OEM'e özgü Veri uygulaması paket adında yapılan değişiklikleri izler.
Şekil 1. Veri uygulaması güncellemeleri.
- Sistem sunucusu işlemi, tek kullanımlık benzersiz bir jeton içeren hedeflenmiş bir intent'i Güncelleme Uygulaması'na yayınlayarak güncelleme kontrolünü tetikler. Sistem sunucusu, tetiklediği en son kontrolün ne zaman tamamlandığını belirleyebilmek için oluşturduğu en son jetonu izler. Diğer jetonlar yoksayılır.
Şekil 2. Güncelleme kontrolünü tetikleyin.
- Güncelleme kontrolü sırasında Güncelleme Uygulaması aşağıdaki görevleri gerçekleştirir:
- Kural Yöneticisi Hizmeti'ni çağırarak geçerli cihaz durumunu sorgular.
Şekil 3. RulesManagerService'i çağıran veri uygulaması güncellemeleri.
- Dağıtımla ilgili bilgi almak için iyi tanımlanmış bir ContentProvider URL'sini ve sütun özelliklerini sorgulayarak Veriler uygulamasını sorgulayın.
Şekil 4. Veri uygulaması güncellemeleri, dağıtım hakkında bilgi edinme.
- Kural Yöneticisi Hizmeti'ni çağırarak geçerli cihaz durumunu sorgular.
- Güncelleme Aracı uygulaması, sahip olduğu bilgilere göre uygun işlemi yapar. Kullanılabilir işlemler şunlardır:
- Yükleme isteğinde bulunun. Distro 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 cihaz için uygun olduğunu yeniden onaylar ve yüklemeyi aşamalara ayırır.
- Kaldırma isteğinde bulunun (Bu nadiren görülür). Örneğin,
/data'teki güncellenmiş APK devre dışı bırakılıyor veya kaldırılıyorsa ve cihaz/system'teki sürüme geri dönüyorsa. - Hiçbir işlem yapmamayı tercih edebilirsiniz. Veri uygulaması dağıtımının geçersiz olduğu tespit edildiğinde gerçekleşir.
5. Şekil. Kontrol tamamlandı.
- Yeniden başlatma ve tzdatacheck. Cihaz bir sonraki başlatıldığında tzdatacheck ikili programı, tüm aşamalı işlemleri yürütür. tzdatacheck ikili dosyası aşağıdaki görevleri gerçekleştirebilir:
- Diğer sistem bileşenleri dosyaları açmadan ve kullanmaya başlamadan önce
/data/misc/zoneinfo/currentdosyalarının oluşturulmasını, değiştirilmesini ve/veya silinmesini yöneterek aşamalı işlemi yürütün. /dataiçindeki dosyaların mevcut platform sürümü için doğru olup olmadığını kontrol edin. Cihaz kısa süre önce bir sistem güncellemesi aldıysa ve dağıtım biçimi sürümü değiştiyse bu durum geçerli olmayabilir.- IANA kuralları sürümünün,
/system'teki sürümle aynı veya daha yeni olduğundan emin olun. Bu,/systemgörüntüsündekinden daha eski saat dilimi kuralları verilerine sahip bir cihaz bırakan sistem güncellemesine karşı koruma sağlar.
- Diğer sistem bileşenleri dosyaları açmadan ve kullanmaya başlamadan önce
Güvenilirlik
Uçtan uca yükleme süreci eşzamansız olup üç işletim sistemi işlemine bölünmüştür. Yükleme sırasında cihazın gücü kesilebilir, disk alanı tükenebilir veya başka sorunlarla karşılaşılabilir. Bu da yükleme kontrolünün tamamlanamaması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ü durumda, RulesManagerService hiç çağrı almaz.
Sistem sunucu kodu, bu sorunu gidermek için tetiklenen bir güncelleme kontrolünün tamamlanıp tamamlanmadığını ve Veri Uygulaması'nın en son kontrol edilen sürüm kodunu izler. Cihaz boştayken ve şarj olurken sistem sunucu kodu mevcut durumu kontrol edebilir. Eksik bir güncelleme kontrolü veya beklenmedik bir Veri Uygulaması sürümü tespit ederse kendiliğinden bir güncelleme kontrolünü tetikler.
Güvenlik
Etkinleştirildiğinde, sistem sunucusunda RulesManagerService kodu, sistemin güvenli bir şekilde kullanılmasını sağlamak için çeşitli kontroller gerçekleştirir.
- Kötü yapılandırılan bir sistem görüntüsünü gösteren sorunlar, cihazın başlatılmasını engeller. Örneğin, güncelleyici veya Veri uygulamasının kötü bir şekilde yapılandırılması ya da güncelleyici veya Veri uygulamasının
/system/priv-app'te bulunmaması bu sorunlara örnek gösterilebilir. - Hatalı bir Veri uygulamasının yüklü olduğunu belirten sorunlar, cihazın başlatılmasını engellemez ancak güncelleme kontrolünün tetiklenmesini engeller. Örneğin, gerekli sistem izinlerinin olmaması veya Veri uygulamasının beklenen URI'de bir ContentProvider göstermemesi bu sorunlara örnek olarak verilebilir.
/data/misc/zoneinfo dizinlerinin dosya izinleri SELinux kuralları kullanılarak uygulanır. Tüm APK'larda olduğu gibi, Veri uygulaması da /system/priv-app sürümünü imzalamak için kullanılan anahtarla imzalanmalıdır. Veri uygulamasının OEM'ye özel bir paket adı ve anahtarı olması gerekir.
Saat dilimi güncellemelerini entegre etme
Saat dilimi güncelleme özelliğini etkinleştirmek için OEM'ler genellikle:
- Kendi veri uygulamalarını oluşturabilirler.
- Güncelleme ve Veri uygulamalarını sistem resmi derlemesine ekleyin.
- Sistem sunucusunu, RulesManagerService'i etkinleştirecek şekilde yapılandırın.
Hazırlık
OEM'ler başlamadan önce aşağıdaki politikayı, kalite güvencesi ve güvenlikle ilgili hususları incelemelidir:
- Veri uygulaması için uygulamaya özel bir imzalama anahtarı oluşturun.
- Hangi cihazların güncelleneceğini ve güncellemelerin yalnızca ihtiyaç duyulan 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ı kullanmak isteyebilir veya farklı cihazlar için farklı Veri uygulamaları kullanmayı tercih edebilir. Bu karar, paket adı seçimini, muhtemelen kullanılan sürüm kodlarını ve QA stratejisini etkiler.
- AOSP'deki stok Android saat dilimi verilerini mi yoksa kendi verilerini mi kullanmak istediklerini öğrenin.
Veri uygulaması oluştur
AOSP, packages/apps/TimeZoneData'te veri uygulaması oluşturmak için gereken tüm kaynak kodu ve derleme kurallarını içerir. Ayrıca, AndroidManifest.xml ve packages/apps/TimeZoneData/oem_template'deki diğer dosyalar için talimatlar ve örnek şablonlar da sağlar. Örnek şablonlar arasında 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 bulunur.
OEM'ler Veri uygulamasını kendi simgesi, adı, ç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ı, sistem görüntüsüne eklenmeye (ilk sürüm için) uygun APK'lar üreten ve bir uygulama mağazasında imzalayıp dağıtılan (sonraki güncellemeler için) bir tapas derlemesiyle oluşturulmak üzere tasarlanmıştır. Tapas kullanmayla ilgili ayrıntılar için Tasma kullanarak veri uygulaması oluşturma bölümüne bakın.
OEM'ler, /system/priv-app'te bir cihazın sistem resmine önceden yerleşik olarak Veri uygulamasını yüklemelidir. OEM'ler, önceden oluşturulmuş APK'ları (tapas derleme işlemi tarafından oluşturulur) sistem görüntüsüne eklemek için packages/apps/TimeZoneData/oem_template/data_app_prebuilt içindeki örnek dosyaları kopyalayabilir. Örnek şablonlar, Veri uygulamasının test sürümlerini test paketlerine dahil etmek için derleme hedeflerini de içerir.
Güncelleme ve Veri uygulamalarını sistem görüntüsüne ekleme
OEM'ler, Güncelleyici ve Veri uygulaması APK'larını sistem görüntüsünün /system/priv-app dizinine yerleştirmelidir. Bunun için sistem resmi derlemesi, Updater uygulaması ve Veri uygulaması önceden derlenmiş hedeflerini açıkça içermelidir.
Güncelleme uygulaması, platform anahtarıyla imzalanmalı ve diğer sistem uygulamaları gibi eklenmelidir. Hedef, packages/apps/TimeZoneUpdater içinde TimeZoneUpdater olarak tanımlanır. Veri uygulamasının dahil edilmesi OEM'ye özeldir ve ön derleme için seçilen hedef ada bağlıdır.
Sistem sunucusunu yapılandırma
OEM'ler, saat dilimi güncellemelerini etkinleştirmek için 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.
| Özellik | Açıklama | Geçersiz kılma işlemi 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 özgü Veri uygulamasının paket adı. | Evet |
config_timeZoneRulesUpdaterPackage |
Varsayılan Güncelleme Uygulaması için yapılandırılmıştır. Yalnızca farklı bir Güncelleme Uygulaması uygulaması sağladığınızda değiştirin. | Hayır |
config_timeZoneRulesCheckTimeMillisAllowed |
RulesManagerService tarafından tetiklenen bir güncelleme kontrolü ile yükleme, kaldırma veya hiçbir şey yapma yanıtı arasında izin verilen süre. Bu noktadan sonra spontane bir güvenilirlik tetikleyicisi oluşturulabilir. | Hayır |
config_timeZoneRulesCheckRetryCount |
RulesManagerService'in daha fazla oluşturmayı durdurmasından önce izin verilen art arda başarısız güncelleme kontrollerinin sayısı. | Hayır |
Yanlış yapılandırılmış bir cihaz önyüklemeyi reddedebileceğinden yapılandırma geçersiz kılma işlemleri sistem resminde (tedarikçi veya başka bir yerde değil) olmalıdır. Yapılandırma geçersiz kılma işlemi tedarikçi firma görüntüsündeyse Veri uygulaması olmayan bir sistem görüntüsüne (veya farklı Veri uygulaması/Güncelleme 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'i kullanan standart Android test paketlerine (CTS ve VTS gibi) benzer OEM'ye özel test paketlerini 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 test için gereken kodu içerir.packages/apps/TimeZoneData/oem_template/xts, Tradefed benzeri bir xTS paketine test eklemek için örnek bir dizin yapısı içerir. Diğer şablon dizinlerinde olduğu gibi, OEM'lerin bu şablonları kopyalayıp ihtiyaçlarına göre özelleştirmesi beklenir.packages/apps/TimeZoneData/oem_template/data_app_prebuilt, test için gereken önceden derlenmiş test APK'larını dahil etmek üzere derleme zamanı yapılandırmasını içerir.
Saat dilimi güncellemeleri oluşturma
IANA yeni bir saat dilimi kuralı grubu yayınladığında Android temel 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 uygulaması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, güncellemek istedikleri her desteklenen 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üncelleme sağlamak istiyorsa süreci üç kez tamamlamalıdır.
1. Adım: Sistem/saat dilimi ve harici/icu veri dosyalarını güncelleyin
Bu adımda OEM'ler, AOSP'deki release-dev dallarından system/timezone ve external/icu için stok Android taahhütlerini alır ve bu taahhütleri Android kaynak kodunun kopyalarına uygular.
Sistem/saat dilimi AOSP yaması, system/timezone/input_data ve system/timezone/output_data dosyalarında güncellenmiş dosyalar içerir. Ek yerel düzeltmeler yapması gereken OEM'ler, giriş dosyalarını değiştirebilir ve ardından output_data'de dosya oluşturmak için system/timezone/input_data ve external/icu'deki dosyaları kullanabilir.
Veri uygulaması APK'sı derlenirken otomatik olarak dahil edilen en önemli dosya system/timezone/output_data/distro/distro.zip dosyasıdır.
2. Adım: Veri uygulamasının sürüm kodunu güncelleyin
Bu adımda OEM'ler Veri uygulamasının sürüm kodunu günceller. Derleme, distro.zip değerini otomatik olarak alır ancak Veri uygulamasının yeni sürümünde yeni bir sürüm kodu olmalıdır. Böylece yeni sürüm yeni olarak tanınır ve önceden yüklenmiş bir Veri uygulamasının veya bir önceki güncellemeyle cihaza yüklenen bir Veri uygulamasının yerini alır.
package/apps/TimeZoneData/oem_template/data_app'ten kopyalanan dosyaları kullanarak Veri uygulamasını oluştururken APK'ya uygulanan sürüm kodunu/sürüm adını Android.mk içinde bulabilirsiniz:
TIME_ZONE_DATA_APP_VERSION_CODE := TIME_ZONE_DATA_APP_VERSION_NAME :=
Benzer girişler testing/Android.mk ürününde de bulunabilir (ancak test sürüm kodları, sistem görüntü sürümünden 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 gerçek sürüm kodlarından daha yüksek oldukları garanti edildiğinden test sürüm kodlarının güncellenmesi gerekmez.
3. Adım: Yeniden derleyin, imzalayın, test edin ve yayınlayın
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ış cihazlarda (veya yayınlanmış bir cihaz için sistem güncellemesi hazırlarken), sistem görüntüsü ve xTS testlerinin en yeni APK'lara sahip olduğundan emin olmak için Veri uygulaması önceden oluşturulmuş dizinine yeni APK'ları gönderin. OEM'ler, yeni dosyanın düzgün çalıştığını (yani CTS'yi ve OEM'ye özgü otomatik ve manuel testleri geçtiğini) test etmelidir.
- Artık sistem güncellemesi almayan cihazlarda, imzalanmış APK yalnızca bir uygulama mağazası üzerinden yayınlanabilir.
OEM'ler, güncellenmiş Veri uygulamasının kalite güvencesinden ve cihazlarında yayınlanmadan önce test edilmesinden sorumludur.
Veri uygulaması sürüm kodu stratejisi
Cihazların doğru APK'ları alması için Veri uygulamasının uygun bir sürüm stratejisine sahip olması gerekir. Örneğin, uygulama mağazasından indirilen APK'dan 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ü (ana + alt)
- Artan (opak) sürüm numarası
Şu anda platform API düzeyi ile distro biçimli sürüm arasında güçlü bir ilişki vardır. Bunun nedeni, her API düzeyi genellikle yeni ICU sürümüyle ilişkilendirilmiş olmasıdır. Bu da dağıtım dosyalarını uyumsuz hale getirir. Gelecekte Android, bir dağıtım dosyasının birden fazla Android platform sürümünde çalışabilmesi için bu durumu değiştirebilir (ve API düzeyi, Veri uygulaması sürüm kodu şemasında kullanılmaz).
Örnek sürüm kodu stratejisi
Bu örnek sürüm oluşturma numarası şeması, yüksek dağıtım biçimli sürümlerin düşük dağıtım biçimli sürümlerin yerini almasını sağlar.
AndroidManifest.xml, eski cihazların işleyemeyeceğinden daha yüksek bir dağıtım biçimi sürümüne sahip sürümler almasını önlemek için android:minSdkVersion kullanır.
Şekil 6. Örnek sürüm kodu stratejisi.
| Örnek | Değer | Amaç |
|---|---|---|
| Y | Rezervasyon yapıldı | Gelecekteki alternatif şemalara/test APK'larına izin verir. Başlangıçta (dolaylı olarak) 0'dır. Temel tür, imzalı 32 bit int türü olduğu için bu şema, gelecekte iki tane numaralandırma şeması düzeltmesini destekler. |
| 01 | Ana format 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şılması pek olası değildir. 1 ana sürümü, API düzeyi 27'ye eşdeğerdir. |
| 1 | Alt biçim sürümü | 3 ondalık basamaklı alt sürüm biçimindeki sürümü izler. Dağıtım biçimi 3 ondalık basamağı destekler ancak burada yalnızca 1 basamak kullanılır. 10'a ulaşması pek olası değildir. |
| X | Rezervasyon yapıldı | Üretim sürümleri için 0'dır (test APK'ları için farklı olabilir). |
| ZZZZZ | Saydam olmayan sürüm numarası | Talebe göre ayrılan ondalık sayı. Gerekirse geçiş reklamı güncellemelerinin yapılmasına olanak tanıyan boşluklar içerir. |
Ondalık sayı yerine ikili program kullanılsaydı şema daha iyi paketlenebilirdi ancak bu şema, kullanıcılar tarafından okunabilme avantajına sahiptir. Tam sayı aralığı tükenirse Veriler uygulamasının paket adı değişebilir.
Sürüm adı, ayrıntıların kullanıcılar tarafından okunabilir bir temsilidir (ör. major=001,minor=001,iana=2017a, revision=1,respin=2).
Örnekler aşağıdaki tabloda gösterilmektedir.
| # | Sürüm kodu | minSdkVersion | {Başlıca biçim sürümü},{Alt biçim sürümü},{IANA kuralları sürümü},{Düzeltme} |
|---|---|---|---|
| 1 | 11000010 | O-MR1 | major=001,minor=001,iana=2017a,revision=1 |
| 2 | 21000010 | P | major=002,minor=001,iana=2017a,revision=1 |
| 3 | 11000020 | O-MR1 | ana=001,minor=001,iana=2017a,düzeltme=2 |
| 4 | 11000030 | O-MR1 | major=001,minor=001,iana=2017b,revision=1 |
| 5 | 21000020 | P | major=002,minor=001,iana=2017b,revision=1 |
| 6 | 11000040 | O-MR1 | major=001,minor=001,iana=2018a,revision=1 |
| 7 | 21000030 | P | ana=002,minor=001,iana=2018a,düzeltme=1 |
| 8 | 1123456789 | - | - |
| 9 | 11000021 | O-MR1 | ana=001,minor=001,iana=2017a,düzeltme=2,respin=2 |
- 1. ve 2. örneklerde, aynı 2017a IANA sürümü için farklı ana biçim sürümlerine sahip iki APK sürümü gösterilmektedir. 2, sayısal olarak 1'den daha yüksektir. Bu, yeni cihazların daha yüksek biçim sürümlerini almasını sağlamak için gereklidir. minSdkVersion, O cihazlara P sürümünün sağlanmamasını sağlar.
- 3. örnek, 1 için bir düzeltme/düzeltmedir ve sayısal olarak 1'den yüksektir.
- 4. ve 5. örneklerde, O-MR1 ve P için 2017b sürümleri gösterilmektedir. Sayısal olarak daha yüksek olduklarından, önceki sürümlerin IANA sürümlerini/Android düzeltmelerini değiştirirler.
- 6. ve 7. örneklerde, O-MR1 ve P için 2018a sürümleri gösterilmektedir.
- 8. Örnek, Y=0 şemasının tamamen yerine geçmek için Y kullanımını göstermektedir.
- 9. örnekte, apk'yı yeniden döndürmek için 3 ile 4 arasında bırakılan boşluğun kullanımı gösterilmektedir.
Her cihaz, sistem görüntüsünde varsayılan olarak uygun sürüm numaralı bir APK ile gönderilir. Bu nedenle, P sistem görüntüsüne kıyasla daha düşük sürüm numarası olduğundan P cihazına O-MR1 sürümünün yüklenmesi riski yoktur. /data bölgesinde O-MR1 sürümü yüklü olup daha sonra P'ye sistem güncellemesi alan bir cihaz, P sürümü O-MR1 için tasarlanan tüm uygulamalardan her zaman daha yüksek olduğundan /data içindeki O-MR1 sürümü yerine /system sürümünü kullanır.
Tapas'ı kullanarak Veri uygulamasını oluşturma
OEM'ler, saat dilimi veri uygulamasının çoğu yönünü yönetmekten ve sistem imajı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) uygun APK'lar üreten ve bir uygulama mağazası üzerinden imzalanıp dağıtılan (sonraki güncellemeler için) bir tapas derlemesiyle geliştirilmesi amaçlanmıştır.
Tapas, uygulamaların dağıtılabilir sürümlerini oluşturmak için azaltılmış bir kaynak ağacı kullanan Android derleme sisteminin basitleştirilmiş bir sürümüdür. Normal Android derleme sistemine aşina olan OEM'ler, normal Android platform derlemesinden derleme dosyalarını tanımalıdır.
Manifest dosyasını oluşturma
Küçültülmüş kaynak ağacı genellikle yalnızca derleme sisteminin ve uygulamanın derlemesi için gereken Git projelerini ifade eden özel bir manifest dosyasıyla elde edilir. Veri uygulaması oluşturma bölümündeki talimatları uyguladıktan sonra OEM'lerin, packages/apps/TimeZoneData/oem_template altındaki şablon dosyaları kullanılarak oluşturulmuş OEM'e özgü en az iki Git projesine sahip olması gerekir:
- Bir Git projesi, manifest gibi uygulama dosyaları ve uygulama APK dosyasını oluşturmak için gereken derleme dosyalarını (örneğin,
vendor/oem/apps/TimeZoneData) içerir. Bu proje, xTS testleri tarafından kullanılabilecek test APK'ları için derleme kuralları da içerir. - Bir Git projesi, sistem resmi derlemesi 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 çeşitli Git projelerinden yararlanır.
Aşağıdaki manifest snippet'i, saat dilimi veri uygulamasının O-MR1 derlemesini desteklemek için gereken minimum Git projesi grubunu içerir. OEM'ler, OEM'ye özel Git projelerini (genellikle imzalama sertifikasını içeren bir proje içerir) bu manifest'e 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 derlemesini çalıştırma
Kaynak ağacı oluşturulduktan sonra aşağıdaki komutları kullanarak tapas derlemesini çağırın:
source build/envsetup.shtapasmake -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 derlenmiş dosyalar dizinine yerleştirilebilir ve/veya uyumlu cihazlar için bir uygulama mağazasından dağıtılabilir.