SDK Runtime

Inviare feedback

La piattaforma Android utilizza il concetto di sandboxing delle app per mantenere limiti di esecuzione e sicurezza solidi per il codice dell'app, oltre ai limiti dei processi. È prassi comune per le app includere codice di terze parti, spesso sotto forma di SDK come SDK per gli annunci o SDK di analisi. Questo riutilizzo consente agli sviluppatori di app di concentrarsi sulla differenziazione delle app e, al contempo, di sfruttare il lavoro degli esperti in materia per scalare la loro esecuzione oltre le semplici operazioni che potrebbero svolgere in autonomia.

Come la maggior parte dei sistemi operativi, gli SDK Android vengono eseguiti all'interno della sandbox dell'app host ed ereditano gli stessi privilegi e le stesse autorizzazioni dell'app host, nonché l'accesso alla memoria e allo spazio di archiviazione dell'app host. Sebbene questa architettura consenta un'integrazione flessibile di SDK e app, crea anche il potenziale per la raccolta e la condivisione di dati utente non visibili. Inoltre, gli sviluppatori di app potrebbero non essere pienamente consapevoli della portata della funzionalità di un SDK di terze parti e dei dati a cui accede, il che rende difficile tenere conto delle pratiche di raccolta e condivisione dei dati della loro app.

In Android 13, abbiamo aggiunto una nuova funzionalità della piattaforma che consente l'esecuzione degli SDK di terze parti in un ambiente di runtime dedicato chiamato SDK Runtime. SDK Runtime fornisce le seguenti garanzie e misure di salvaguardia più efficaci per la raccolta e la condivisione dei dati utente:

  • Un ambiente di esecuzione modificato
  • Autorizzazioni e diritti di accesso ai dati ben definiti per gli SDK

Stiamo cercando attivamente un feedback su questo design da parte della community pubblicitaria delle app mobile. Siamo lieti di ricevere feedback dalla più ampia community di sviluppatori, che ci aiuterà a definire iterazioni future di SDK Runtime, compreso il supporto per casi d'uso aggiuntivi.

Obiettivi

La presente proposta si propone di raggiungere i seguenti obiettivi:

  • Riduci l'accesso non dichiarato e la condivisione dei dati dell'app di un utente da parte di SDK di terze parti tramite l'isolamento dei processi e il controllo dell'accesso ai dati e delle API ben definito. Scopri di più sull'isolamento dei processi in una sezione separata di questo documento.
  • Riduci il monitoraggio non dichiarato dell'utilizzo delle app da parte di un utente da parte di SDK di terze parti limitando l'accesso da parte degli SDK a identificatori univoci e permanenti.
  • Accelera in modo sicuro la distribuzione degli aggiornamenti dell'SDK nelle app riducendo il carico per sviluppatori di app e utenti finali. Scopri di più sul modello di distribuzione di SDK attendibili proposto in un'altra sezione di questo documento.
  • Aiutare gli sviluppatori di app a tenere maggiormente conto delle pratiche di accesso e condivisione dei dati della loro app.
  • Aiuta gli sviluppatori di SDK a impedire le manomissioni da parte di altri SDK tramite la limitazione di determinati costrutti di linguaggio non sicuro come il codice JNI.
  • Aiuta gli SDK per gli annunci a rilevare e prevenire il traffico non valido e le frodi pubblicitarie attraverso il controllo completo sulle visualizzazioni remote che mostrano i contenuti multimediali.
  • Riduci al minimo l'impatto indebito per gli sviluppatori di app e SDK.

Gli SDK vengono eseguiti in un processo isolato

Il runtime SDK proposto consente agli SDK compatibili, definiti in tutto il resto di questo documento come SDK abilitati per runtime (RE), di operare in un processo separato per l'app. La piattaforma facilita la comunicazione bidirezionale tra il processo dell'app e il relativo SDK Runtime. Per informazioni dettagliate, consulta la sezione relativa alle comunicazioni di questo documento. Gli SDK non RE rimarranno nel processo dell'app come fanno attualmente. I seguenti diagrammi illustrano queste modifiche:

Diagramma prima che mostra tutto ciò che esegue il processo dell'app
Prima di essere aggiunto a SDK Runtime, il codice di chiamata SDK, insieme agli SDK che ricevono le chiamate da questo codice, risiedono nel processo dell'app

Dopo il diagramma che mostra i processi divisi tra il processo dell'app e quello di runtime dell'SDK
Dopo essere stato aggiunto a SDK Runtime, il codice di chiamata SDK, nel processo in primo piano dell'app, il codice di chiamata dell'SDK comunica con le interfacce dell'SDK. Queste interfacce attraversano quindi un confine del processo nel processo di SDK Runtime per chiamare gli SDK stessi.

Nuovo modello di distribuzione affidabile per gli SDK

Questa proposta di separazione tra SDK e app motiva un altro concetto di separazione, uno per la distribuzione di SDK e app. La nostra proposta richiede un meccanismo di distribuzione e installazione affidabile per garantire che gli SDK corretti siano installati nel runtime SDK di un'app. Ciò contribuisce a proteggere utenti e sviluppatori di app dal caricamento di SDK non validi, consentendo allo stesso tempo agli store di ridurre significativamente il carico della distribuzione dell'SDK da parte degli sviluppatori di app.

