Guida del produttore per la sicurezza a lungo termine di Android

Questa guida descrive le best practice consigliate da Google per l'applicazione di patch di sicurezza valutate da Android Compatibility Test Suite (CTS). È destinato ai produttori di apparecchiature OEM compatibili con Android (produttori) che saranno supportate per più di tre anni, come veicoli, TV, set-top box ed elettrodomestici. Questa guida non è destinata agli utenti finali (ad esempio, i proprietari di veicoli).

Ringraziamenti e disclaimer

Questa guida non vincola legalmente o contrattualmente Google o altri produttori e non è intesa come un insieme di requisiti. Questa guida è invece un ausilio didattico che descrive le pratiche consigliate.

Feedback

Questa guida non è esaustiva e sono previste ulteriori revisioni. Invia un feedback all'indirizzo manufacturers-guide-android@googlegroups.com.

Glossario

Termine Definizione
ACC Impegno di compatibilità di Android. Precedentemente noto come Android Anti-Fragmentation Agreement (AFA).
AOSP Android Open Source Project
ASB Bollettino sulla sicurezza di Android
BSP Board Support Package
CDD Compatibility Definition Document
CTS Compatibility Test Suite (CTS)
FOTA firmware over-the-air
GPS sistema GPS
MISRA Motor Industry Software Reliability Association
NIST National Institute of Standards and Technology
OBD diagnostica di bordo (OBD-II è un miglioramento rispetto a OBD-I in termini di capacità e standardizzazione)
OEM produttore di apparecchiature originali
Sistema operativo sistema operativo
SEI Software Engineering Institute
SoC system on chip
SOP inizio della produzione
SPL Livello patch di sicurezza
TPMS tire-pressure monitoring system

Informazioni sul sistema operativo Android

Android è uno stack software completo open source basato su Linux progettato per una varietà di dispositivi e fattori di forma. Dalla sua prima release nel 2008, Android è diventato il sistema operativo più diffuso, alimentando oltre 1,4 miliardi di dispositivi in tutto il mondo (2016). A marzo 2017, circa il 67% di questi dispositivi utilizzava Android 5.0 (Lollipop) o versioni successive (dati più recenti sono disponibili nella dashboard Android). Sebbene la stragrande maggioranza dei dispositivi siano telefoni cellulari e tablet, Android sta crescendo negli smartwatch, nelle TV e nei dispositivi di infotainment in-vehicle (IVI) per auto.

Il numero di app per Android disponibili nel Google Play Store ha raggiunto oltre 2,2 milioni (2016). Lo sviluppo di app per Android è supportato dal programma di compatibilità Android, che definisce un insieme di requisiti tramite il Compatibility Definition Document (CDD) e fornisce strumenti di test tramite la Compatibility Test Suite (CTS). I programmi di compatibilità Android garantiscono che qualsiasi app Android possa essere eseguita su qualsiasi dispositivo compatibile con Android che supporti le funzionalità richieste per l'app.

Google rilascia regolarmente nuove versioni del sistema operativo, aggiornamenti della sicurezza del sistema operativo e informazioni sulle vulnerabilità scoperte. I produttori devono consultare i bollettini sulla sicurezza di Android per verificare l'applicabilità di questi aggiornamenti ai prodotti supportati dal sistema operativo Android. Per una revisione dei sistemi di sicurezza, compatibilità e build di Android, consulta quanto segue:

Informazioni sui veicoli connessi (prodotti canonici di lunga durata)

I veicoli hanno iniziato a essere connessi con l'introduzione della radio AM negli anni '20. Da lì, il numero di connessioni fisiche e wireless esterne ha iniziato a crescere man mano che gli enti normativi e le case automobilistiche si sono rivolte all'elettronica per semplificare la diagnostica e la manutenzione (ad esempio, la porta OBD-II), migliorare la sicurezza (ad esempio, il TPMS) e raggiungere gli obiettivi di risparmio di carburante. La successiva ondata di connettività ha introdotto funzionalità di comodità per il conducente come l'apertura e la chiusura centralizzata con telecomando, i sistemi telematici e funzionalità di infotainment avanzate come Bluetooth, Wi-Fi e proiezione dello smartphone. Oggi, i sensori e la connettività integrati (ad esempio il GPS) supportano i sistemi di sicurezza e di guida semiautonoma.

