Saat dilimi kuralları

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 arasında, OEM'lerin APK tabanlı güncellemeleri etkinleştirmesi için gereken platform kodu hâlâ mevcuttur. 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 tabanlı güncelleme, APEX tabanlı güncellemenin yerini aldığından APK güncelleme mekanizması, modül güncellemeleri de alan üretim cihazlarında kullanılmamalıdı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 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:

1. 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.
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ı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 veri güncelleme mekanizması özelliği, Android 14'ten itibaren tamamen kaldırılmıştır ve kaynak kodunda bulunamaz. İş 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 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ı seçebilir veya tercih ederlerse kendi veri dosyalarını oluşturabilirler. Her durumda, OEM'ler desteklenen cihazlarının kalite güvencesi/testi, zamanlaması ve saat dilimi kural güncellemelerinin lansmanı üzerinde 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ı verilerinin bulunması 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), tzdata ve tzlookup.xml dosyalarını kullanır.
• bionic/ içindeki yerel kitaplık kodu (ör. mktime, localtime sistem çağrıları için), 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ı 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/ ve bionic/ kodu, 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 için (biçimler, yerelleştirilmiş dizeler vb.) /system dosyaları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.

İçerikleri ICU sürümü, Android platformu gereksinimleri ve diğer sürüm değişikliklerine bağlı olarak değiştiği için dağıtım dosyası biçimi Android sürümüne bağlıdır. 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 /data/misc/zoneinfo/staged'e yazarak saat dilimi güncelleme işlemlerini aşamalı olarak gerçekleştirir. 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.
• OEMTimeZoneData, 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 ç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.

Distro kurulumu

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

1. Veri uygulaması, uygulama mağazasından indirme veya harici 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.
   
   

   Şekil 1. Veri uygulaması güncellemeleri.

2. 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.

3. Güncelleme kontrolü sırasında Güncelleme Uygulaması aşağıdaki görevleri gerçekleştirir:
   • RulesManagerService'i çağırarak mevcut cihaz durumunu sorgulayan bir işlevdir.
     
     

     Şekil 3. RulesManagerService'i çağıran veri uygulaması güncellemeleri.

   • Dağıtım hakkında 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.

4. Güncelleme Aracı uygulaması, sahip olduğu bilgilere göre uygun işlemi yapar. Kullanılabilen 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 durum 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.
   Güncelleme uygulaması, her durumda RulesManagerService'i kontrol jetonuyla çağırır. Böylece sistem sunucusu, kontrolün tamamlandığını ve başarılı olduğunu bilir.
   
   

   Şekil 5. Kontrol tamamlandı.

5. Yeniden başlatma ve tzdatacheck. Cihaz bir sonrakinde açıldığında tzdatacheck ikili dosyası, aşamalı olarak yürütülen tüm işlemleri gerçekleştirir. tzdatacheck ikili programı aşağıdaki görevleri gerçekleştirebilir:
   • Diğer sistem bileşenleri dosyaları açmadan ve kullanmaya başlamadan önce /data/misc/zoneinfo/current dosyalarının oluşturulmasını, değiştirilmesini ve/veya silinmesini yöneterek aşamalı 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 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 sürümündeki sürümle aynı veya daha yeni olduğundan emin olun. Bu, bir sistem güncellemesi sonucunda cihazda /system görüntüsünde bulunandan daha eski saat dilimi kuralları verilerinin kalmasına karşı koruma sağlar.

Güvenilirlik

Baştan sona yükleme işlemi, üç işletim sistemi işlemine bölünmüş ve eşzamansızdı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 durumda, Updater uygulaması sistem sunucusunu başarısız olduğunu bildirir. En kötü durumda ise 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 olarak verilebilir.
• Hatalı bir Veri uygulamasının yüklendiğini 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

OEM'ler, saat dilimi güncelleme özelliğini etkinleştirmek için genellikle:

• Kendi veri uygulamalarını oluşturabilirler.
• Güncelleme ve Veri uygulamalarını sistem resmi derlemesine ekleyin.
• RulesManagerService'i etkinleştirecek şekilde sistem sunucusunu 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şturma

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 hem gerçek Veri uygulaması APK'sı için bir derleme hedefi hem de Veri uygulamasının test sürümlerini oluşturmak için ek hedefler içerir.

OEM'ler Veriler uygulamasını kendi simgeleriyle, adlarıyla, çevirileriyle 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'ı kullanma hakkında ayrıntılı bilgi için Tapas'ı kullanarak veri uygulamasını oluşturma başlıklı makaleyi inceleyin.

OEM'ler, Veriler uygulamasını /system/priv-app'te bir cihazın sistem resmine önceden yüklenmiş olarak 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üncelleme Aracı ve Veri uygulaması APK'larını sistem resminin /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.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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 , testin gerektirdiği önceden derlenmiş 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ı 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 içinde de 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 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:

• Henüz piyasaya sürülmemiş cihazlar için (veya piyasaya sürülmüş bir cihaz için sistem güncellemesi hazırlarken) sistem görüntüsünde ve xTS testlerinde en son APK'ların bulunduğundan emin olmak üzere yeni APK'ları Veri uygulaması önceden oluşturulmuş dizinine 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, imzalı 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)
• Artımlı (opak) sürüm numarası

Şu anda platform API düzeyi, her API düzeyi genellikle ICU'nun yeni bir sürümüyle ilişkilendirildiği için dağıtım biçimi sürümüyle yakından ilişkilidir (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 numaralandırma ş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şleyemeyeceğinden daha yüksek bir dağıtım biçimi sürümüne sahip sürümler almamasını sağlamak için android:minSdkVersion kullanır.

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

Onluk yerine ikili sayı kullanılsaydı şema daha iyi sıkıştırılabilirdi ancak bu şema, insanlar tarafından okunabilir olma 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.

• 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, P sürümünün O cihazlara 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. örnekte, Y=0 şemasının tamamen değiştirilmesi için Y'nin kullanımı gösterilmektedir.
• 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üme sahip 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'te O-MR1 sürümü yüklü olan ve daha sonra P sürümüne güncellenen bir cihaz, P sürümü her zaman O-MR1 için tasarlanmış uygulamalardan daha yüksek olduğundan /data'deki O-MR1 sürümüne kıyasla /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ı, sistem resmine 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, 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

Azaltılmış kaynak ağacı genellikle yalnızca derleme sisteminin ve uygulamanın derlenmesi için ihtiyaç duyulan Git projelerini belirten özel bir manifest dosyasıyla elde edilir. Veri uygulaması oluşturma başlıklı makaledeki talimatları uyguladıktan sonra OEM'lerin, packages/apps/TimeZoneData/oem_template altındaki şablon dosyalarını kullanarak OEM'ye özel en az iki Git projesi oluşturması gerekir:

• Bir Git projesi, uygulama APK dosyasını oluşturmak için gereken manifest ve derleme dosyaları gibi uygulama 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.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 derlenmiş dosyalar dizinine yerleştirilebilir ve/veya uyumlu cihazlar için bir uygulama mağazasından dağıtılabilir.