Non è più necessario collegare e pacchettizzare in modo statico gli SDK con le rispettive app prima di essere caricati in uno store per la distribuzione. Si aprirà il seguente processo:

  1. Gli sviluppatori di SDK potevano caricare gli SDK sottoposti al controllo delle versioni negli store, separati dalle app stesse.
  2. Gli sviluppatori di app possono specificare le dipendenze dell'SDK per versione, build e caricare una release dell'app che non include le dipendenze effettive dell'SDK.
  3. Quando un utente scarica questa app, la procedura di installazione potrebbe utilizzare le dipendenze SDK specificate dell'app per poi scaricarle dallo store.

Questo innovativo meccanismo di distribuzione consente agli sviluppatori di SDK di apportare modifiche non rivoluzionarie (ovvero, nessuna modifica alle API o alla loro semantica) ai propri SDK e di distribuirli ai dispositivi senza il coinvolgimento degli sviluppatori di app. È possibile eseguire il deployment o il rollback di queste modifiche sostanziali all'SDK, senza dover attendere che gli sviluppatori di app ricreano le proprie app con i nuovi SDK o attendere che gli utenti finali aggiornino le loro app. Le modifiche che provocano errori dovrebbero comunque essere aggiornate dagli sviluppatori di app, ma gli sviluppatori di SDK potrebbero ricevere le ultime modifiche e apportare correzioni più rapidamente e in modo più uniforme per un maggior numero di persone, idealmente riducendo al minimo il supporto delle versioni.

I seguenti diagrammi illustrano le modifiche proposte per la distribuzione dell'SDK:

Diagramma precedente
Prima dell'introduzione di SDK Runtime, gli sviluppatori inviano i loro SDK direttamente alle app.

Dopo il diagramma
Dopo l'introduzione di SDK Runtime, d, gli sviluppatori di SDK usavano un'UI di caricamento dell'SDK per pubblicare i propri SDK in uno store. Lo store gestirebbe quindi la distribuzione delle app, insieme a eventuali dipendenze dell'SDK, ai dispositivi degli utenti finali.

Modifiche alle modalità di creazione, esecuzione e distribuzione di SDK e app

Questa è una proposta iniziale per una tecnologia di distribuzione e runtime dell'SDK flessibile. Le seguenti sezioni propongono una serie di modifiche alle seguenti ampie categorie:

  • Accesso: autorizzazioni, memoria, spazio di archiviazione
  • Esecuzione: lingue, modifiche al runtime, ciclo di vita, rendering multimediale
  • Comunicazioni: app-to-SDK e SDK-to-SDK
  • Sviluppo: come creare, eseguire il debug e testare in questo modello
  • Distribuzione: come distribuire, aggiornare e eseguire il rollback di tutte le versioni di Android, app e SDK

Questo documento include anche le Domande frequenti per rispondere a domande comuni.

Questa è una proposta di progettazione iniziale e siamo consapevoli che potrebbe essere un cambiamento significativo per alcuni membri dell'ecosistema. Per questo motivo, richiediamo attivamente il tuo feedback tramite il tracker dei problemi.

Accesso

Gestire la privacy di un sistema implica la gestione del modo in cui parti diverse possono accedere a risorse diverse. Per soddisfare la nostra proposta di valore relativa alla privacy, proponiamo di aggiornare il modello per l'accesso ad app, SDK e dati utente in modo da seguire il principio del privilegio minimo e impedire l'accesso non dichiarato a dati potenzialmente sensibili.

Autorizzazioni SDK

Come processo separato, SDK Runtime avrà un proprio set di autorizzazioni ben definito, anziché ereditare quelle concesse dall'utente all'app. In base a una ricerca preliminare sulle autorizzazioni utilizzate dagli SDK relativi agli annunci, proponiamo che le seguenti autorizzazioni siano accessibili per impostazione predefinita agli SDK nel runtime dell'SDK:

  • INTERNET: accesso a internet per poter comunicare con un servizio web.
  • ACCESS_NETWORK_STATE: per accedere alle informazioni sulle reti.
  • Autorizzazioni di accesso alle API incentrate sulla tutela della privacy, che forniscono funzionalità pubblicitarie di base senza bisogno di accedere a identificatori tra app.
  • AD_ID: possibilità di richiedere l'ID pubblicità. Inoltre, l'accesso dell'app a questa autorizzazione dipende dalla limitazione.
  • BIND_GET_INSTALL_REFERRER_SERVICE: possibilità di utilizzare l'API Google Play Referrer di installazione per attribuire l'origine dell'installazione di un'app.

Al momento stiamo esaminando se e come autorizzare autorizzazioni aggiuntive, limitando l'impatto sugli utenti finali dal punto di vista della privacy e dell'usabilità. Richiediamo feedback su tutti i casi d'uso che potrebbero non essere soddisfatti da questo insieme di autorizzazioni.

Memoria

SDK Runtime disponeva del proprio spazio di memoria isolato, perché dispone di un proprio processo. Per impostazione predefinita, questa struttura negherebbe l'accesso all'SDK allo spazio di memoria dell'app e, analogamente, l'applicazione non sarebbe in grado di accedere allo spazio di memoria dell'SDK. Proponiamo di mantenere questo comportamento predefinito in linea con il principio del privilegio minimo.

Archiviazione