Con l'aumento del numero di connessioni del veicolo, aumenta anche l'area della potenziale superficie di attacco del veicolo. Le connessioni comportano una raccolta simile di problemi di cybersicurezza rispetto all'elettronica di consumo. Tuttavia, mentre i riavvii, gli aggiornamenti giornalieri delle patch e i comportamenti inspiegabili sono la norma per l'elettronica di consumo, sono incoerenti per i prodotti con sistemi critici per la sicurezza come i veicoli.

I produttori devono adottare un approccio proattivo per garantire la continuità della sicurezza di un prodotto sul campo. In breve, i produttori devono essere a conoscenza delle vulnerabilità di sicurezza note nel prodotto e adottare un approccio basato sul rischio per risolverle.

Garantire la sicurezza a lungo termine

Un veicolo connesso spesso ha una o più unità di controllo elettronico (ECU) che includono più componenti software come sistema operativo, librerie, utilità e così via. I produttori devono monitorare questi componenti e identificare le vulnerabilità pubblicate note con un'analisi proattiva, tra cui:

  • Valutazione regolare del prodotto rispetto al database delle vulnerabilità ed esposizioni comuni (CVE).
  • Raccolta di informazioni sulle vulnerabilità di sicurezza relative ai prodotti.
  • Test di sicurezza.
  • Analisi attiva dei bollettini sulla sicurezza di Android.

Esempio di aggiornamenti del sistema operativo e delle patch di sicurezza (IVI con Android):

Figura 1. Esempio di implementazione di aggiornamenti principali del sistema operativo e della sicurezza durante il ciclo di vita del veicolo.

# Passaggio Attività

①

 Branch di sviluppo Il produttore seleziona una versione di Android (Android X). In questo esempio, "Android X" diventa la base di ciò che verrà spedito nel veicolo due anni prima dell'inizio della produzione (SOP).
② Lancio iniziale Alcuni mesi prima che Android X diventi la prima versione del sistema operativo spedita nel prodotto, gli aggiornamenti di sicurezza vengono presi dai Bollettini sulla sicurezza di Android (ASB) e potenzialmente da altre fonti ritenute preziose dal produttore. y2 = il secondo Bollettino sulla sicurezza per la versione X di Android, applicato (portato) dal produttore ad Android X. Questo aggiornamento viene fornito nel prodotto e il conto alla rovescia della produzione inizia dall'anno zero con Android X.y2.

In questo esempio, il produttore ha deciso di non spedire la release annuale più recente di Android X+1. I motivi per cui viene spedita la versione più recente includono l'aggiunta di nuove funzionalità, la risoluzione di nuove vulnerabilità di sicurezza e/o la spedizione di servizi Google o di terze parti che richiedono la versione più recente di Android. I motivi contro la spedizione con l'ultima release sono la mancanza di tempo intrinseca al processo di sviluppo e lancio del veicolo necessario per integrare, testare e convalidare le modifiche, inclusa la conformità a tutti i requisiti normativi e di certificazione.
③ Aggiornamento completo del sistema operativo Dopo la SOP, il produttore rilascia l'aggiornamento del sistema operativo Android X+2, che corrisponde a due versioni di Android dopo la versione utilizzata per il prodotto iniziale (Android X0). Gli aggiornamenti della sicurezza ASB sono disponibili per il livello API (a partire dalla data di spedizione), quindi l'aggiornamento viene rilasciato come X+2.y0 circa 1,25 anni dopo l'inizio della produzione. Questo aggiornamento del sistema operativo potrebbe essere compatibile o meno con i prodotti distribuiti. Se lo è, potrebbe essere creato un piano per aggiornare i veicoli distribuiti.

