Saat dilimi kuralları

Android 10, APK tabanlı saat dilimi verileri güncelleme mekanizmasının (Android 8.1 ve Android 9'da kullanılabilir) desteğini sonlandırır ve bunun yerine APEX tabanlı bir modül güncelleme mekanizması kullanır. AOSP 8.1-13 sürümlerinde, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gereken platform kodu hâlâ yer almaktadır. Bu nedenle, Android 10'a yükseltme yapan cihazlar, iş ortakları tarafından sağlanan saat dilimi verisi güncellemelerini APK aracılığıyla almaya devam edebilir. Ancak, APK güncelleme mekanizması, modül güncellemelerini de alan bir üretim cihazında kullanılmamalıdır. Çünkü APK tabanlı bir güncelleme, APEX tabanlı bir güncellemenin yerini alır (yani, APK güncellemesi alan bir cihaz, APEX tabanlı güncellemeleri yoksayar).

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 saati uygulamasını ve saat dilimlerini günceller. Böylece, dini, siyasi ve jeopolitik nedenlerle sık sık değişebilen veriler standart hale getirilir.

Güncellemeler aşağıdaki süreçle yapılır:

1. IANA bir veya daha fazla hükümetin ülkelerindeki saat dilimi kuralını değiştirmesi üzerine Saat Dilimi Veritabanı'nda güncelleme yayınlar.
2. Google veya Android iş ortağı, güncellenmiş saat dilimlerini içeren bir Saat Dilimi Verileri modülü güncellemesi (APEX dosyası) hazırlar.
3. Son kullanıcı cihazı güncellemeyi indirir, yeniden başlatılı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 verisi güncelleme mekanizması özelliği, Android 14'ten itibaren tamamen kaldırıldı ve kaynak kodunda bulunmuyor. İş ortakları, Time Zone Mainline modülüne tamamen geçiş yapmalıdır.

Android 8.1 ve Android 9'da OEM'ler, sistem güncellemesi gerektirmeden 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 ö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 etmesini sağlar.

Android temel kitaplıklar ekibi, stok Android cihazlarda 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ı veya tercih ederlerse kendi veri dosyalarını oluşturmayı seçebilir. Her durumda, OEM'ler desteklenen cihazları için saat dilimi kuralı güncellemelerinin kalite güvencesi/testi, zamanlaması ve kullanıma sunulması üzerinde kontrolü elinde tutar.

Android saat dilimi kaynak kodu ve verileri

Bu özelliği kullanmayanlar da dahil olmak üzere tüm stok Android cihazlarda saat dilimi kuralları verilerinin olması ve /system bölümünde varsayılan bir saat dilimi kuralları veri kümesiyle gönderilmesi gerekir. Bu veriler daha sonra Android kaynak ağacındaki aşağıdaki kitaplıklardan gelen kod tarafından kullanılır:

• libcore/'dan (ör. java.util.TimeZone) yönetilen kod, tzdata ve tzlookup.xml dosyalarını kullanır.
• bionic/ içindeki yerel kitaplık kodu (örneğin, mktime için localtime sistem çağrıları) tzdata dosyasını kullanır.
• external/icu/ içindeki ICU4J/ICU4C kitaplık kodu, icu.dat dosyasını kullanır.

Bu kitaplıklar, /data/misc/zoneinfo/current dizininde bulunabilecek yer paylaşımı dosyalarını takip eder. Yer paylaşımı dosyalarının, geliştirilmiş saat dilimi kuralları verilerini içermesi beklenir. Böylece cihazlar, /system değiştirilmeden güncellenebilir.

Saat dilimi kuralı verilerine ihtiyaç duyan Android sistem bileşenleri önce aşağıdaki konumları kontrol eder:

• libcore/ ve bionic/ kodları, tzdata ve tzlookup.xml dosyalarının /data kopyasını kullanır.
• ICU4J/ICU4C kodu, /data içindeki dosyaları kullanır ve mevcut olmayan veriler (biçimler, yerelleştirilmiş dizeler vb.) için /system dosyalarına geri döner.

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 oluşturma sorunlarını algılamasına olanak tanıyan meta veriler de içerir.

Dağıtım dosyası biçimi, içerikler ICU sürümü, Android platformu gereksinimleri ve diğer sürüm değişiklikleriyle değiştiği için Android sürümüne bağlıdır. Android, desteklenen Android sürümleri için her IANA güncellemesinde dağıtım dosyaları sağlar (platform sistem dosyalarını güncellemenin yanı sıra). 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çerir) kullanarak kendi dosyalarını oluşturabilir.