Questa proposta intende bilanciare la necessità da parte degli SDK di accedere allo spazio di archiviazione per il loro normale funzionamento e ridurre al minimo il monitoraggio tra app e tra processi utilizzando l'archiviazione permanente. Attualmente proponiamo il seguente aggiornamento per le modalità di accesso allo spazio di archiviazione:

  • Un'app non potrà accedere direttamente al suo spazio di archiviazione degli SDK e viceversa.
  • L'unità di archiviazione esterna del dispositivo non sarà accessibile agli SDK.
  • All'interno di ogni SDK Runtime, sarebbe disponibile sia lo spazio di archiviazione accessibile a tutti gli SDK sia lo spazio privato per un determinato SDK.

Come il modello di archiviazione attuale, lo spazio di archiviazione in sé non avrà limiti arbitrari di dimensione. Gli SDK possono utilizzare spazio di archiviazione per gli asset di memorizzazione nella cache. Questo spazio di archiviazione viene cancellato periodicamente quando l'SDK non è in esecuzione attiva.

Attuazione

Per garantire un sistema privato tra app, SDK e utenti, il contesto di esecuzione stesso (formati di codice, costrutti del linguaggio, API accessibili e dati di sistema) deve rafforzare questi limiti di privacy o quanto meno non introdurre opportunità per eluderli. Allo stesso tempo, vogliamo mantenere l'accesso alla piattaforma completa e alla maggior parte delle funzionalità di runtime attualmente di cui dispongono gli SDK. Qui proponiamo una serie di aggiornamenti all'ambiente di runtime per raggiungere questo equilibrio.

Codice

Il codice Android (app e SDK) viene interpretato prevalentemente da Android Runtime (ART), indipendentemente dal fatto che sia stato scritto in Kotlin o Java. La ricchezza dell'artwork e la formulazione del linguaggio che offre, insieme alla verificabilità che offre rispetto alle alternative, in particolare il codice nativo, sembrano bilanciare correttamente funzionalità e privacy. Proponiamo che il codice SDK abilitato per il runtime sia costituito esclusivamente da bytecode Dex, anziché supportare l'accesso JNI.

Sappiamo che esistono casi d'uso, come l'uso di SQLite pacchettizzato personalizzato, che, dato l'uso di codice nativo, dovrà essere sostituito con un'alternativa come la versione SQLite integrata dell'SDK Android.

SELinux

Su Android, ogni processo (incluse quelli in esecuzione come root) viene eseguito con un contesto SELinux specifico, che consente al kernel di gestire il controllo dell'accesso a servizi di sistema, file, dispositivi e altri processi. Per cercare di preservare la maggior parte dei casi d'uso degli SDK riducendo al minimo la circonvenzione delle protezioni della privacy che stiamo cercando di proseguire, proponiamo i seguenti aggiornamenti dal contesto SELinux di un'app non di sistema per l'SDK Runtime:

  • Un insieme limitato di servizi di sistema sarebbe accessibile. (in progettazione attiva)
  • Gli SDK potrebbero soltanto caricare ed eseguire il codice nell'APK.
  • Saresti accessibile a un insieme limitato di proprietà di sistema. (in progettazione attiva)

API

È consentito l'uso di API di riflessione e di richiamo all'interno del runtime dell'SDK. Tuttavia, un SDK non potrà utilizzare riflessioni o richiamare API su un altro SDK abilitato per runtime. Condivideremo una proposta completa di API vietate in un futuro aggiornamento.

Inoltre, le recenti release della piattaforma Android hanno limitato sempre di più l'accesso agli identificatori persistenti per migliorare la privacy. Per il runtime SDK proponiamo di limitare ulteriormente l'accesso agli identificatori che potrebbero essere utilizzati per il monitoraggio tra app.

Le API SDK Runtime sono accessibili solo dalle app in esecuzione in primo piano. Il tentativo di accedere alle API SdkSandboxManager dalle app in background comporta il lancio di SecurityException.

Infine, gli SDK RE non possono utilizzare le API Notifications per l'invio di notifiche agli utenti in qualsiasi momento.

Lifecycle