A meno che non siano in vigore altri accordi commerciali, la decisione di eseguire un aggiornamento completo del sistema operativo è interamente a discrezione del produttore.
④ Aggiornamento della sicurezza Due anni dopo l'inizio del ciclo di vita della produzione del veicolo, il produttore applica patch al sistema operativo Android X+2. Questa decisione si basa sulla valutazione del rischio del produttore. Il produttore sceglie il terzo aggiornamento della sicurezza ASB per la release X+2 come base dell'aggiornamento. I prodotti che ricevono l'aggiornamento della sicurezza ora hanno il sistema operativo (X+2.y3) + il livello patch di sicurezza di Android.

Sebbene i produttori possano selezionare singole patch di sicurezza da qualsiasi ASB, devono correggere tutti i problemi richiesti nel bollettino per utilizzare il livello di patch di sicurezza Android (SPL) associato al bollettino (ad esempio, 2017-02-05). È responsabilità del produttore eseguire il backport e il rilascio di sicurezza per il prodotto supportato.
⑤ Aggiornamento completo del sistema operativo Una ripetizione del passaggio 3 (aggiornamento completo del sistema operativo). Il secondo aggiornamento completo del sistema operativo porta il prodotto ad Android X+4, tre anni dopo l'inizio del ciclo di vita di produzione del veicolo. Il produttore sta ora bilanciando i requisiti hardware più recenti di una versione recente di Android con l'hardware del prodotto e i vantaggi per l'utente di un sistema operativo Android aggiornato. Il produttore rilascia un aggiornamento senza aggiornamenti della sicurezza, quindi il prodotto ora ha il sistema operativo (X+4.y0) + il livello patch di sicurezza Android.

In questo esempio, a causa delle limitazioni hardware, X+4 è l'ultima versione principale di Android che verrà fornita per questo prodotto, anche se i 6 anni di durata prevista del veicolo richiedono ancora il supporto della sicurezza.
⑥ Aggiornamento della sicurezza Ripeti il passaggio 4 (Aggiornamento della sicurezza). Il produttore ha il compito di prendere gli aggiornamenti di sicurezza ASB da una versione di Android molto più recente (X+6) e di trasferire alcuni o tutti questi aggiornamenti su Android X+4. È responsabilità del produttore eseguire l'unione, l'integrazione e l'esecuzione degli aggiornamenti (o stipulare un contratto con una terza parte). Inoltre, il produttore deve essere consapevole che i problemi di sicurezza nelle versioni di Android non più supportate non sono trattati nel Bollettino sulla sicurezza di Android.
⑦ Aggiornamento della sicurezza A otto anni dall'inizio del ciclo di vita di produzione del veicolo, quattro release di Android dopo l'ultimo aggiornamento del sistema operativo nel passaggio 5 (aggiornamento completo del sistema operativo) e dieci anni dopo la specifica di Android X, l'onere di curare e eseguire il backporting delle patch di sicurezza ricade interamente sul produttore per le versioni più vecchie di tre anni rispetto alla release pubblica del livello API.

Best practice per la sicurezza

Per rendere più difficili i compromessi della sicurezza, Google consiglia e utilizza le best practice comunemente accettate per la sicurezza e l'ingegneria del software, come descritto in Implementazione della sicurezza.

Linee guida per la sicurezza

Le pratiche consigliate per la sicurezza includono:

  • Utilizza le versioni più recenti di librerie esterne e componenti open source.
  • Non includere funzionalità di debug intrusive nelle versioni release del sistema operativo.
  • Rimuovi le funzionalità inutilizzate (per ridurre la superficie di attacco non necessaria).
  • Utilizza il principio del privilegio minimo e altre best practice per lo sviluppo di app per Android.

Linee guida per lo sviluppo di software

