Android 9, bootloader başlatma nedeni spesifikasyonunda aşağıdaki değişiklikleri içerir.
Başlatma nedenleri
Bootloader, aşağıdaki işlemleri gerçekleştirmek için benzersiz bir şekilde kullanılabilen donanım ve bellek kaynaklarını kullanır:
bir cihazın neden yeniden başlatıldığını belirler, ardından
androidboot.bootreason=<reason>
Android'e ekleniyor
kernel komut satırını kullanın. init
, daha sonra bunu çevirir
komut satırı ile Android mülkündeki tüm cihazlarınıza
bootloader_boot_reason_prop
(ro.boot.bootreason
).
Android 12 veya sonraki sürümlerin yüklü olduğu cihazlarda
5.10 veya daha yeni çekirdek sürümü kullanıldığında, androidboot.bootreason=<reason>
, çekirdek komut satırı yerine bootconfig'e eklenir.
Başlatma nedeni özellikleri
Android'in önceki sürümleri,
boşluklar, tamamı küçük harfle yazıldı, birkaç gereksinim (ör. raporlama için
kernel_panic
, watchdog
,
cold
/warm
/hard
) ve
başka benzersiz sebeplerden dolayı ödemeler. Bu belirsiz spesifikasyon
yüzlerce özel (ve bazen anlamsız) başlatma nedeninin çoğalması
Bu da yönetilemeyen bir duruma yol açıyordu. Şu anki
Android sürümü, neredeyse ayrıştırılamayan veya anlamsız içeriğin büyük ivmesi
dosyası, Bootloader tarafından dosyalanan ve
bootloader_boot_reason_prop
Android 9 sürümüyle birlikte Android ekibi
, eski bootloader_boot_reason_prop
sürümünün
önemli bir hıza sahiptir ve çalışma zamanında yeniden yazılamaz. Projenin yaşam döngüsü
Dolayısıyla başlatma nedeni spesifikasyonu,
bootloader'ını geliştirip mevcut sistemde rötuşlar yapın. Bunun için
Android ekibi:
- Bootloader geliştiricilerini aşağıdakileri yapmaya teşvik etmek için onlarla işbirliği yapma:
- ve anlaşılması gereken
standart, ayrıştırılabilir ve anlaşılması
bootloader_boot_reason_prop
system/core/bootstat/bootstat.cpp
etkinliğine katılınkBootReasonMap
listesi.
- ve anlaşılması gereken
standart, ayrıştırılabilir ve anlaşılması
-
system_boot_reason_prop
(sys.boot.reason
). CEVAP sınırlı bir sistem uygulaması grubu (ör.bootstat
veinit
) bu özelliği yeniden yazabilir, ancak tüm uygulamalar okuması için sepolicy haklarını verdi. - Başlatma nedeni hakkında kullanıcıları, kullanıcı verileri eklenene kadar beklemeleri gerektiği konusunda bilgilendirme
sistem başlatma nedeni özelliğindeki içeriğe güvenmeden önce
system_boot_reason_prop
Neden bu kadar geç? bootloader_boot_reason_prop
erken kullanıma sunulacak
Android güvenlik politikası uyarınca gerektiğinde engellenir.
çünkü yanlış, ayrıştırılamayan ve standart olmayan bilgileri temsil eder.
Çoğu durumda, yalnızca başlatma sistemi hakkında derinlemesine bilgi sahibi olan geliştiriciler
bu bilgilere erişmesi gerekir. Hassaslaştırılmış, ayrıştırılabilir ve standart
system_boot_reason_prop
ile başlatma nedeni için API güvenilir
ve yalnızca kullanıcı verileri eklendikten sonra doğru şekilde alınır.
Özellikle:
- Kullanıcı verileri eklenmeden önce,
system_boot_reason_prop
, şuradan değeri içerecek:bootloader_boot_reason_prop
. - Kullanıcı verileri eklendikten sonra
system_boot_reason_prop
, politikaya uygun veya raporlayın.
Bu nedenle Android 9,
Bu nedenle, başlatma nedeni resmi olarak edinilmeden önce
açılışta anında doğru sonuç verir (bootloader_boot_reason_prop
ile)
eklendikten sonra kullanılabilir hale gelecek şekilde (
system_boot_reason_prop
) tıklayın.
Bootstat mantığı, daha bilgilendirici ve uyumlu bir sisteme bağlıdır.
bootloader_boot_reason_prop
Bu mülkte bir
Böylece, tüm kontrollü yeniden başlatma işlemlerinin doğruluğunu
artırır ve doğru bir şekilde
Bu da senaryonun doğruluğunu ve anlamını geliştirip genişletmesini sağlar.
/ system_boot_reason_prop
.
Standart başlatma nedeni biçimi
bootloader_boot_reason_prop
için standart başlatma nedeni biçimi
, Android 9'da aşağıdaki söz dizimini kullanır:
<reason>,<subreason>,<detail>…
Biçimlendirme kuralları:
- Küçük harf
- Boşluk kullanmayın (alt çizgi kullanın)
- Yazdırılabilir tüm karakterler
- Virgülle ayrılmış
reason
,subreason
ve bir veyadetail
örneği daha.- En yüksek önceliği temsil eden zorunlu bir
reason
cihazın yeniden başlatılması veya kapatılmasının nedeni. - Kısa bir özetini temsil eden isteğe bağlı
subreason
cihazın yeniden başlatılması veya kapatılması (ya da kim tarafından yeniden başlatılması veya cihazda) olduğunu varsayalım. - İsteğe bağlı olarak bir veya daha fazla
detail
değeri.detail
bir alt sisteme işaret ederek belirli bir sistemin hangi sistemsubreason
ile sonuçlandı. Birden çok öğe belirtebilirsiniz Genellikle şu hiyerarşiyi izlemesi gerekendetail
değerleri: önem taşır. Bununla birlikte, dilerseniz Eşit önem düzeyine sahipdetail
değerleri.
- En yüksek önceliği temsil eden zorunlu bir
bootloader_boot_reason_prop
için boş bir değer dikkate alınır
yasa dışıdır (bu, diğer aracıların olaydan sonra bir başlatma nedeni yerleştirmesine olanak tanır).
Neden şartları
reason
için sağlanan değer (ilk aralık, fesihten önce veya
virgül), aşağıdaki küme çekirdek, güçlü ve künt olarak ayrılmış olmalıdır.
nedenler:
- çekirdek kümesi:
- "
watchdog"
"kernel_panic"
- "
- güçlü küme:
"recovery"
"bootloader"
- künt olarak ayarlandı:
"cold"
Genellikle tüm cihazların tamamen sıfırlandığını gösterir. hafıza da buna dahildir."hard"
Genellikle donanımın kendi durumunun olduğunu gösterir sıfırlama işlemi yapılır veramoops
kalıcı içeriği saklamalıdır."warm"
Genel olarak belleği ve cihazları gösterir bazı eyaletler veramoops
korunur (bkz.pstore
yedek deposunda kalıcı içerik bulunur."shutdown"
"reboot"
Genellikleramoops
durumunun şöyle olduğu anlamına gelir: cihazın durumu bilinmiyor. Bu değer,cold
,hard
vewarm
değerleri sağlar sıfırlama işleminin derinliği hakkında ipuçları verir.
Bootloader'lar bir çekirdek grubu veya bir kört küme reason
sağlamalıdır ve
mümkünse bir subreason
sağlanması önerilir
belirler. Örneğin, güç tuşuna uzun basmak zorunda kalabilirsiniz.
Başlatma nedeni ramoops
yedeğinde olabilir
"reboot,longkey"
.
İlk aralık reason
, herhangi bir subreason
veya
detail
. Ancak, çekirdek tarafından ayarlanan nedenler
"watchdog"
, belirli bir nedenden sonra yeniden kullanılabilir.
kaynağın bir ayrıntısıyla (örneğin,
"reboot,watchdog,service_manager_unresponsive"
veya
"reboot,software,watchdog"
).
Başlatma nedenleri, verileri çözmek ve/veya
anlaşılması kolay bir raporla okunabilir olmalıdır. Örnekler:
"shutdown,vbxd"
(kötü), "shutdown,uv"
(daha iyi),
"shutdown,undervoltage"
(tercih edilen).
Neden-alt neden kombinasyonları
Android reason
-subreason
arasında rezervasyon yapar
normal kullanımda aşırı yüklenmemesi gereken ancak
duruma göre, kombinasyon, ilişkili reklamı doğru şekilde yansıtıyorsa
koşul. Ayrılmış kombinasyonlara örnekler:
"reboot,userrequested"
"shutdown,userrequested"
"shutdown,thermal"
(thermald
dilinden)"shutdown,battery"
"shutdown,battery,thermal"
(en yüksek fiyat:BatteryStatsService
)"reboot,adb"
"reboot,shell"
"reboot,bootloader"
"reboot,recovery"
Daha ayrıntılı bilgi için kBootReasonMap
bölümüne bakın
system/core/bootstat/bootstat.cpp
ve ilişkili git
değişiklik günlüğü geçmişini görebilirsiniz.
Başlatma nedenlerini raporla
Bootloader'dan gelen veya standart başlatmada kaydedilen tüm başlatma nedenleri
kBootReasonMap
bölümüne kaydedilmelidir.
system/core/bootstat/bootstat.cpp
. İlgili içeriği oluşturmak için kullanılan
kBootReasonMap
listesi, uyumlu ve eski öğelerin bir karışımıdır
neden olabilir. Bootloader geliştiricileri yalnızca yeni
burada belirtilen kurallara uygun olmayan nedenler
ürün daha önce gönderilmiş ve değiştirilemez).
Google Etiket Yöneticisi'nde mevcut, uyumlu girişleri kullanmanızı
system/core/bootstat/bootstat.cpp
ve öncesinde kısıtlama egzersizleri yapın
dizeleri kullanmaktır. Yönerge olarak şu şekildedir:
- Tamam'ı tıklayarak
"kernel_panic"
adlı kişiyi bootloader'ı yükleyin,bootstat
bunu inceleyebilir daraltmak içinkernel_panic signatures
içinramoops
alt nedenleri standartsystem_boot_reason_prop
bölümüne ekleyin. - Uyumlu olmayan bir dizeyi bildirmek için Uygun Değil
kBootReasonMap
(örneğin"panic")
bootloader'ı yükleyin, bu durum sonuçtareason
.
Örneğin, kBootReasonMap
"wdog_bark"
içeriyorsa
bir bootloader geliştiricisi şunları yapmalıdır:
"watchdog,bark"
olarak değiştirin ve şuradaki listeye ekleyin:kBootReasonMap
."bark"
özelliğinin, vesubreason
ürününün daha anlamlı olup olmadığını kullanılabilir.
Başlatma nedeni uygunluğunu doğrulayın
Şu anda Android, doğru sonuçları verebilecek etkin bir CTS testi sağlamamaktadır. bir bootloader'ın sağlayabileceği tüm olası başlatma nedenlerini tetikleme veya inceleme; iş ortakları, uyumluluğu belirlemek için pasif test yapmayı deneyebilir.
Sonuç olarak, bootloader uyumluluğu için bootloader geliştiricilerinin
yukarıda açıklanan kuralların ve yönergelerin ruhuna gönüllü olarak uygun hareket etmelisiniz.
Bu tür geliştiricilerin AOSP'ye (özellikle de Google'ın
system/core/bootstat/bootstat.cpp
) ve bu fırsatı aşağıdaki
hakkındaki tartışmalar için foruma Google'dan erişebilirsiniz.