Al momento, gli SDK delle app seguono il ciclo di vita dell'app host, ovvero quando l'app entra in primo piano, si arresta o viene arrestata forzatamente dal sistema operativo a causa della pressione dovuta alla memoria, lo fanno anche gli SDK dell'app. La nostra proposta di separare gli SDK di un'app in un processo diverso implica le seguenti modifiche del ciclo di vita:

  • L'app può essere terminata dall'utente o dal sistema operativo. SDK Runtime verrà interrotto automaticamente immediatamente dopo.
  • SDK Runtime può essere interrotto dal sistema operativo a causa della pressione della memoria o di un'eccezione non gestita in un SDK.

    Per Android 13, quando un'app è in primo piano, SDK Runtime viene eseguito con priorità elevata ed è improbabile che venga interrotto. Quando l'app passa in background, la priorità del processo SDK Runtime si riduce e l'app diventa idonea alla chiusura. La priorità del processo SDK Runtime rimane bassa anche se l'app torna in primo piano. Di conseguenza, è molto probabile che venga terminato sotto pressione di memoria rispetto all'app.

    Per Android 14 e versioni successive, le priorità del processo dell'app e del runtime dell'SDK sono allineate. Le priorità di processo per ActivityManager.RunningAppProcessInfo.importance per l'app e per il runtime SDK devono essere all'incirca le stesse.

    Nel caso in cui SDK Runtime venga terminato mentre l'app è attiva, ad esempio in caso di un'eccezione non gestita nell'SDK, lo stato di SDK Runtime, inclusi tutti gli SDK e le viste remote caricati in precedenza, andrà perso. Lo sviluppatore di app può gestire la terminazione di SDK Runtime utilizzando uno dei seguenti metodi:

    • La proposta offre agli sviluppatori di app i metodi di callback del ciclo di vita per rilevare quando si è verificata la terminazione di SDK Runtime.
    • Se SDK Runtime termina mentre gli annunci vengono visualizzati, questi potrebbero non funzionare come previsto. Ad esempio, le visualizzazioni potrebbero essere bloccate sullo schermo e non essere più interattive. L'app può rimuovere la visualizzazione dell'annuncio se questa non influisce sull'esperienza utente.
    • L'app può fare un altro tentativo per caricare gli SDK e richiedere annunci.
    • Per Android 14, se SDK Runtime viene terminato mentre sono caricati gli SDK e se lo sviluppatore di app non ha registrato i metodi di callback del ciclo di vita descritti in precedenza, l'app termina per impostazione predefinita. Solo i processi dell'app con SDK caricati vengono terminati ed escono normalmente.
    • Gli oggetti Binder restituiti dall'SDK per comunicare con l'SDK (ad esempio SandboxedSdk) generano un DeadObjectException se utilizzati dall'app.

    Questo modello di ciclo di vita è soggetto a modifiche nei prossimi aggiornamenti.

    In caso di errori persistenti, lo sviluppatore dell'app deve pianificare il degrado controllato senza l'SDK o informare l'utente se l'SDK è fondamentale per la funzionalità di base dell'app. Per ulteriori dettagli su questa interazione tra app e SDK, consulta la sezione sulle comunicazioni di questo documento.

Gli SDK non RE possono continuare a utilizzare primitive del sistema operativo standard disponibili per la propria app incorporata, inclusi servizi, attività e trasmissioni, mentre gli SDK RE non possono.

Casi particolari

I seguenti casi non sono supportati e potrebbero generare comportamenti imprevisti:

  • Se più app condividono lo stesso UID, SDK Runtime potrebbe non funzionare correttamente. In futuro potrebbe essere aggiunto il supporto per gli UID condivisi.
  • Per le app con più processi, il caricamento dell'SDK deve essere completato nel processo principale.

Rendering multimediale

Esistono SDK che visualizzano contenuti come testo, immagini e video in una visualizzazione specificata dall'app. A questo scopo, proponiamo un approccio di rendering remoto in cui l'SDK eseguirà il rendering dei contenuti multimediali dall'interno di SDK Runtime, ma useremo l'API SurfaceControlViewHost per consentire il rendering dei contenuti multimediali in una vista specificata dall'app. In questo modo, l'SDK è in grado di eseguire il rendering di questi contenuti multimediali in modo privato per l'utente, contribuendo al contempo a prevenire e rilevare interazioni non valide o fraudolente dell'utente con i contenuti multimediali visualizzati.

Gli annunci nativi, ovvero quelli che non vengono visualizzati dall'SDK, ma dall'app, saranno supportati dagli SDK in SDK Runtime. Il processo di raccolta degli indicatori e delle creatività viene eseguito in modo coerente con gli annunci non nativi. Questa è un'area di indagine attiva.

Gli annunci video in-stream sono quelli che vengono eseguiti in-stream con un video, mostrato in un player all'interno di un'app. Poiché il video viene riprodotto in un player all'interno dell'app, anziché in un player o in una visualizzazione nell'SDK, il modello di rendering è diverso dagli altri formati di annunci. Stiamo esplorando attivamente i meccanismi per supportare sia l'inserimento di annunci lato server sia l'inserimento di annunci basato su SDK.

Integrità del sistema

Cerchiamo di ridurre al minimo l'impatto sull'integrità del sistema che SDK Runtime ha sui dispositivi degli utenti finali e stiamo progettando dei modi per farlo. Molto probabilmente, però, alcuni dispositivi Android 13 di livello base con risorse di sistema molto limitate, come Android Go, non supporteranno SDK Runtime a causa dell'impatto sull'integrità del sistema. A breve condivideremo i requisiti minimi necessari per utilizzare correttamente SDK Runtime.

Comunicazioni

Poiché le app e gli SDK attualmente vengono eseguiti nello stesso processo, la comunicazione tra questi è illimitata e senza mediazione. Inoltre, Android consente la comunicazione tra app anche se la comunicazione inizia e termina con gli SDK. Questo modello di comunicazione a flusso libero consente vari casi d'uso, offrendo al contempo la possibilità di condivisione di dati non dichiarati tra app e tra SDK all'interno e tra le app. Proponiamo i seguenti aggiornamenti di questo modello di comunicazione per trovare un equilibrio tra il valore di tale comunicazione e la realizzazione degli obiettivi dichiarati.

Da app a SDK

L'interfaccia tra l'app e l'SDK è il percorso di comunicazione più comune verso un SDK e nell'API di un SDK risiede gran parte della differenziazione e innovazione rivolta all'utente. In questo caso, cerchiamo di preservare la capacità degli SDK di innovare e differenziarsi. Di conseguenza, la nostra proposta consente agli SDK di esporre le API alle app e di garantire che le app possano trarre vantaggio da tutta questa innovazione.