Le pratiche consigliate per lo sviluppo sicuro del software per il ciclo di vita del sistema includono:

  • Esegui la modellazione delle minacce per classificare e identificare asset, minacce e potenziali mitigazioni.
  • Esegui una revisione dell'architettura/progettazione per garantire una progettazione sicura e valida.
  • Esegui revisioni regolari del codice per identificare anti-pattern e bug il prima possibile.
  • Progetta, implementa ed esegui test delle unità con un'elevata copertura del codice, tra cui:
    • Test funzionali (inclusi scenari di test negativi)
    • Test di regressione regolari (per assicurarsi che i bug corretti non riappaiano)
    • Fuzz testing (come parte della suite di test delle unità)
  • Utilizza strumenti di analisi statica del codice sorgente (scan-build, lint e così via) per identificare potenziali problemi.
  • Utilizza strumenti di analisi dinamica del codice sorgente, come AddressSanitizer, UndefinedBehaviorSanitizer e FORTIFY_SOURCE (per i componenti nativi) per identificare e mitigare potenziali problemi durante lo sviluppo del sistema.
  • Avere una strategia di gestione per il codice sorgente del software e la configurazione/versione della release.
  • Avere una strategia di gestione delle patch per la generazione e il deployment delle patch software.

Policy di backporting della sicurezza

Attualmente Google fornisce supporto attivo per i backport di sicurezza delle vulnerabilità di sicurezza scoperte e segnalate per tre (3) anni dal rilascio pubblico del livello API. L'assistenza attiva consiste in quanto segue:

  1. Ricevere ed esaminare i report sulle vulnerabilità.
  2. Crea, testa e rilascia aggiornamenti della sicurezza.
  3. Fornire rilasci ricorrenti di aggiornamenti della sicurezza e dettagli del bollettino di sicurezza.
  4. Esegui la valutazione della gravità in base alle linee guida stabilite.

Tre anni dopo la data di rilascio pubblico del livello API, Google consiglia le seguenti linee guida:

  • Utilizza una terza parte (ad esempio un fornitore di SoC o un fornitore di kernel) per il supporto del backporting per gli aggiornamenti della sicurezza del sistema operativo precedenti a tre anni dal rilascio dell'API.
  • Utilizza una terza parte per eseguire revisioni del codice utilizzando le ASB fornite pubblicamente. Sebbene gli ASB identifichino le vulnerabilità per la versione attualmente supportata, un produttore può utilizzare le informazioni fornite per confrontare gli aggiornamenti appena rilasciati con le versioni precedenti. Questi dati possono essere utilizzati per eseguire l'analisi dell'impatto e potenzialmente generare patch simili per le versioni del sistema operativo precedenti a tre anni dal rilascio dell'API.
  • Se opportuno, carica gli aggiornamenti della sicurezza su Android Open Source Project (AOSP).
  • Il produttore deve coordinare la gestione degli aggiornamenti della sicurezza per il codice specifico del fornitore (ad esempio, codice proprietario specifico del dispositivo).
  • Il produttore deve entrare a far parte del gruppo di notifica di anteprima per i partner dell'NDA Android Security Bulletin (richiede la firma di accordi legali come l'NDA per gli sviluppatori). I bollettini devono includere:
    • Annunci
    • Riepilogo dei problemi per livello patch, inclusi CVE e gravità
    • Dettagli della vulnerabilità, se appropriato

Riferimenti aggiuntivi

Per istruzioni sulle pratiche di codifica e sviluppo di software sicure, consulta quanto segue:

Google incoraggia l'utilizzo delle seguenti pratiche consigliate.

In genere è consigliabile avviare qualsiasi prodotto connesso con l'ultima versione del sistema operativo e un produttore deve tentare di utilizzare la versione più recente del sistema operativo prima di lanciare il prodotto. Sebbene il blocco della versione sia necessario per garantire la stabilità prima dei test e della convalida, il produttore deve bilanciare la stabilità del prodotto ottenuta dalle versioni precedenti del sistema operativo con le versioni più recenti del sistema operativo che presentano meno vulnerabilità di sicurezza note e protezioni di sicurezza avanzate.

