Saat Dilimi Kuralları

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:

1. 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ı.
2. Google veya Android iş ortağı, güncellenmiş saat dilimlerini içeren bir Saat Dilimi Veri modülü güncellemesi (APEX dosyası) hazırlar.
3. 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 ve tzlookup.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/ ve bionic/ code, 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 (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:

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

   

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

   

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

     

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

     

4. 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.
   Her durumda Updater uygulaması, kontrol belirteciyle birlikte RulesManagerService'i çağırır, böylece sistem sunucusu, kontrolün eksiksiz ve başarılı olduğunu bilir.
   
   

   

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

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.

config_enableUpdateableTimeZoneRules

config_timeZoneRulesUpdateTrackingEnabled

config_timeZoneRulesDataPackage

config_timeZoneRulesUpdaterPackage

config_timeZoneRulesCheckTimeMillisAllowed

config_timeZoneRulesCheckRetryCount

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.

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.

• Ö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.