Data la struttura dei limiti del processo di SDK Runtime, proponiamo di creare un livello di marshaling, accessibile all'interno dell'app, per trasferire le chiamate, le risposte o i callback API attraverso questo confine tra l'app e l'SDK. Proponiamo che l'interfaccia per questo livello di marshalling sia definita dagli sviluppatori di SDK e generata da strumenti di creazione open source ufficiali che svilupperemo.

Con questa proposta, cerchiamo di rimuovere il lavoro di marshaling boilerplate dagli sviluppatori di app e SDK, offrendo al contempo flessibilità agli sviluppatori di SDK e garantendo che il codice SDK venga eseguito in SDK Runtime per raggiungere i nostri obiettivi di privacy. Se seguiamo questo percorso, il linguaggio e gli strumenti di definizione dell'API dovrebbero essere progettati in base al tuo input.

Il modello di interazione generale sarebbe il seguente:

  • L'app chiama l'SDK attraverso l'interfaccia, trasmettendo i callback.
  • L'SDK soddisfa le richieste in modo asincrono e risponde utilizzando i callback.
  • Questo può essere generalizzato a qualsiasi modello di abbonato publisher, il che significa che un'app può iscriversi a eventi nell'SDK con callback e, quando si verificano questi eventi, vengono attivati i callback.

Una conseguenza della nuova struttura cross-process di questa proposta è che ci sono due cicli di vita dei processi che dovrebbero essere gestiti: uno per l'app stessa e l'altro per SDK Runtime. La nostra proposta mira ad automatizzare quanto più possibile tutto questo, riducendo al minimo l'impatto per gli sviluppatori di app e SDK. Il seguente diagramma mostra un approccio che stiamo prendendo in considerazione:

Diagramma
Diagramma di sequenza che mostra le interazioni tra app e SDK durante l'avvio di app e SDK.

La piattaforma esporrà nuove API per le app al fine di caricare dinamicamente SDK nel processo SDK Runtime, ricevere notifiche sulle modifiche dello stato del processo e interagire con gli SDK caricati in SDK Runtime.

Il grafico nella figura precedente mostra la comunicazione tra app a un livello inferiore, senza il livello di marshaling.

L'app comunica con l'SDK in esecuzione nel processo di SDK Runtime tramite i seguenti passaggi:

  1. Prima che un'app potesse interagire con un SDK, l'app richiedeva alla piattaforma di caricare l'SDK. Per garantire l'integrità del sistema, le app specificano gli SDK che intendono caricare nel file manifest e questi SDK sono gli unici che possono essere caricati.

    Lo snippet di codice riportato di seguito fornisce un esempio pratico dell'API:

    SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
        OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
    
  2. L'SDK riceve una notifica che l'ha caricato e restituisce la sua interfaccia. Questa interfaccia è pensata per essere utilizzata dal processo dell'app. Per condividere l'interfaccia al di fuori del confine del processo, deve essere restituita come oggetto IBinder.

    La guida ai servizi associati offre diversi modi per fornire IBinder. Qualunque metodo tu scelga, deve essere coerente tra l'SDK e l'app del chiamante. I diagrammi utilizzano AIDL come esempio.

  3. SdkSandboxManager riceve l'interfaccia IBinder e la restituisce all'app.

  4. L'app riceve l'oggetto IBinder e lo trasmette nell'interfaccia dell'SDK, richiamando le sue funzioni:

    IBinder binder = sandboxSdk.getInterface();
    ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
    mySdkInterface.something();
    

L'app può anche eseguire il rendering di contenuti multimediali dall'SDK seguendo questa procedura:

  1. Come spiegato nella sezione relativa al rendering dei contenuti multimediali di questo documento, per ottenere un SDK per il rendering dei contenuti multimediali in una vista, l'app potrebbe effettuare una chiamata a requestSurfacePackage() e recuperare il SurfaceControlViewHost.SurfacePackage appropriato.

    Lo snippet di codice riportato di seguito fornisce un esempio pratico dell'API:

    SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
            Executor executor,
            OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
    
  2. L'app potrebbe quindi incorporare il valore SurfacePackage restituito in SurfaceView tramite l'API setChildSurfacePackage in SurfaceView.

    Lo snippet di codice riportato di seguito fornisce un esempio pratico dell'API:

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
    

La nostra proposta è che le API IBinder e requestSurfacePackage() siano generiche e non debbano essere richiamate direttamente dalle app. Queste API verrebbero invece chiamate dal riferimento API generato di cui sopra, in un livello "shim", per ridurre il carico per gli sviluppatori di app.

Da SDK a SDK

Spesso due SDK nella stessa app hanno bisogno di comunicare. Questo può accadere quando un determinato SDK è stato progettato per essere composto da SDK costituenti e può verificarsi quando due SDK di parti diverse devono collaborare per soddisfare una richiesta dall'app di chiamata.