Le linee guida consigliate includono:

  • A causa dei lunghi tempi di sviluppo inerenti al processo di sviluppo del veicolo, i produttori potrebbero dover lanciare il sistema operativo con la versione n-2 o precedente.
  • Mantenere la conformità con la compatibilità di Android per ogni versione del sistema operativo Android rilasciata con una campagna over-the-air (OTA).
  • Implementa l'aggiornamento firmware over-the-air (FOTA) del prodotto Android per aggiornamenti rapidi e semplici per i clienti. L'aggiornamento FOTA deve essere eseguito utilizzando le best practice di sicurezza, come la firma del codice e la connessione TLS tra il prodotto e il back office IT.
  • Invia al team di sicurezza Android le vulnerabilità di sicurezza di Android identificate in modo indipendente.

Nota:Google ha preso in considerazione notifiche specifiche per tipo di dispositivo o settore nei bollettini sulla sicurezza di Android. Tuttavia, poiché Google non conosce il kernel, i driver o i chipset di un determinato dispositivo (veicolo, TV, dispositivo indossabile, smartphone e così via), non ha un modo deterministico per etichettare un determinato problema di sicurezza con un tipo di dispositivo.

Il produttore deve fare ogni tentativo per utilizzare l'ultima versione del sistema operativo o gli aggiornamenti della sicurezza per la versione in uso durante i miglioramenti del ciclo di vita del prodotto. Gli aggiornamenti possono essere eseguiti durante gli aggiornamenti periodici ricorrenti dei prodotti o per correzioni rapide per risolvere problemi di qualità e/o di altro tipo. Le pratiche consigliate includono:

  • Crea un piano per gestire gli aggiornamenti di driver, kernel e protocollo.
  • Utilizza un metodo appropriato per il settore per fornire aggiornamenti ai veicoli distribuiti.

Compatibility Definition Document (CDD)

Il Compatibility Definition Document (CDD) descrive i requisiti che un dispositivo deve soddisfare per essere considerato compatibile con Android. Il CDD è pubblico e disponibile per tutti. Puoi scaricare le versioni del CDD da Android 1.6 alla versione più recente da source.android.com.

Soddisfare questi requisiti per un prodotto comporta i seguenti passaggi di base:

  1. Il partner firma l'impegno di compatibilità Android (ACC) con Google. Viene quindi assegnato un consulente per le soluzioni tecniche (TSC) come guida.
  2. Il partner completa la revisione della CDD per la versione del sistema operativo Android del prodotto.
  3. Il partner esegue e invia i risultati del CTS (descritti di seguito) finché non sono accettabili per la compatibilità con Android.

Suite di test di compatibilità (Compatibility Test Suite, CTS)

Lo strumento di test Compatibility Test Suite (CTS) verifica che l'implementazione di un prodotto sia compatibile con Android e che siano incluse le patch di sicurezza più recenti. Il CTS è pubblico, open source e disponibile per tutti. Puoi scaricare le versioni del CTS da Android 1.6 all'ultima versione da source.android.com.

Ogni build del software Android rilasciata al pubblico (immagini di installazione di fabbrica e aggiornamento sul campo) deve dimostrare la compatibilità con Android tramite i risultati del CTS. Ad esempio, se il dispositivo esegue Android 7.1, è necessario fare riferimento all'ultima versione corrispondente di CDD 7.1 e CTS 7.1 quando viene creata e testata un'immagine di build con intent di rilascio. I produttori sono fortemente incoraggiati a utilizzare CTS in modo tempestivo e frequente per identificare e risolvere i problemi.

NOTA: i partner che firmano altri contratti, ad esempio Google Mobile Services (GMS), potrebbero dover soddisfare altri requisiti.

Flusso di lavoro CTS