Saat dilimi güncelleme bileşenleri

Saat dilimi kuralları güncellemesi, dağıtım dosyalarının cihaza aktarılmasını ve içerdiği dosyaların güvenli bir şekilde yüklenmesini içerir. Aktarma ve yükleme için aşağıdakiler gerekir:

• Platform hizmeti işlevi (timezone.RulesManagerService), varsayılan olarak devre dışıdır. OEM'ler, işlevselliği yapılandırma üzerinden etkinleştirmelidir. RulesManagerService, sistem sunucusu sürecinde çalışır ve /data/misc/zoneinfo/staged'a yazarak saat dilimi güncelleme işlemlerini aşamalandırır. RulesManagerService, halihazırda hazırlanmış işlemleri de değiştirebilir veya silebilir.
• TimeZoneUpdater, güncellenemeyen bir sistem uygulaması (diğer adıyla Güncelleyici uygulaması). OEM'ler, bu özelliği kullanan cihazların sistem görüntüsüne bu uygulamayı dahil etmelidir.
• OEM TimeZoneData, dağıtım dosyalarını cihaza taşıyan ve bunları Güncelleyici 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 görüntüsüne dahil etmelidir.
• tzdatacheck, saat dilimi güncellemelerinin doğru ve güvenli şekilde çalışması için gereken başlatma zamanı ikilisi.

Android kaynak ağacı, yukarıdaki bileşenler için genel kaynak kodu içerir. OEM, bu kodu değişiklik yapmadan kullanmayı tercih edebilir. Test kodu, OEM'lerin özelliği doğru şekilde etkinleştirip etkinleştirmediğini otomatik olarak kontrol etmesini sağlamak için sağlanır.

Dağıtım kurulumu

Dağıtım yükleme süreci aşağıdaki adımları içerir:

1. Veri uygulaması, uygulama mağazasından indirilerek veya yan 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ı paket adında yapılan değişiklikleri izler.
   
   

   1. şekil. Veri uygulaması güncellemeleri.

2. Sistem sunucusu işlemi, güncelleme uygulamasında benzersiz ve tek kullanımlık bir jetonla hedeflenmiş bir amaç yayınlayarak güncelleme kontrolünü tetikler. Sistem sunucusu, oluşturduğu en son jetonu takip ederek tetiklediği en son kontrolün ne zaman tamamlandığını belirleyebilir. Diğer tüm jetonlar yoksayılır.
   
   

   Şekil 2. Güncelleme kontrolünü tetikleyin.

3. Güncelleme kontrolü sırasında, Güncelleyici uygulaması aşağıdaki görevleri gerçekleştirir:
   • RulesManagerService'i çağırarak mevcut cihaz durumunu sorgular.
     
     

     3.Şekil Data uygulaması güncellemeleri, RulesManagerService'i çağırıyor.

   • Dağıtım hakkında bilgi almak için iyi tanımlanmış bir ContentProvider URL'si ve sütun özellikleri sorgulayarak Veri uygulamasını sorgular.
     
     

     Şekil 4. Uygulama güncellemeleriyle ilgili veriler, dağıtım hakkında bilgi edinme.

4. Güncelleyici uygulaması, sahip olduğu bilgilere göre uygun işlemi yapar. Kullanılabilir işlemler şunlardır:
   • Yükleme isteğinde bulunun. 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 cihaza uygun olduğunu yeniden onaylar ve yüklemeyi hazırlar.
   • Kaldırma isteğinde bulunma (bu nadiren gerçekleşir). Örneğin, /data içindeki güncellenmiş APK devre dışı bırakılıyorsa veya kaldırılıyorsa ve cihaz /system'deki 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 oluşur.
   Her durumda, Updater uygulaması RulesManagerService'i kontrol jetonuyla çağırır. Böylece sistem sunucusu, kontrolün tamamlandığını ve başarılı olduğunu bilir.
   
   

   5.şekil Kontrol tamamlandı.

5. Yeniden başlatma ve tzdatacheck. Cihaz bir sonraki başlatılışında, tzdatacheck ikilisi, hazırlanan tüm işlemleri yürütür. tzdatacheck ikili programı aşağıdaki görevleri gerçekleştirebilir:
   • Diğer sistem bileşenleri dosyaları açıp kullanmaya başlamadan önce /data/misc/zoneinfo/current dosyalarının oluşturulması, değiştirilmesi ve/veya silinmesi işlemlerini yaparak kademeli işlemi yürütün.
   • /data içindeki dosyaların mevcut platform sürümü için doğru olup olmadığını kontrol edin. Cihaz yeni 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 sürümüyle aynı veya daha yeni olduğundan emin olun. Bu, sistem güncellemesinin cihazı /system görüntüsünde bulunanlardan daha eski saat dilimi kuralları verileriyle bırakmasına karşı koruma sağlar.