Ci sono due casi fondamentali da considerare:

  • Quando entrambi gli SDK sono abilitati per il runtime. In questo caso, entrambi gli SDK sono in esecuzione in SDK Runtime con tutte le relative protezioni. Attualmente gli SDK non sono in grado di comunicare come fanno all'interno di un'app. Di conseguenza, è stata aggiunta un'API in SdkSandboxController per abilitare il recupero degli oggetti SandboxedSdk per tutti i RE-SDK caricati. Ciò consente a un RE-SDK di comunicare con altri SDK caricati in SDK Runtime.
  • Quando un solo SDK è abilitato per il runtime.
    • Se l'SDK per la chiamata è in esecuzione nell'app, questo non funziona in modo diverso dall'app stessa che chiama il secondo SDK all'interno di SDK Runtime.
    • Se l'SDK per le chiamate viene eseguito in SDK Runtime, questa proposta consiglia di esporre un metodo utilizzando il metodo IBinder descritto nella sezione da app a SDK che il codice nell'app ascolta, elabora e risponde con i callback forniti.
    • Gli SDK per gli annunci che non sono abilitati per il runtime potrebbero non essere in grado di registrarsi autonomamente, proponiamo la creazione di un mediator SDK che includa qualsiasi SDK di partner o di app come dipendenze dirette dell'app e che gestisca la registrazione. Questo SDK mediatore stabilisce la comunicazione tra SDK non abilitati per il runtime o altre dipendenze dell'app e il mediatore abilitato per il runtime che agisce come adattatore.

Il set di funzionalità per la comunicazione SDK-SDK è stato suddiviso nelle seguenti categorie:

  • Comunicazione SDK-SDK all'interno di SDK Runtime (disponibile nella versione più recente di Anteprima per sviluppatori)
  • Comunicazione SDK-SDK tra l'app e SDK Runtime (disponibile nell'ultima Anteprima per sviluppatori)
  • Come dovrebbero funzionare le viste e il rendering remoto per la mediazione (proposta in fase di sviluppo)

I seguenti casi d'uso sono presi in considerazione durante la progettazione delle primitive:

  1. Mediazione e offerte. Molti SDK pubblicitari offrono funzionalità di mediazione o di offerta in base alla quale l'SDK chiama diversi altri SDK per un'impressione dell'annuncio (mediazione) o per la raccolta di indicatori al fine di eseguire un'asta (asta). In genere l'SDK di coordinamento chiama altri SDK tramite un adattatore fornito dall'SDK di coordinamento. Date le primitive sopra riportate, l'SDK di coordinamento, RE o meno, dovrebbe essere in grado di accedere a tutti gli SDK RE e non RE per il normale funzionamento. Il rendering in questo contesto è un'area di indagine attiva.
  2. Presentazione delle funzionalità. Alcuni prodotti SDK sono costituiti da SDK più piccoli che, tramite un processo di rilevamento tra SDK, determinano l'insieme di funzionalità finale esposto allo sviluppatore di app. Le primitive di registrazione e individuazione dovrebbero abilitare in questo caso d'uso.
  3. Modelli di abbonamento al publisher. Alcuni SDK sono progettati per avere un publisher centrale di eventi a cui altri SDK o app possono sottoscrivere per le notifiche tramite callback. Le primitive riportate sopra dovrebbero supportare questo caso d'uso.

Da app ad app

La comunicazione app-app si verifica quando almeno uno dei due processi di comunicazione è un SDK abilitato per il runtime ed è un potenziale vettore per la condivisione di dati non rivelati. Di conseguenza, SDK Runtime non è in grado di stabilire un canale di comunicazione diretto con nessuna app diversa dall'applicazione client o con gli SDK in un altro runtime SDK creato per un'altra app. A tale scopo, puoi procedere nei seguenti modi:

  • L'SDK non può definire componenti come <service>, <contentprovider> o <activity> nel file manifest.
  • L'SDK non può pubblicare un ContentProvider o inviare un broadcast.
  • L'SDK può avviare un'attività appartenente a un'altra app, ma con limiti relativi a ciò che può essere inviato nell'intent. Ad esempio, non è possibile aggiungere extra o azioni personalizzate a questo intent.
  • L'SDK può essere avviato o associato solo a una lista consentita di servizi.
  • L'SDK è in grado di accedere solo a un sottoinsieme del sistema ContentProvider (come com.android.providers.settings.SettingsProvider), nei casi in cui i dati ottenuti non contengono identificatori e non possono essere utilizzati per creare un'impronta dell'utente. Questi controlli si applicano anche all'accesso a ContentProvider tramite ContentResolver.
  • L'SDK è in grado di accedere solo a un sottoinsieme di ricevitori di trasmissioni protetti (come android.intent.action.AIRPLANE_MODE).

Tag manifest

Una volta installato l'SDK, PackageManager analizza il manifest dell'SDK e non riesce a installare l'SDK se sono presenti tag manifest esclusi. Ad esempio, l'SDK non può definire componenti come <service>, <activity>, <provider> o <receiver> e non può dichiarare <permission> nel file manifest. I tag che non superano l'installazione non sono supportati in SDK Runtime. I tag che vengono installati correttamente, ma che vengono ignorati automaticamente, potrebbero essere supportati nelle versioni future di Android.

Questi controlli possono essere applicati anche da qualsiasi strumento in fase di creazione utilizzato dall'SDK per creare il bundle SDK e al momento del caricamento nell'Application Store.

Supporto per le attività

Gli SDK nell'ambiente SDK Runtime non possono aggiungere un tag attività al file manifest e non possono avviare le proprie attività utilizzando Context.startActivity. La piattaforma crea invece le attività per gli SDK quando richiesto e le condivide con gli SDK.

L'attività della piattaforma è di tipo android.app.Activity. L'attività della piattaforma inizia da una delle attività dell'app e fa parte dell'attività dell'app. L'FLAG_ACTIVITY_NEW_TASK non è supportato.