Il workflow CTS prevede la configurazione dell'ambiente di test, l'esecuzione dei test, l'interpretazione dei risultati e la comprensione del codice sorgente CTS. Le seguenti linee guida hanno lo scopo di aiutare gli utenti CTS (ad esempio sviluppatori, produttori) a utilizzare il CTS in modo efficace ed efficiente.

  • Esegui test frequenti. CTS è progettato come strumento automatizzato che si integra nel sistema di build. L'esecuzione frequente di CTS può aiutarti a trovare i difetti rapidamente e in anticipo quando si verificano regressioni o un degrado del software.
  • Scarica ed esamina il codice sorgente del CTS. Il codice sorgente completo di CTS è un software open source che chiunque può scaricare e utilizzare (il codice sorgente scaricato è completamente compilabile ed eseguibile). Quando un test non riesce sul dispositivo, l'esame della sezione pertinente del codice sorgente può aiutarti a identificare il motivo.
  • Scarica l'ultima versione del CTS. Le nuove release di Android possono aggiornare il CTS con correzioni di bug, miglioramenti e nuovi test. Controlla Download CTS di frequente e aggiorna il programma CTS in base alle necessità. Il produttore e Google concorderanno la versione CTS da superare per il lancio del prodotto, in quanto il prodotto deve essere bloccato a un certo punto mentre il CTS continua a essere aggiornato.

Superare il CTS

Per un prodotto compatibile con Android, Google garantisce che i risultati dei test CTS e CTS Verifier del dispositivo siano accettabili. In linea di principio, tutti i test devono essere superati. Tuttavia, un test che non riesce per motivi diversi dalla mancata conformità del dispositivo ai requisiti di compatibilità Android è soggetto a revisione da parte di Google. Durante questo processo:

  1. Il produttore fornisce a Google le patch CTS proposte, le relative convalide e le giustificazioni per dimostrare l'argomento.
  2. Google esamina il materiale inviato e, se accettato, aggiorna i test CTS pertinenti in modo che il dispositivo superi la revisione successiva di CTS.

Se un test CTS non va a buon fine dopo l'applicazione di una patch di sicurezza, il produttore deve modificare la patch in modo che non interrompa la compatibilità OPPURE dimostrare che il test è errato e fornire una correzione per il test (come descritto sopra).