Güvenilirlik

Uçtan uca yükleme işlemi eşzamansızdır ve üç işletim sistemi işlemine bölünmüştür. Yükleme sırasında herhangi bir noktada cihazın gücü kesilebilir, disk alanı tükenebilir veya başka sorunlar yaşanabilir. Bu durum, yükleme kontrolünün tamamlanmamasına neden olur. En iyi başarısız durumda, Updater uygulaması sistem sunucusuna başarısız olduğunu bildirir. En kötü başarısız durumda ise RulesManagerService hiç çağrı almaz.

Bunu işlemek için sistem sunucusu kodu, tetiklenen bir güncelleme kontrolünün tamamlanıp tamamlanmadığını ve Veri Uygulaması'nın son kontrol edilen sürüm kodunun ne olduğunu takip eder. Cihaz boşta ve şarj olurken sistem sunucusu kodu mevcut durumu kontrol edebilir. Eksik bir güncelleme kontrolü veya beklenmedik bir veri uygulaması sürümü algılarsa kendiliğinden güncelleme kontrolü başlatır.

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üne işaret eden sorunlar, cihazın başlatılmasını engeller. Örneğin, Updater veya Data uygulamasının kötü yapılandırılması ya da Updater veya Data uygulamasının /system/priv-app'da olmaması bu tür sorunlara örnek verilebilir.
• Kötü bir Veri uygulamasının yüklendiğini gösteren sorunlar, cihazın başlatılmasını engellemez ancak güncelleme kontrolünün tetiklenmesini engeller. Gerekli sistem izinlerinin olmaması veya Veri uygulamasının beklenen URI'de bir ContentProvider'ı kullanıma sunmaması bu durumlara örnek olarak verilebilir.

/data/misc/zoneinfo dizinlerinin dosya izinleri SELinux kuralları kullanılarak zorunlu kılınır. Tüm APK'larda olduğu gibi, Veri uygulaması da /system/priv-app sürümünü imzalamak için kullanılan aynı anahtarla imzalanmalıdır. Veri uygulamasının, OEM'ye özel bir paket adı ve anahtarı olması beklenir.

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ü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ırlık

Üreticiler başlamadan önce aşağıdaki politika, kalite güvencesi ve güvenlik konularını incelemelidir:

• Veri uygulamaları için özel bir uygulamaya özgü imzalama anahtarı oluşturun.
• Hangi cihazların güncelleneceğini ve güncellemelerin yalnızca ihtiyaç duyan cihazlara yüklendiğinden nasıl emin olunacağını anlamak için saat dilimi güncellemeleriyle ilgili 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ı kullanmak isteyebilir veya farklı cihazlar için farklı Veri uygulamaları kullanmayı tercih edebilir. Bu karar, paket adı seçimini, kullanılan sürüm kodlarını ve kalite kontrol stratejisini etkiler.
• Kullanıcıların AOSP'den alınan stok Android saat dilimi verilerini mi kullanmak istediğini yoksa kendi verilerini mi oluşturmak istediğini öğrenin.

Veri uygulaması oluşturma

AOSP, packages/apps/TimeZoneData içinde bir Veri uygulaması oluşturmak için gereken tüm kaynak kodunu ve derleme kurallarını içerir. Ayrıca AndroidManifest.xml ve packages/apps/TimeZoneData/oem_template içinde bulunan diğer dosyalar için talimatlar ve örnek şablonlar da bulunur. Ö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 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ı, sistem görüntüsüne (ilk sürüm için) eklenmeye uygun APK'ler üreten ve bir uygulama mağazası aracılığıyla imzalanıp dağıtılan (sonraki güncellemeler için) bir tapas derlemesiyle oluşturulmak üzere tasarlanmıştır. Tapas kullanma hakkında ayrıntılı bilgi için Building the Data app using tapas başlıklı makaleyi inceleyin.

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 derleme işlemiyle oluşturulur) 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, test paketlerine veri uygulamasının test sürümlerini dahil etmek için derleme hedeflerini de içerir.

Güncelleyici ve Veri uygulamalarını sistem görüntüsüne dahil etme