Affinché un SDK inizi un'attività, deve registrare un'istanza di tipo SdkSandboxActivityHandler che viene utilizzata per notificare la creazione di attività quando l'app chiama SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) per avviare l'attività.

Il flusso di richiesta di un'attività è mostrato nel grafico seguente.

Diagramma
Diagramma di sequenza che mostra il flusso per avviare un'attività.

Sviluppo

Un principio chiave di questa proposta è ridurre al minimo l'impatto sull'ecosistema degli sviluppatori per quanto possibile. Questa proposta offre agli sviluppatori un set completo di strumenti di sviluppo per scrivere, creare ed eseguire il debug di SDK e app per la creazione di applicazioni nuove. Per garantire l'integrità di questa proposta, sono state apportate alcune modifiche al modo in cui le app e gli SDK di RE sono configurati, creati e creati.

In creazione

Android Studio e gli strumenti correlati verranno aggiornati in modo che siano compatibili con SDK Runtime, in modo che gli sviluppatori abbiano configurato correttamente le app e gli SDK RE e che le chiamate legacy o non supportate vengano aggiornate alle alternative più recenti, se pertinente. Durante la fase di creazione, la nostra proposta richiede agli sviluppatori alcuni passaggi.

Sviluppatori di app

Le app devono specificare le dipendenze del certificato SDK e dell'SDK RE nel file manifest dell'app. Nella proposta la trattiamo come una fonte effettiva di informazioni da parte dello sviluppatore dell'applicazione. Ad esempio:

  • Nome:il nome del pacchetto dell'SDK o della libreria.
  • Versione principale: codice di versione principale dell'SDK.
  • Digest certificato: il digest del certificato della build dell'SDK. Per una determinata build, proponiamo agli sviluppatori di SDK di ottenere e registrare questo valore tramite lo store pertinente.

Questo vale solo per gli SDK distribuiti nello store, indipendentemente dal fatto che siano RE o meno. Le app che collegano in modo statico gli SDK userebbero i meccanismi di dipendenza attuali.

Dato il nostro obiettivo di avere un impatto minimo per gli sviluppatori, è importante che una volta specificato un livello API target che supporta SDK Runtime, gli sviluppatori di app dovranno avere una singola build solo se la build viene eseguita su dispositivi che supportano o meno SDK Runtime.

Sviluppatori di SDK

Nel design proposto, gli sviluppatori di SDK RE devono dichiarare esplicitamente un nuovo elemento che rappresenti l'entità SDK o libreria nel file manifest. Inoltre, dovrebbe essere fornito un insieme di valori simile a quello della dipendenza più una versione secondaria:

  • Nome:il nome del pacchetto dell'SDK o della libreria.
  • Versione principale: codice di versione principale dell'SDK.
  • Versione secondaria: codice versione secondaria dell'SDK.

Se gli sviluppatori di SDK RE hanno altri SDK RE come dipendenze in fase di build, è probabile che dovranno dichiararli in modo identico a come uno sviluppatore di app dichiarerebbe la stessa dipendenza. Gli SDK RE a seconda di SDK non RE li collegherebbero in modo statico. Ciò potrebbe introdurre problemi che verrebbero rilevati in fase di creazione o durante i test superati se gli SDK non RE richiedono una funzionalità non supportata dal runtime SDK o se deve essere eseguita nel processo dell'app.

Gli sviluppatori di SDK RE vorranno continuare a supportare i dispositivi Android 13 di livello base con risorse di sistema molto limitate, come Android 12 o versioni precedenti e, come menzionato nella sezione Stato del sistema del documento, per i dispositivi Android 13 di livello base. Stiamo studiando degli approcci per garantire che gli sviluppatori di SDK possano mantenere un unico code-base per supportare gli ambienti RE e non.

Builds

Sviluppatori di app

Ci aspettiamo che gli sviluppatori di app notino i piccoli cambiamenti nella fase di creazione. Per l'analisi tramite lint, la compilazione e le build devono essere presenti sulla macchina dipendenze dell'SDK, che siano distribuite localmente o distribuite nell'app store (RE o meno). Proponiamo che Android Studio astrae questi dettagli dallo sviluppatore di app con un utilizzo normale e li renda il più trasparente possibile.

Anche se prevediamo che una build DEBUG debba includere tutto il codice e i simboli presenti nella build DEBUG ai fini del debug, per le build RELEASE verranno rimossi o meno tutti gli SDK distribuiti nello store (RE o meno) dall'elemento finale.

Siamo all'inizio della nostra fase di progettazione e condivideremo altre informazioni man mano che si realizza.

Sviluppatori di SDK

Stiamo lavorando su un percorso per garantire che le versioni non RE e RE di un SDK possano essere integrate in un singolo artefatto per la distribuzione. In questo modo, gli sviluppatori di app non dovranno supportare build separate per le versioni RE e non RE di un SDK.

Proprio come per le app, tutti gli SDK di dipendenze distribuiti nell'app store dovrebbero essere presenti sulla macchina per il linting, la compilazione e le build. Ci aspettiamo che Android Studio possa semplificare questa operazione.

Test

Sviluppatori di app

Come descritto nella nostra proposta, gli sviluppatori di app potrebbero testare le proprie app sui dispositivi con Android 13 come farebbero normalmente. Dopo aver creato l'app, quest'ultima potrà essere installata su un emulatore o un dispositivo RE. Questo processo di installazione garantisce l'installazione degli SDK corretti nel runtime SDK per il dispositivo o l'emulatore, indipendentemente dal fatto che gli SDK siano stati estratti da un repository di SDK remoto o dalla cache dal sistema di compilazione.