Il CTS rimane aperto per le revisioni delle correzioni dei test. Ad esempio, Android 4.4 continua ad accettare correzioni (vedi https://android-review.googlesource.com/c/platform/cts/+/273371).

Domande frequenti

D: Chi è responsabile dell'applicazione degli aggiornamenti della sicurezza a un'implementazione specifica di Android?

R: Il responsabile è il produttore che fornisce direttamente il dispositivo. Questa entità non è Google, che pubblica aggiornamenti della sicurezza in AOSP e non per un dispositivo specifico (ad esempio un veicolo).

D: In che modo Google gestisce i problemi di sicurezza in Android?

R: Google esamina continuamente i problemi e sviluppa potenziali correzioni, che rende disponibili per tutti i livelli API supportati nell'ambito del normale processo di aggiornamento della sicurezza. Da agosto 2015, Google pubblica regolarmente bollettini e link agli aggiornamenti su source.android.com; Google pubblica anche aggiornamenti della sicurezza nell'ambito delle versioni principali del sistema operativo. Vedi anche le Norme di backporting della sicurezza.

D: Se un produttore ha integrato tutte le patch AOSP di un ASB, ma non ha integrato le patch del fornitore BSP menzionate nello stesso bollettino, può comunque aumentare il livello di sicurezza (ad esempio, applicare la patch corrispondente a platform/build)?

R: Per dichiarare un livello di patch di sicurezza Android (SPL), un produttore deve risolvere tutti i problemi richiesti pubblicati nel Bollettino sulla sicurezza di Android (inclusi i bollettini precedenti) e mappati a un particolare SPL Android. Ad esempio, un produttore che utilizza il bollettino sulla sicurezza di marzo 2017 (SPL 2017-03-01) ha risolto tutti i problemi richiesti documentati nel bollettino di marzo 2017 per questo SPL e tutti gli aggiornamenti precedenti, inclusi gli aggiornamenti specifici del dispositivo per tutti i bollettini sulla sicurezza di Android precedenti, inclusi gli aggiornamenti specifici del dispositivo associati all'SPL 2017-02-05.

D: Cosa succede quando il produttore non è d'accordo con gli aggiornamenti della sicurezza forniti dal fornitore BSP O quando gli aggiornamenti della sicurezza imposti da un ASB non vengono forniti dai fornitori?

R: Un ASB descrive le vulnerabilità di sicurezza (elencate in un elenco di CVE) e spesso fornisce test di sicurezza corrispondenti. L'obiettivo è garantire che le vulnerabilità elencate non possano più essere riprodotte su un dispositivo e che il dispositivo possa superare i test di sicurezza associati. Pertanto, il problema non riguarda l'applicazione di un aggiornamento della sicurezza fornito da Google o da un fornitore di terze parti, ma l'attestazione del produttore che il dispositivo non è vulnerabile all'elenco di CVE nell'ASB. Il produttore è libero di utilizzare gli aggiornamenti della sicurezza forniti o, se ha una modifica più appropriata per il proprio dispositivo, di utilizzare quella.

Ad esempio, considera un caso in cui Google risolve una vulnerabilità di sicurezza AOSP utilizzando una modifica del codice che consente al componente di rimanere pienamente funzionale e conforme alla CDD. Se il produttore stabilisce che il componente non è necessario sul dispositivo o non è obbligatorio in base al CDD (o ai test di certificazione correlati), può rimuoverlo per ridurre le future esigenze di manutenzione e la superficie di attacco. Sebbene il produttore non abbia utilizzato l'aggiornamento della sicurezza fornito, ha garantito che il dispositivo non sia vulnerabile alla CVE documentata nel bollettino di sicurezza. Tuttavia, allontanandosi dall'aggiornamento della sicurezza consigliato, il produttore si assume il rischio di risolvere in modo errato il problema, introducendo nuove vulnerabilità di sicurezza o riducendo in altro modo la funzionalità della build finale.

Collaboriamo con tutti i partner SoC per garantire che esistano correzioni per tutti i problemi in un ASB, ma consigliamo ai produttori di stipulare un contratto di assistenza con i fornitori di SoC per il ciclo di vita di un dispositivo. I SoC potrebbero smettere di supportare un chipset prima del previsto, quindi stabilire accordi prima della selezione del chipset del dispositivo è una parte importante della procedura di lancio del dispositivo.

Infine, nei casi in cui è impossibile acquisire direttamente o creare in modo indipendente una correzione per un problema documentato in un ASB, un produttore potrebbe mantenere lo SPL Android precedente e aggiungere comunque le nuove correzioni disponibili alla build. Tuttavia, questa pratica alla fine porterà a problemi con la certificazione della build (in quanto Android garantisce che l'ultimo livello di patch di sicurezza sia disponibile sui dispositivi certificati). Google consiglia di collaborare in anticipo con il tuo SoC per evitare questa pratica.

D: Se il produttore stabilisce che un elemento ASB non è applicabile al suo prodotto, l'elemento deve comunque essere applicato o corretto per soddisfare gli altri requisiti di Google o per superare il test CTS?

R: Non richiediamo l'applicazione di patch per dichiarare un livello di patch di sicurezza Android (SPL). Richiediamo invece che il produttore attesti che la sua build non è vulnerabile al problema.

Un esempio è quando un componente di cui viene applicata una patch non esiste nel sistema del produttore oppure un componente viene rimosso dal sistema del produttore per risolvere un problema. In questo caso, il sistema potrebbe essere conforme senza richiedere al produttore di applicare una patch.

Ciò è fondamentalmente diverso da un produttore che vuole, ad esempio, correggere solo le patch critiche, senza applicare altre patch applicabili che causerebbero il mancato superamento di un test di sicurezza. In questo caso si presume che la SPL non sia stata soddisfatta.