Motivo avvio canonico

Android 9 include le seguenti modifiche alla specifica del motivo dell'avvio del bootloader.

Motivi dell'avvio

Un bootloader utilizza risorse hardware e di memoria disponibili in modo univoco per determinare perché un dispositivo si è riavviato, quindi comunica tale determinazione aggiunta di androidboot.bootreason=<reason> ad Android della riga di comando del kernel per il suo lancio. init traduce quindi questo testo riga di comando per propagarsi alla proprietà Android bootloader_boot_reason_prop (ro.boot.bootreason). Per i dispositivi che verranno lanciati con Android 12 o versioni successive: usando la versione del kernel 5.10 o successiva, androidboot.bootreason=<reason> in bootconfig al posto della riga di comando del kernel.

Specifiche del motivo dell'avvio

Le versioni precedenti di Android specificavano un formato motivo di avvio che non prevedeva l'utilizzo spazi, era tutto minuscolo, includeva pochi requisiti (come per la generazione di report kernel_panic, watchdog, cold/warm/hard) e quali hanno generato per altri motivi unici. Questa specifica poco chiara ha generato proliferazione di centinaia di motivi di avvio personalizzati (e a volte privi di significato) e questo ha causato una situazione ingestibile. Alla data Release di Android, il grande slancio di contenuti quasi non analizzabili o privi di significato segnalato dal bootloader ha creato problemi di conformità bootloader_boot_reason_prop.

Con il rilascio di Android 9, il team di Android riconosce che la versione precedente di bootloader_boot_reason_prop ha slancio significativo e non può essere riscritto in fase di runtime. Eventuali miglioramenti a la specifica del motivo di avvio deve quindi provenire dalle interazioni di bootloader e modifiche al sistema esistente. A questo scopo, Il team Android è:

• Coinvolgimento degli sviluppatori di bootloader per incoraggiarli a:
  • Fornisci motivi canonici, analizzabili e riconoscibili per bootloader_boot_reason_prop.
  • Partecipa al system/core/bootstat/bootstat.cpp Elenco kBootReasonMap.
• L'aggiunta di un'origine controllata e riscrivibile del runtime system_boot_reason_prop (sys.boot.reason). R un gruppo limitato di app di sistema (ad esempio bootstat e init) può riscrivere questa proprietà, ma tutte le app possono essere autorizzati a leggerla.
• Informare gli utenti sul motivo dell'avvio di attendere fino al montaggio dei dati utente prima di considerare attendibili i contenuti nella proprietà Motivo avvio del sistema system_boot_reason_prop.

Perché così tardi? Sebbene bootloader_boot_reason_prop sia disponibile in anteprima all'avvio, viene bloccato dal criterio di sicurezza di Android in base alle necessità. perché rappresenta informazioni imprecise, non analizzabili e non canoniche. Nella maggior parte dei casi, solo gli sviluppatori con una conoscenza approfondita del sistema di avvio devono accedere a queste informazioni. Un URL raffinato, analizzabile e canonico L'API per il motivo dell'avvio con system_boot_reason_prop può essere affidabile e raccolti in modo accurato solo dopo il montaggio dei dati utente. Nello specifico:

• Prima di montare i dati utente, system_boot_reason_prop conterrà il valore da bootloader_boot_reason_prop.
• Dopo aver montato i dati utente, system_boot_reason_prop può essere aggiornato per essere conforme o per segnalare informazioni più accurate.

Per questo motivo, Android 9 estende il periodo prima che il motivo dell'avvio possa essere acquisito ufficialmente, subito accurato all'avvio (con bootloader_boot_reason_prop) disponibili solo dopo il montaggio dei dati utente (con system_boot_reason_prop).

La logica di bootstat dipende da una logica più informativa e conforme bootloader_boot_reason_prop. Quando la proprietà utilizza una proprietà più prevedibile, migliora la precisione di tutti i riavvii controllati scenari di chiusura, che a loro volta perfezionano e ampliano la precisione e il significato di system_boot_reason_prop.

Formato motivo avvio canonico

Il formato canonico del motivo dell'avvio per bootloader_boot_reason_prop in Android 9 utilizza la seguente sintassi:

<reason>,<subreason>,<detail>…

Regole di formattazione:

• Minuscolo
• Nessuno spazio vuoto (utilizza il sottolineato)
• Tutti i caratteri stampabili
• reason, subreason e uno o uno o più separati da virgole altre detail istanze.
  • Un valore reason obbligatorio che rappresenta la priorità più alta il motivo per cui il dispositivo ha dovuto riavviarsi o spegnersi.
  • Un elemento subreason facoltativo che rappresenta un breve riepilogo di il motivo per cui il dispositivo ha dovuto riavviarsi o spegnersi (oppure chi ha riavviato o arrestato il dispositivo).
  • Uno o più valori facoltativi di detail. detail possono puntare a un sottosistema per aiutare a determinare quale specifico sistema ha generato subreason. Puoi specificare più detail, che in genere devono seguire una gerarchia di l'importanza. Tuttavia, è accettabile anche segnalare detail valori di uguale importanza.