OEM'ler, Updater ve Data uygulaması APK'larını sistem görüntüsünün /system/priv-app dizinine yerleştirmelidir. Bunun için sistem görüntüsü derlemesi, Updater uygulaması ve Data uygulaması önceden oluşturulmuş hedeflerini açıkça içermelidir.

Güncelleyici uygulaması, platform anahtarıyla imzalanmalı ve diğer sistem uygulamaları gibi dahil edilmelidir. Hedef, packages/apps/TimeZoneUpdater içinde TimeZoneUpdater olarak tanımlanır. Veri uygulaması dahil etme, OEM'ye özeldir ve önceden oluşturma için seçilen hedef adına 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.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

Yanlış yapılandırılmış bir cihaz önyükleme yapmayı reddedebileceğinden yapılandırma geçersiz kılmaları 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ı içermeyen (veya farklı veri uygulaması/güncelleyici 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 (ör. CTS ve VTS) kullanılarak yapılan standart Android test paketlerine benzer, OEM'e özgü tüm 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 testleri dahil etmek için örnek bir dizin yapısı içerir. Diğer şablon dizinlerinde olduğu gibi, OEM'lerin de şablonları kopyalayıp kendi ihtiyaçlarına göre özelleştirmesi beklenir.
• packages/apps/TimeZoneData/oem_template/data_app_prebuilt , test için gereken önceden oluşturulmuş test APK'larını dahil etmek üzere derleme zamanı yapılandırması içerir.

Saat dilimi güncellemeleri oluşturma

IANA yeni bir saat dilimi kuralları grubu 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 commit'leri alabilir, bunları kullanarak Veri uygulamalarının yeni bir sürümünü oluşturabilir ve ardından yeni sürümü yayınlayarak üretimdeki cihazlarını güncelleyebilir.

Veri uygulamaları, Android sürümleriyle yakından ilişkili dağıtım dosyaları içerdiğinden, OEM'ler, güncellemek istedikleri her desteklenen Android sürümü için Veri uygulamasının yeni bir sürümünü oluşturmalıdır. Örneğin, bir OEM, Android 8.1, 9 ve 10 cihazları için güncelleme sağlamak istiyorsa işlemi üç kez tamamlaması gerekir.

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 konumlarındaki 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 biçiminde dosyalar oluşturabilir.

En önemli dosya, system/timezone/output_data/distro/distro.zip'dır. Bu dosya, Veri uygulaması APK'sı oluşturulduğunda otomatik olarak eklenir.

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 sürümünü otomatik olarak alır ancak Veri uygulamasının yeni sürümünün yeni bir sürüm kodu olmalıdır. Böylece yeni olarak tanınır ve önceden yüklenmiş bir Veri uygulamasının veya önceki bir güncelleme ile cihaza yüklenmiş bir Veri uygulamasının yerine kullanılır.

package/apps/TimeZoneData/oem_template/data_app konumundan kopyalanan dosyaları kullanarak Veri uygulamasını oluştururken APK'ya uygulanan sürüm kodunu/sürüm adını Android.mk konumunda bulabilirsiniz:

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 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ıyorsa test sürümü kodlarının gerçek sürüm kodlarından daha yüksek olacağı garanti edildiğinden güncellenmesi gerekmez.

3. adım: Yeniden oluşturun, imzalayın, test edin ve yayınlayın

Bu adımda OEM'ler, APK'yı tapas kullanarak yeniden oluşturur, oluşturulan APK'yı imzalar, ardından APK'yı test edip yayınlar:

• Henüz piyasaya sürülmemiş cihazlar için (veya piyasaya sürülmüş bir cihazda sistem güncellemesi hazırlanırken) sistem görüntüsünde ve xTS testlerinde en yeni APK'ların bulunması için yeni APK'ları Data uygulamasının önceden oluşturulmuş dizinine gönderin. OEM'ler, yeni dosyanın doğru şekilde çalıştığını (yani CTS'yi ve OEM'e özel tüm otomatik ve manuel testleri geçtiğini) test etmelidir.
• Artık sistem güncellemesi almayan yayınlanmış cihazlar için imzalı APK yalnızca bir uygulama mağazası aracılığıyla yayınlanabilir.

OEM'ler, güncellenen Veri uygulamasının yayınlanmadan önce cihazlarında kalite güvencesi ve testinden 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 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, her API düzeyi genellikle ICU'nun yeni bir sürümüyle ilişkilendirildiğinden (bu da dağıtım dosyalarını uyumsuz hale getirir) platform API düzeyi, dağıtım biçimi sürümüyle güçlü bir şekilde ilişkilidir. 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 veri uygulaması sürüm kodu ş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 işleyebileceklerinden 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.

6.şekil Örnek sürüm kodu stratejisi.

Ondalık yerine ikili sistem kullanılsaydı şema daha iyi paketlenebilirdi ancak bu şema, insanlar tarafından okunabilme avantajına sahiptir. Tam sayı aralığı tükendiyse Veri uygulaması paket adı değişebilir.

Sürüm adı, ayrıntıların kullanıcılar tarafından okunabilir bir gösterimidir. Örneğin: major=001,minor=001,iana=2017a, revision=1,respin=2. Örnekler aşağıdaki tabloda gösterilmektedir.

• 1. ve 2. örneklerde, aynı 2017a IANA sürümünün farklı ana biçim sürümlerine sahip iki APK sürümü gösterilmektedir. 2, 1'den sayısal olarak daha yüksektir. Bu, yeni cihazların daha yüksek biçim sürümlerini almasını sağlamak için gereklidir. minSdkVersion, P sürümünün O cihazlarına sağlanmamasını sağlar.
• 3. örnek, 1. örneğin düzeltilmiş/düzeltilmiş halidir ve sayısal olarak 1. örnekten daha 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ı için, ilgili öncüllerinin önceki IANA sürümlerinin/Android revizyonlarının yerini alırlar.
• 6. ve 7. örneklerde O-MR1 ve P için 2018a sürümleri gösterilmektedir.
• 8. örnekte, Y=0 şemasının tamamen değiştirilmesi için Y'nin kullanımı gösterilmektedir.
• Örnek 9, APK'yı yeniden döndürmek için 3 ile 4 arasında bırakılan boşluğun kullanımını gösterir.

Her cihaz, sistem görüntüsünde varsayılan ve uygun şekilde sürümü belirlenmiş bir APK ile gönderildiğinden, P sistem görüntüsü sürümünden daha düşük bir sürüm numarasına sahip olduğu için P cihazına O-MR1 sürümünün yüklenme riski yoktur. /data sürümü yüklü olan ve daha sonra P sürümüne sistem güncellemesi alan bir cihaz, /data sürümündeki O-MR1 sürümüne kıyasla /system sürümünü tercih eder. Bunun nedeni, P sürümünün her zaman O-MR1 için tasarlanmış uygulamalardan daha yüksek olmasıdır.

Tapas'ı kullanarak Veri uygulaması 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ı, sistem görüntüsüne (ilk sürüm için) eklenmeye uygun APK'lar üreten ve bir uygulama mağazası aracılığıyla imzalanıp dağıtılan (sonraki güncellemeler için) bir tapas derlemesiyle oluşturulmak üzere tasarlanmış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 derlemesindeki derleme dosyalarını tanıyabilir.

Manifest dosyasını oluşturma

Küçültülmüş kaynak ağacı genellikle yalnızca derleme sistemi tarafından ihtiyaç duyulan ve uygulamanın oluşturulması için gerekli Git projelerine atıfta bulunan özel bir manifest dosyasıyla elde edilir. Veri uygulaması oluşturma bölümündeki talimatları uyguladıktan sonra OEM'ler, packages/apps/TimeZoneData/oem_template altındaki şablon dosyalarını kullanarak en az iki OEM'e özel Git projesi oluşturmalıdır:

• Bir Git projesi, manifest ve uygulama APK dosyası oluşturmak için gereken derleme dosyaları (örneğin, vendor/oem/apps/TimeZoneData) gibi uygulama dosyalarını içerir. Bu proje, xTS testlerinde kullanılabilecek test APK'ları için derleme kurallarını da içerir.
• Bir Git projesi, sistem görüntüsü derlemesine ve xTS testlerine dahil edilmek üzere uygulama derlemesi tarafından oluşturulan imzalı APK'ları içerir.

Uygulama derlemesi, platform derlemesiyle paylaşılan veya OEM'den bağımsız kod kitaplıkları içeren birkaç başka Git projesinden yararlanır.

Aşağıdaki manifest snippet'i, saat dilimi verileri uygulamasının O-MR1 sürümünü desteklemek için gereken minimum Git projeleri kümesini içerir. OEM'ler, OEM'e özel Git projelerini (genellikle imzalama sertifikasını içeren bir proje) bu manifeste eklemeli ve farklı dalları buna göre yapılandırmalıdır.

   <!-- 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.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ş dizinine yerleştirilebilir ve/veya uyumlu cihazlar için bir uygulama mağazası üzerinden dağıtılabilir.