Sviluppatori di SDK

Gli sviluppatori di SDK in genere usano app di test interne su dispositivi ed emulatori per testare il loro sviluppo. La nostra proposta non modifica questa situazione e la convalida in-app seguirebbe gli stessi passaggi descritti per gli sviluppatori di app qui sopra, con un unico artefatto di build sia per le app RE che per quelle non RE. Gli sviluppatori di SDK saranno in grado di analizzare il loro codice indipendentemente dal fatto che si trovi nel runtime dell'SDK o meno, anche se potrebbero esserci alcune limitazioni sugli strumenti di debug e profilazione avanzati. Questa è un'area di indagine attiva.

Distribuzione

La nostra proposta di progettazione per la separazione di un'app dai relativi SDK ha creato la possibilità di distribuire SDK nello store. È una possibilità generale, non unica per uno specifico store. I vantaggi sono evidenti:

  • Garantisci la qualità e la coerenza degli SDK.
  • Semplifica la pubblicazione per gli sviluppatori di SDK.
  • Accelera l'implementazione degli aggiornamenti della versione secondaria dell'SDK nelle app installate.

Per supportare la distribuzione dell'SDK, è probabile che uno store debba fornire la maggior parte delle seguenti funzionalità:

  • Un meccanismo che consente agli sviluppatori di SDK di caricare i loro SDK distribuibili nello store, aggiornarli, eseguirne il rollback ed eventualmente rimuoverli.
  • Un meccanismo per garantire l'integrità di un SDK e della sua provenienza, nonché di un'app e la sua provenienza, e di risolvere le relative dipendenze.
  • un meccanismo per eseguirne il deployment sui dispositivi in modo coerente affidabilità e prestazioni.

Limitazioni in evoluzione nel tempo

Prevediamo che le limitazioni affrontate dal codice nel runtime dell'SDK si evolveranno con le versioni successive di Android. Per garantire la compatibilità dell'applicazione, non modificheremo queste restrizioni con gli aggiornamenti dei moduli principali per un determinato livello di SDK. Il comportamento associato a un determinato targetSdkVersion viene conservato fino a quando il relativo supporto targetSdkVersion non viene deprecato tramite i criteri dello store e il targetSdkVersion ritiro potrebbe avvenire con una cadenza più rapida rispetto alle app. Le limitazioni potrebbero cambiare spesso tra le versioni dell'SDK Android, soprattutto nelle prime release.

Inoltre, stiamo creando un meccanismo canary per consentire ai tester esterni e interni di unirsi a un gruppo che riceve l'insieme di limitazioni proposto per la prossima versione di Android. Questo ci aiuterà a ricevere feedback e fiducia in merito alle modifiche proposte per l'insieme di limitazioni.

Domande frequenti

  1. Che cos'è un SDK relativo alla pubblicità?

    Un SDK relativo agli annunci è un SDK che facilita qualsiasi parte del targeting degli utenti con messaggi per scopi commerciali su app che non sono di proprietà dell'inserzionista. Sono inclusi, a titolo esemplificativo, SDK di analisi in cui è possibile creare gruppi di utenti per il targeting successivo, SDK per la pubblicazione di annunci, SDK anti-abuso e antifrode per gli annunci, SDK per il coinvolgimento e SDK di attribuzione.

  2. Qualsiasi SDK può essere eseguito in SDK Runtime?

    Sebbene l'obiettivo iniziale siano gli SDK correlati agli annunci, gli sviluppatori di SDK non correlati agli annunci che cercano un approccio incentrato sulla privacy e ritengono di poter operare alle condizioni sopra descritte possono condividere feedback sui propri SDK in esecuzione in SDK Runtime. Tuttavia, SDK Runtime non è progettato per essere compatibile con tutti i design di SDK. Al di là delle limitazioni documentate, è probabile che SDK Runtime non sia adatto per gli SDK che richiedono comunicazioni in tempo reale o a velocità effettiva elevata con l'app di hosting.

  3. Perché scegliere l'isolamento dei processi anziché all'interno del runtime basato su Java di un processo?

    Attualmente, il runtime basato su Java non facilita facilmente i limiti di sicurezza necessari per le garanzie sulla privacy desiderate per gli utenti di Android. Il tentativo di implementare qualcosa di simile richiederebbe probabilmente uno sforzo pluriennale, senza alcuna garanzia di successo. Pertanto, Privacy Sandbox utilizza i limiti dei processi di utilizzo, una tecnologia testata nel tempo e ben comprensibile.

  4. Lo spostamento degli SDK nel processo di SDK Runtime potrebbe comportare dimensioni di download o risparmi di spazio?

    L'integrazione di più app con SDK abilitati per il runtime della stessa versione può ridurre le dimensioni di download e lo spazio su disco.

  5. A quali tipi di eventi del ciclo di vita delle app, ad esempio quando l'app passa in background, gli SDK avranno accesso in SDK Runtime?

    Stiamo lavorando attivamente al supporto della progettazione per la notifica del runtime dell'SDK sugli eventi del ciclo di vita a livello di app della sua applicazione client (ad esempio app che passa in background, app che passa in primo piano). Il design e il codice di esempio verranno condivisi in un'imminente anteprima per gli sviluppatori.