Viene considerato un valore vuoto per bootloader_boot_reason_prop illegale (perché ciò consente ad altri agenti di inserire un motivo di avvio a posteriori).

Requisiti per i motivi

Il valore specificato per reason (primo intervallo, prima della risoluzione virgola) deve essere del seguente set, suddiviso in kernel, forte e smussato motivi:

• set di kernel:
  • "watchdog"
  • "kernel_panic"
• set forte:
  • "recovery"
  • "bootloader"
• insieme smussato:
  • "cold". Indica in genere un ripristino completo di tutti i dispositivi, inclusa la memoria.
  • "hard". Indica in genere che l'hardware ha il suo stato reimpostata e ramoops deve conservare i contenuti persistenti.
  • "warm". In genere indica la memoria e i dispositivi mantengono uno stato e ramoops (vedi pstore (driver nel kernel) che contiene contenuti permanenti.
  • "shutdown"
  • "reboot". In genere significa che lo stato ramoops è sconosciuto e lo stato dell'hardware è sconosciuto. Questo valore è un catchall come I valori cold, hard e warm forniscono indizi sulla profondità del ripristino del dispositivo.

I bootloader devono fornire un set di kernel o un set smussato reason; e ti consigliamo vivamente di fornire un subreason, se possibile determinato. Ad esempio, una pressione prolungata del tasto di accensione potrebbe o meno avere Il backup di ramoops potrebbe essere il motivo dell'avvio "reboot,longkey".

Nessun reason primo intervallo può far parte di subreason o detail. Tuttavia, poiché i motivi del set del kernel non possono essere generati spazio utente, "watchdog" può essere riutilizzato per un motivo non definito, insieme a un dettaglio della fonte (ad esempio, "reboot,watchdog,service_manager_unresponsive", oppure "reboot,software,watchdog").

I motivi dell'avvio non devono richiedere conoscenze interne di esperti per decifrare e/o devono essere leggibili da una persona con un report intuitivo. Esempi: "shutdown,vbxd" (pessima), "shutdown,uv" (migliore), "shutdown,undervoltage" (preferito).

Combinazioni motivo-sottomotivo

Android prenota un insieme di reason-subreason combinazioni che non devono essere sovraccaricate durante il normale utilizzo ma che possono essere utilizzate caso per caso se la combinazione riflette accuratamente i . Ecco alcuni esempi di combinazioni riservate:

• "reboot,userrequested"
• "shutdown,userrequested"
• "shutdown,thermal" (da thermald)
• "shutdown,battery"
• "shutdown,battery,thermal" (da BatteryStatsService)
• "reboot,adb"
• "reboot,shell"
• "reboot,bootloader"
• "reboot,recovery"

Per maggiori dettagli, consulta kBootReasonMap in system/core/bootstat/bootstat.cpp e il Git associato della cronologia delle modifiche nel repository di codice sorgente Android.

Segnala motivi di avvio

Tutti i motivi di avvio, dal bootloader o registrati nell'avvio canonico deve essere registrato nella sezione kBootReasonMap di system/core/bootstat/bootstat.cpp. La L'elenco kBootReasonMap è un mix di versioni conformi e legacy non conformi. Gli sviluppatori del bootloader devono registrare soltanto nuovi motivi di conformità qui (e non dovrebbero registrare motivi non conformi a meno che il prodotto è già stato spedito e non può essere modificato).

Consigliamo vivamente di utilizzare voci esistenti e conformi in system/core/bootstat/bootstat.cpp e contenimento dell'allenamento prima del giorno utilizzando una stringa non conforme. Come regola generale, si tratta di:

• OK per segnalare "kernel_panic" dal bootloader, in quanto bootstat potrebbe essere in grado di ramoops per kernel_panic signatures per perfezionare nella versione canonica system_boot_reason_prop.
• Non è possibile segnalare una stringa non conforme in kBootReasonMap (ad esempio "panic") del bootloader, poiché ciò comprometterà la possibilità di perfezionare reason.

Ad esempio, se kBootReasonMap contiene "wdog_bark", uno sviluppatore di bootloader deve:

• Passa a "watchdog,bark" e aggiungilo all'elenco in kBootReasonMap.
• Valuta cosa significa "bark" per chi non ha familiarità con il tecnologia e determinare se un subreason più significativo è disponibili.

Verifica la conformità del motivo dell'avvio

Al momento Android non fornisce un test CTS attivo in grado di fornire con precisione attivare o controllare tutti i possibili motivi di avvio forniti da un bootloader; i partner possono comunque tentare di eseguire un test passivo per determinare la compatibilità.

Di conseguenza, la conformità del bootloader richiede agli sviluppatori aderiscono volontariamente allo spirito delle regole e delle linee guida sopra descritte. Invitiamo tali sviluppatori a contribuire ad AOSP (in particolare per system/core/bootstat/bootstat.cpp) e usa questa opportunità come per discussioni sui problemi che causano l'avvio.