Requisiti del kernel di base

Android 8.0 e versioni successive richiedono una versione minima del kernel e una configurazione del kernel, verificate dagli aggiornamenti Vendor Test Suite (VTS) e over-the-air (OTA). Noccioli di dispositivi Android devono consentire kernel .config supporto e la possibilità di leggere la configurazione del kernel in fase di esecuzione attraverso il procfs file system.

Supporto del kernel .config

Tutti i kernel dei dispositivi devono consentire l'interezza del android-base.cfg , che deve includere le seguenti opzioni del kernel-config (o il loro kernel-version equivalente):

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y

Versione del kernel

Per Android 9, i requisiti minimi della versione del kernel Long Term Support (LTS) sono 4.4.107, 4.9.84 e 4.14.42.

  • Tutti i SoC prodotti nel 2018 devono essere avviati con kernel 4.9.84 o successivo.
  • Tutti gli altri SoC che avviano dispositivi Android con Android 9 devono utilizzare il kernel 4.4.107 o versioni successive.
  • I kernel dei dispositivi basati su 4.14 devono includere la versione LTS 4.14.42 o successiva.
  • Indipendentemente dalla data di lancio, tutti i SoC con avvio del dispositivo su Android 8.0 e versioni successive rimangono soggetti alle modifiche al kernel necessarie per abilitare Treble.
  • I dispositivi Android meno recenti che eseguono l'aggiornamento ad Android 8.0 o versioni successive possono continuare a utilizzare la versione del kernel di base originale.

Per i dettagli su kernel LTS, vedere kernel stabili a lungo termine e Android Kernel Comune

Supporto Devicetree

Se la piattaforma non supporta l' Advanced Configuration and Power Interface (ACPI) specifica, devicetree supporto nel kernel deve essere abilitato o bootloader deve passare la descrizione dell'hardware, sotto forma di un devicetree al kernel. Il devicetree deve essere disponibile anche per la lettura da parte di Android e deve essere in grado di passare ad Android parametri specifici del fornitore e dell'ODM. CONFIG_OF è obbligatoria, insieme a tutti gli altri dispositivi e sistemi specifici sottosistemi CONFIG_OF_* opzioni di configurazione del kernel.

Utilizzo di DebugFS

L'implementazione dell'interfaccia venditore non può fare affidamento sul DebugFS file system per accedere alle informazioni di debug. Questo perché in Android 7,0-10, DebugFS può essere abilitata, ma i test VTS potrebbe essere fatto con DebugFS non montati.

In Android 11, DebugFS non è possibile accedere o montati su dispositivi di produzione, per cui i produttori di dispositivi devono rimuoverlo. Prima di Android 11, dumpstate accede legante statistiche da DebugFS . Perché l'utente costruisce il lancio con Android 11 o superiore non possono accedere DebugFS , dumpstate accessi legante statistiche binderfs . Per abilitare Binderfs , abilitare la configurazione del kernel CONFIG_ANDROID_BINDERFS .

In Android 11, VTS applica questi due requisiti:

  • CONFIG_DEBUG_FS non è abilitato nella configurazione del kernel del dispositivo.
  • DebugFS non è elencato in /proc/filesystems .

DebugFS in Android 12

I dispositivi che si avviano con Android 12 utilizzando versioni del kernel successive alla v5.4 devono essere forniti con il kernel GKI. In modo che i partner possono accedere DebugFS in userdebug costruisce mentre si sviluppano sul kernel GKI, la configurazione del kernel CONFIG_DEBUG_FS è attivata nel defconfig GKI. Mai montare DebugFS a utente costruisce per i dispositivi di lancio sia su Android e Android 11 12.

Le build Userdebug hanno una copertura di test migliore rispetto alle build utente e vengono testate pesantemente durante tutto il ciclo di sviluppo. Il seguente piano riduce al minimo la differenza tra i due tipi di build rispetto al DebugFS accesso, e fornisce questi vantaggi:

  • Impedisce userdebug costruisce accidentale seconda DebugFS per nuove funzionalità
  • Assicura che qualsiasi funzionalità esistente interrotta dalla mancanza di DebugFS sia nota all'inizio del ciclo di sviluppo

Debugfs accessi in userdebug generazioni sono così ripartite:

  1. DebugFS inizializzazioni di file durante l'avvio del dispositivo, come ad esempio un accesso in scrittura a un file in DebugFS per attivare la raccolta dei dati di debug.
  2. Generazione bugreport: Il dumpstate Hal legge DebugFS file quando DumpstateBoard() viene richiamato dal dumpstate . Queste informazioni diventano parte della segnalazione di bug.
  3. Test e convalida specifici del dispositivo.

La tabella seguente descrive come ciascuna di queste tre categorie è supportata in Android 11 e Android 12. Si noti che il seguente applica solo a userdebug costruisce poiché DebugFS non possono essere montati in utente crea.

Caso d'uso build del debug dell'utente di Android 11 Build del debug dell'utente di Android 12
Un tempo DebugFS file di inizializzazione, durante l'avvio. Questo accesso avviene una sola volta durante l'avvio. Init fornitore fa questo. Dumpstate HAL esegue questa operazione durante l'inizializzazione di HAL. Per abilitare gli stessi, init monta DebugFS in userdebug costruisce prima dei inizializza HAL. Init chiamate umount() sul DebugFS quando il dispositivo ha completato l'avvio.
Generazione bugreport: Il dumpstate Hal legge DebugFS file, che diventano parte del bug report. Fatto da HAL dumpstate entro DumpstateBoard() quando viene richiamato dallo strumento dumpstate. Fatto da HAL dumpstate entro DumpstateBoard() quando viene richiamato da dumpstate ( DumpstateDevice.cpp ). Lo strumento dumpstate (parte del quadro Android) garantisce che DebugFS supporti durante l'invocazione.
Test e convalida specifici del dispositivo Adb root e shell Adb root e shell. Montare DebugFS dalla shell adb con accesso root 1.

1 Per montare DebugFS da adb shell con accesso root, utilizzare questo comando:

adb shell mount -t debugfs debugfs /sys/kernel/debug .

Azioni necessarie per i partner

I partner devono attuare quanto segue in base a queste modifiche nei dispositivi Android 12:

  • Fai tutte le inizializzazioni di boot di DebugFS nodi accadono durante l'inizializzazione HAL dumpstate. Per un esempio di come fare questo, vedere DNM: Esempio per l'avvio di inizializzazione momento della DebugFS file .
  • Non consentire DebugFS accesso durante il runtime. Si applicano le seguenti eccezioni:
    • Generazione di bugreport (proviene da dumpstate HAL)
    • Test e validazione (accessibile adb root e shell - garantire che debugfs è montato prima)

Gli sviluppatori possono impostare la proprietà persistente di debug persist.dbg.keep_debugfs_mounted per mantenere DebugFs montati dopo il riavvio l'userdebug e ita costruisce.

Test GTS conformità garantiscono che le DebugFS filesystem non è montato in utente crea. Sepolicy neverallow dichiarazioni assicurano che nei dispositivi di lancio su Android 12 o superiore, processi non autorizzati non sono forniti accesso ai DebugFs .