Questa pagina è stata tradotta dall'API Cloud Translation.

Panoramica di SDK Runtime

La piattaforma Android utilizza il concetto di sandboxing delle app per mantenere confini di esecuzione e sicurezza solidi per il codice dell'app, oltre ai confini dei processi. È prassi comune per le app includere codice di terze parti, spesso sotto forma di SDK come SDK per gli annunci o SDK per l'analisi. Questo riutilizzo consente agli sviluppatori di app di concentrarsi sulla differenziazione delle loro app, sfruttando al contempo il lavoro di esperti in materia per scalare l'esecuzione oltre ciò che potrebbero fare facilmente da soli.

Come la maggior parte dei sistemi operativi, in Android gli SDK vengono eseguiti all'interno della sandbox dell'app host e 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 di integrare in modo flessibile SDK e app, crea anche la possibilità di raccogliere e condividere dati utente non divulgati. Inoltre, gli sviluppatori di app potrebbero non essere pienamente consapevoli dell'entità 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 14 abbiamo aggiunto una nuova funzionalità della piattaforma che consente agli SDK di terze parti di essere eseguiti 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 il feedback della community pubblicitaria per app mobile su questo design. Accogliamo inoltre con favore il feedback della community di sviluppatori più ampia per contribuire a definire le future versioni dell'SDK Runtime, incluso il supporto di ulteriori casi d'uso.

Obiettivi

Questa proposta mira a raggiungere i seguenti obiettivi:

Riduci l'accesso e la condivisione non divulgati dei dati dell'app di un utente da parte di SDK di terze parti tramite l'isolamento dei processi e il controllo dell'accesso alle API e ai dati ben definito. Scopri di più sull'isolamento dei processi in una sezione distinta di questo documento.
Riduci il monitoraggio non divulgato dell'utilizzo dell'app da parte di SDK di terze parti impedendo agli SDK di accedere a identificatori univoci e permanenti.
Accelera in modo sicuro la distribuzione degli aggiornamenti dell'SDK alle app riducendo il carico sugli sviluppatori di app e sugli utenti finali. Scopri di più sul modello di distribuzione dell'SDK attendibile proposto in un'altra sezione di questo documento.
Aiutare gli sviluppatori di app a tenere meglio conto delle prassi di accesso e condivisione dei dati della loro app.
Aiuta gli sviluppatori di SDK a impedire la manomissione da parte di altri SDK tramite la limitazione di alcuni costrutti di linguaggio non sicuri, come il codice JNI.
Aiutano gli SDK per gli annunci a rilevare e prevenire il traffico non valido e la frode pubblicitaria tramite il controllo completo delle visualizzazioni remote che mostrano i contenuti multimediali.
Riduci al minimo l'impatto ingiustificato sugli sviluppatori di app e SDK.

Gli SDK vengono eseguiti in un processo isolato

L'SDK Runtime proposto consente agli SDK compatibili, indicati nel resto di questo documento come SDK abilitati per il runtime (RE), di operare in un processo distinto 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 rimarrebbero nel processo dell'app come accade attualmente. I seguenti diagrammi illustrano queste modifiche:

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

Diagramma successivo che mostra le procedure suddivise tra processo dell'app e processo di runtime dell'SDK — Dopo essere stato aggiunto a SDK Runtime, il codice di chiamata dell'SDK nel processo in primo piano dell'app comunica con le interfacce SDK. Queste interfacce attraversano quindi un confine di processo nel processo SDK Runtime per chiamare gli SDK stessi.

Nuovo modello di distribuzione attendibile per gli SDK

Questa proposta di separazione dell'SDK dall'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 attendibile, per garantire che gli SDK corretti siano installati nel runtime dell'SDK di un'app. In questo modo, gli utenti e gli sviluppatori di app sono protetti dal caricamento di SDK non validi, mentre gli store possono ridurre notevolmente il carico della distribuzione degli SDK da parte degli sviluppatori di app.

Gli SDK non dovranno più essere collegati in modo statico e pacchettizzati insieme alle app prima di essere caricati su un app store per la distribuzione. Si verificherà invece il seguente procedura:

Gli sviluppatori di SDK potrebbero caricare i propri SDK con versione negli store, separatamente dalle app stesse.
Gli sviluppatori di app potrebbero specificare le dipendenze dell'SDK in base alla versione, compilare e caricare una release dell'app che non includa le dipendenze dell'SDK effettive.
Quando un utente scarica questa app, la procedura di installazione potrebbe utilizzare le dipendenze SDK specificate dell'app per scaricarle dall'app store.

Questo nuovo meccanismo di distribuzione consentirebbe agli sviluppatori di SDK di apportare modifiche non invasive (ovvero nessuna modifica alle API o alla loro semantica) ai propri SDK e di distribuirli sui dispositivi senza il coinvolgimento degli sviluppatori di app. Queste modifiche non invasive all'SDK potrebbero essere implementate o annullate senza dover necessariamente attendere che gli sviluppatori di app ricostruiscano le loro app con i nuovi SDK o che gli utenti finali aggiornino le loro app. Le modifiche che comportano interruzioni dovrebbero ancora essere aggiornate dagli sviluppatori di app, ma gli sviluppatori di SDK potrebbero implementare le proprie modifiche e correzioni non che comportano interruzioni più rapidamente e in modo più uniforme per più persone, riducendo al minimo il supporto delle versioni.

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

Prima del diagramma — Prima dell'introduzione di SDK Runtime, gli sviluppatori inviavano i propri SDK direttamente alle app.

Dopo il diagramma — Dopo l'introduzione di SDK Runtime, gli sviluppatori di SDK useranno un'interfaccia utente di caricamento dell'SDK per pubblicare i propri SDK in un app store. L'app store gestirà quindi la distribuzione delle app, insieme a eventuali dipendenze dall'SDK, sui dispositivi degli utenti finali.

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

Questa è una proposta iniziale per una tecnologia di distribuzione e runtime SDK flessibile. Le seguenti sezioni propongono una serie di modifiche nelle seguenti categorie generali:

Accesso: autorizzazioni, memoria, spazio di archiviazione
Esecuzione: lingue, modifiche al runtime, ciclo di vita, rendering dei contenuti multimediali
Comunicazioni: da app a SDK e da SDK a SDK
Sviluppo: come creare, eseguire il debug e testare questo modello
Distribuzione: come distribuire, aggiornare e eseguire il rollback tra le versioni di Android, app e SDK

Questo documento include anche una sezione Domande frequenti per rispondere alle domande più comuni.

Si tratta di una proposta di design iniziale e siamo consapevoli che potrebbe rappresentare un cambiamento significativo per alcuni membri dell'ecosistema. Per questo motivo, stiamo cercando attivamente il tuo feedback e ti chiediamo di inviarlo tramite il tracker dei problemi.

Accesso

La gestione della privacy di un sistema implica la gestione del modo in cui entità diverse possono accedere a risorse diverse. Per soddisfare la nostra proposta di valore per la privacy, proponiamo di aggiornare il modello di accesso ad app, SDK e dati utente in modo che segua il principio del privilegio minimo per impedire l'accesso non dichiarato a dati potenzialmente sensibili.

Autorizzazioni SDK

In quanto processo separato, SDK Runtime avrà un proprio insieme ben definito di autorizzazioni, anziché ereditare quelle concesse dall'utente all'app. In base a ricerche preliminari sulle autorizzazioni utilizzate dagli SDK correlati agli annunci, proponiamo che le seguenti autorizzazioni siano accessibili agli SDK in SDK Runtime per impostazione predefinita:

INTERNET: accesso a internet per poter comunicare con un servizio web.
ACCESS_NETWORK_STATE: accedi alle informazioni sulle emittenti.
READ_BASIC_PHONE_STATE: accedi alle informazioni sullo stato dello smartphone, ad esempio il tipo di rete mobile.
Autorizzazioni per accedere alle API incentrate sulla tutela della privacy, che forniscono funzionalità pubblicitarie di base senza dover accedere a identificatori tra app.
AD_ID: Possibilità di richiedere l'ID pubblicità. Questo sarà anche limitato dall'accesso dell'app a questa autorizzazione.

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

Memoria

Il runtime dell'SDK avrebbe un proprio spazio di memoria isolato in virtù del proprio processo. Per impostazione predefinita, questa struttura negherebbe all'SDK l'accesso allo spazio di memoria dell'app e, analogamente, l'applicazione non potrebbe accedere allo spazio di memoria dell'SDK. Proponiamo di mantenere questo comportamento predefinito per mantenersi in linea con il principio del privilegio minimo.

Archiviazione

Questa proposta intende bilanciare la necessità per gli SDK di accedere allo spazio di archiviazione per il loro normale funzionamento e ridurre al minimo il monitoraggio tra app e processi utilizzando lo spazio di archiviazione permanente. Proponiamo il seguente aggiornamento al modo in cui viene eseguito l'accesso allo spazio di archiviazione oggi:

Un'app non potrà accedere direttamente allo spazio di archiviazione dei suoi SDK e viceversa.
La memoria esterna del dispositivo non sarà accessibile agli SDK.
All'interno di ogni SDK Runtime è presente sia spazio di archiviazione accessibile a tutti gli SDK sia spazio di archiviazione privato per un determinato SDK.

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

Esecuzione

Per garantire un sistema privato tra app, SDK e utenti, il contesto di esecuzione stesso (formati di codice, costrutti linguistici, API accessibili e dati di sistema) deve rafforzare questi confini della privacy o, almeno, non introdurre opportunità per aggirarli. Allo stesso tempo, vogliamo preservare l'accesso alla piattaforma completa e alla maggior parte delle funzionalità di runtime attualmente disponibili negli SDK. Qui proponiamo una serie di aggiornamenti all'ambiente di runtime per trovare questo equilibrio.

Codice

Il codice Android (app e SDK) viene interpretato principalmente da Android Runtime (ART), indipendentemente dal fatto che sia stato scritto in Kotlin o Java. La ricchezza dell'ART e le strutture linguistiche che offre, unite alla verificabilità che offre se confrontata con le alternative, in particolare il codice nativo, sembrano bilanciare in modo appropriato funzionalità e privacy. Proponiamo che il codice dell'SDK abilitato per il runtime sia costituito esclusivamente da bytecode Dex, anziché supportare l'accesso JNI.

Siamo consapevoli che esistono casi d'uso, come l'utilizzo di SQLite pacchettizzato personalizzato, che, dato l'uso di codice nativo, dovranno essere sostituiti con un'alternativa come la versione integrata di SQLite dell'SDK Android.

SELinux

Su Android, ogni processo (inclusi quelli in esecuzione come root) viene eseguito con un contesto SELinux specifico, che consente al kernel di gestire il controllo dell'accesso ai servizi, ai file, ai dispositivi e ad altri processi di sistema. Nel tentativo di preservare la maggior parte dei casi d'uso dell'SDK, riducendo al minimo la circonvenzione delle protezioni della privacy che stiamo cercando di implementare, stiamo proponendo i seguenti aggiornamenti dal contesto SELinux di un'app non di sistema per il runtime dell'SDK:

Sarà accessibile un insieme limitato di servizi di sistema. (in fase di progettazione)
Gli SDK potrebbero caricare ed eseguire il codice solo nel proprio APK.
Sarà accessibile un insieme limitato di proprietà di sistema. (in fase di progettazione)

API

L'uso della riflessione e dell'invocazione di API all'interno del runtime dell'SDK è consentito. Tuttavia, a un SDK non sarà consentito utilizzare la riflessione o richiamare API su un altro SDK con runtime abilitato. Condivideremo una proposta completa delle API vietate in un futuro aggiornamento.

Inoltre, le release recenti della piattaforma Android hanno limitato sempre di più l'accesso agli identificatori permanenti 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 da app in background comporta l'emissione di un messaggio di errore SecurityException.

Infine, gli SDK RE non possono utilizzare le API di notifica per inviare notifiche agli utenti in qualsiasi momento.

Lifecycle

Attualmente, gli SDK delle app seguono il ciclo di vita della relativa app host, il che significa che quando l'app entra o esce dal primo piano, si arresta o viene interrotta forzatamente dal sistema operativo a causa di una pressione sulla memoria, lo stesso accade per gli SDK dell'app. La nostra proposta di separare gli SDK di un'app in un processo diverso implica le seguenti modifiche al ciclo di vita:

L'app può essere interrotta dall'utente o dal sistema operativo. Il runtime SDK si chiuderebbe automaticamente subito dopo.
Il runtime dell'SDK può essere terminato dal sistema operativo a causa di una pressione sulla memoria o di un'eccezione non gestita in un SDK, ad esempio.

Per Android 14, quando un'app è in primo piano, il runtime dell'SDK viene eseguito con priorità elevata ed è improbabile che venga interrotto. Quando l'app passa in background, la priorità del processo di runtime dell'SDK si abbassa e diventa idonea all'interruzione. La priorità del processo di runtime dell'SDK rimane bassa anche se l'app torna in primo piano. Di conseguenza, è molto probabile che venga interrotto a causa della pressione sulla memoria rispetto all'app.

Per Android 14 e versioni successive, le priorità dei processi dell'app e dell'ambiente di runtime dell'SDK sono allineate. Le priorità di elaborazione per ActivityManager.RunningAppProcessInfo.importance per l'app e il runtime dell'SDK devono essere approssimativamente le stesse.

Se SDK Runtime viene interrotto mentre l'app è attiva, ad esempio se nell'SDK si verifica un'eccezione non gestita, lo stato di SDK Runtime, inclusi tutti gli SDK e le visualizzazioni remote caricati in precedenza, viene perso. Lo sviluppatore di app può gestire la terminazione di SDK Runtime utilizzando uno dei seguenti metodi:
- La proposta offre agli sviluppatori di app metodi di callback del ciclo di vita correlati per rilevare quando si è verificata l'interruzione dell'ambiente di runtime dell'SDK.
- Se il runtime dell'SDK viene interrotto durante la visualizzazione degli annunci, 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 non influisce sull'esperienza utente.
- L'app può fare un altro tentativo di caricare gli SDK e richiedere gli annunci.
- Per Android 14, se SDK Runtime si arresta dopo aver caricato gli SDK e se lo sviluppatore dell'app non ha registrato i metodi di callback del ciclo di vita sopra menzionati, l'app viene interrotta per impostazione predefinita. Solo i processi dell'app che hanno caricato gli SDK terminano e escono normalmente.
- Gli oggetti Binder restituiti dall'SDK per comunicare con esso (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 ritiro graduale senza l'SDK o avvisare 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 relativa alle comunicazioni di questo documento.

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

Casi particolari

I seguenti casi non sono supportati e potrebbero comportare un comportamento imprevisto:

Se più app condividono lo stesso UID, il runtime dell'SDK 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 eseguito nel processo principale.

Rendering multimediale

Esistono SDK che visualizzano contenuti come testo, immagini e video in una visualizzazione specificata dall'app. Per farlo, proponiamo un approccio di rendering remoto in cui l'SDK eseguirà il rendering dei contenuti multimediali dall'interno di SDK Runtime, ma utilizzerà l'API SurfaceControlViewHost per consentire il rendering dei contenuti multimediali in una visualizzazione specificata dall'app. In questo modo, l'SDK offre la possibilità di eseguire il rendering di questi contenuti multimediali in modo privato per l'utente, nonché di contribuire a prevenire e rilevare le interazioni degli utenti non valide o fraudolente con i contenuti multimediali visualizzati.

Gli annunci nativi, ovvero quelli non visualizzati dall'SDK, ma dall'app, verrebbero supportati dagli SDK in SDK Runtime. La raccolta degli indicatori e il recupero delle creatività avviene in modo coerente con gli annunci non nativi. Si tratta di un'area di indagine attiva.

Gli annunci video in-stream sono quelli pubblicati in-stream con un video, mostrati in un player all'interno di un'app. Poiché il video viene riprodotto in un player nell'app anziché in un player o in una visualizzazione nell'SDK, il modello di rendering è diverso da quello di 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 del runtime dell'SDK sullo stato di salute del sistema sui dispositivi degli utenti finali e stiamo studiando dei modi per farlo. Molto probabilmente, però, alcuni dispositivi Android 14 entry-level con risorse di sistema molto limitate, come Android (versione Go), non supporteranno il runtime dell'SDK a causa dell'impatto sullo stato di salute del sistema. A breve condivideremo i requisiti minimi necessari per utilizzare correttamente il runtime dell'SDK.

Comunicazioni

Poiché al momento le app e gli SDK vengono eseguiti nello stesso processo, la comunicazione tra loro è libera e non mediata. Inoltre, Android consente la comunicazione tra app anche se la comunicazione inizia e termina con gli SDK. Questo modello di comunicazione senza restrizioni consente vari casi d'uso, ma allo stesso tempo introduce la possibilità di condividere dati non divulgati tra app e tra SDK all'interno e tra le app. Proponiamo i seguenti aggiornamenti a questo modello di comunicazione per trovare un equilibrio tra il valore di questa comunicazione e la realizzazione dei nostri obiettivi dichiarati.

App-to-SDK

L'interfaccia tra l'app e l'SDK è il percorso di comunicazione più comune per un SDK e l'API di un SDK è dove risiede gran parte della differenziazione e dell'innovazione rivolta agli utenti. Cerchiamo di preservare la capacità degli SDK di innovare e distinguersi. 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 del confine del processo del runtime dell'SDK, proponiamo di creare un livello di marshalling, accessibile all'interno dell'app, per trasportare le chiamate API e le risposte o i callback attraverso questo confine tra l'app e l'SDK. Proponiamo di definire l'interfaccia di questo livello di marshalling dagli sviluppatori SDK e di generarla dagli strumenti di compilazione open source ufficiali che svilupperemo.

Con questa proposta, cerchiamo di rimuovere il lavoro di marshalling boilerplate dagli sviluppatori di app e SDK, offrendo al contempo flessibilità agli sviluppatori di SDK e garantendo che il codice dell'SDK venga eseguito in SDK Runtime per realizzare i nostri obiettivi di privacy. Se dovessimo seguire questa strada, il linguaggio di definizione dell'API e gli strumenti dovranno essere progettati con il tuo contributo.

Il modello di interazione generale è il seguente:

L'app chiama l'SDK tramite l'interfaccia, passando i callback.
L'SDK soddisfa le richieste in modo asincrono e risponde utilizzando i callback.
Questo può essere generalizzato a qualsiasi modello publisher-subscriber, il che significa che un'app può registrarsi agli eventi nell'SDK con i callback e, quando si verificano questi eventi, i callback vengono attivati.

Una conseguenza della nuova struttura cross-process di questa proposta è che esistono due cicli di vita dei processi che devono essere gestiti: uno per l'app stessa e l'altro per il runtime dell'SDK. La nostra proposta mira a automatizzare il più possibile queste operazioni, riducendo al minimo l'impatto sugli sviluppatori di app e SDK. Il seguente diagramma mostra un approccio che stiamo valutando:

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

La piattaforma espone nuove API per consentire alle app di caricare dinamicamente gli SDK nel processo di runtime dell'SDK, di ricevere notifiche relative alle modifiche dello stato del processo e di interagire con gli SDK caricati nel runtime dell'SDK.

Il grafico nella figura precedente mostra la comunicazione dall'app all'SDK a un livello inferiore, senza il livello di marshaling.

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

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.

Il seguente snippet di codice fornisce un esempio di API illustrativo:
```
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
```
L'SDK riceve una notifica che lo informa del caricamento 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 fornisce diversi modi per fornire IBinder. Qualunque sia la tua scelta, deve essere coerente tra l'SDK e l'app chiamante. I diagrammi utilizzano AIDL come esempio.
SdkSandboxManager riceve l'interfaccia IBinder e la restituisce all'app.

L'app recupera il IBinder e lo trasmette all'interfaccia dell'SDK, chiamandone le funzioni:

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

L'app può anche eseguire il rendering dei contenuti multimediali dall'SDK seguendo questi passaggi:

Come spiegato nella sezione sul rendering dei contenuti multimediali di questo documento, affinché un'app possa ottenere un SDK per il rendering dei contenuti multimediali in una visualizzazione, l'app potrebbe effettuare una chiamata a requestSurfacePackage() e recuperare il valore SurfaceControlViewHost.SurfacePackage appropriato.

Il seguente snippet di codice fornisce un esempio di API illustrativo:
```
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
```
L'app potrebbe quindi incorporare il SurfacePackage restituito nel SurfaceView tramite l'API setChildSurfacePackage in SurfaceView.

Il seguente snippet di codice fornisce un esempio di API illustrativo:
```
SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
```

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

Da SDK a SDK

Spesso è necessario che due SDK nella stessa app comunichino. Ciò può accadere quando un determinato SDK è progettato per essere composto da SDK costituenti e può verificarsi quando due SDK di parti diverse devono collaborare per soddisfare una richiesta dell'app chiamante.

Esistono due casi principali da considerare:

Quando entrambi gli SDK sono abilitati per il runtime. In questo caso, entrambi gli SDK vengono eseguiti in SDK Runtime con tutte le relative protezioni. Gli SDK non sono in grado di comunicare come fanno oggi all'interno di un'app. Di conseguenza, è stata aggiunta un'API in SdkSandboxController per consentire il recupero degli oggetti SandboxedSdk per tutti gli SDK RE caricati. In questo modo, un RE-SDK può comunicare con altri SDK caricati nel runtime dell'SDK.
Quando solo un SDK è abilitato per il runtime.
- Se l'SDK chiamante è in esecuzione nell'app, il funzionamento non è diverso dall'app stessa che chiama il secondo SDK all'interno di SDK Runtime.
- Se l'SDK chiamante è in esecuzione all'interno di SDK Runtime, questa proposta consiglia di esporre un metodo che utilizzi IBinder descritto nella sezione relativa all'app-to-SDK, che il codice nell'app ascolta, elabora e risponde con i callback forniti.
- Gli SDK per gli annunci non abilitati per il runtime potrebbero non essere in grado di registrarsi autonomamente. Pertanto, proponiamo la creazione di un SDK mediatore che includa gli SDK di partner o app come dipendenze dirette dell'app e gestisca la registrazione. Questo SDK mediatore stabilisce la comunicazione tra gli SDK non abilitati per il runtime o altre dipendenze dell'app e il mediatore abilitato per il runtime che funge da adattatore.

L'insieme di funzionalità per la comunicazione tra SDK è stato suddiviso nelle seguenti categorie:

Comunicazione SDK-SDK all'interno dell'SDK Runtime (disponibile nell'ultima Developer Preview)
Comunicazione tra SDK e SDK tra un'app e l'ambiente di runtime dell'SDK (disponibile nell'ultima versione di Developer Preview)
Come dovrebbero funzionare le visualizzazioni e il rendering remoto per la mediazione (proposta in sviluppo)

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

Mediazione e asta. Molti SDK pubblicitari offrono una funzionalità di mediazione o di offerta in cui l'SDK chiama vari altri SDK per un'impressione dell'annuncio (mediazione) o per la raccolta di indicatori per eseguire un'asta (offerta). In genere, l'SDK di coordinamento chiama altri SDK tramite un adattatore fornito dall'SDK di coordinamento. Date le primitive sopra indicate, 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.
Rilevamento delle funzionalità. Alcuni prodotti SDK sono costituiti da SDK più piccoli che, tramite un processo di rilevamento inter-SDK, determinano il set di funzionalità definitivo esposto allo sviluppatore di app. È previsto che le primitive di registrazione e scoperta supportino questo caso d'uso.
Modelli di abbonamento per i publisher. Alcuni SDK sono progettati per avere un editore centralizzato di eventi a cui altri SDK o app possono iscriversi per ricevere notifiche tramite callback. Gli elementi primitivi riportati sopra dovrebbero supportare questo caso d'uso.

Da app ad app

La comunicazione tra app si verifica quando almeno uno dei due processi in comunicazione è un SDK abilitato in fase di runtime ed è un potenziale vettore per la condivisione di dati non divulgati. Di conseguenza, l'ambiente di runtime dell'SDK non è in grado di stabilire un canale di comunicazione diretto con qualsiasi app diversa dall'applicazione client o con gli SDK in un altro ambiente di runtime dell'SDK creato per un'altra app. Questo viene ottenuto 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 una trasmissione.
L'SDK può avviare un'attività appartenente a un'altra app, ma con limitazioni su 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 (ad esempio com.android.providers.settings.SettingsProvider), in cui i dati ottenuti non dispongono di 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 trasmissione protetti (ad esempio android.intent.action.AIRPLANE_MODE).

Tag manifest

Quando l'SDK è installato, PackageManager analizza il manifest dell'SDK e non riesce a installarlo se sono presenti tag manifest vietati. Ad esempio, l'SDK potrebbe non definire componenti come <service>, <activity>, <provider> o <receiver> e non dichiarare un <permission> nel file manifest. I tag per i quali non è andata a buon fine l'installazione non sono supportati in SDK Runtime. I tag che non causano errori di installazione, ma vengono ignorati silenziosamente, potrebbero essere supportati nelle future versioni di Android.

Questi controlli potrebbero essere applicati anche da qualsiasi strumento di compilazione utilizzato dall'SDK per creare il bundle SDK e al momento del caricamento nell'app store.

Assistenza 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. FLAG_ACTIVITY_NEW_TASK non è supportato.

Affinché un SDK avvii un'attività, deve registrare un'istanza di tipo SdkSandboxActivityHandler che viene utilizzata per inviare una notifica relativa alla creazione dell'attività quando l'app chiama SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) per avviarla.

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

Sviluppo

Un principio chiave di questa proposta è ridurre al minimo l'impatto sull'ecosistema degli sviluppatori, se possibile. Questa proposta offre agli sviluppatori un insieme completo di strumenti di sviluppo per scrivere, compilare e eseguire il debug di app e SDK RE. Per garantire l'integrità di questa proposta, sono state apportate alcune modifiche alla configurazione, alla creazione e alla compilazione di app e SDK RE.

In creazione

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

Sviluppatori di app

Le app devono specificare le dipendenze dell'SDK RE e del certificato SDK nel file manifest dell'app. Nella nostra proposta, lo trattiamo come la fonte di verità dello sviluppatore dell'applicazione. Ad esempio:

Nome: nome del pacchetto dell'SDK o della libreria.
Versione principale:codice della versione principale dell'SDK.
Digest del certificato:il digest del certificato della build dell'SDK. Per una determinata compilazione, consigliamo allo sviluppatore dell'SDK di ottenere e registrare questo valore tramite l'app store pertinente.

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

Dato il nostro obiettivo di impatto minimo per gli sviluppatori, è importante che, una volta specificato un livello API di destinazione che supporta il runtime dell'SDK, gli sviluppatori di app debbano avere sempre una sola build, indipendentemente dal fatto che la build venga eseguita su dispositivi che supportano o meno il runtime dell'SDK.

Sviluppatori di SDK

Nel nostro design proposto, gli sviluppatori di SDK RE devono dichiarare esplicitamente un nuovo elemento che rappresenti l'entità SDK o della libreria nel file manifest. Inoltre, è necessario fornire un insieme di valori simile alla dipendenza, oltre a una versione minore:

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

Se gli sviluppatori di SDK RE hanno altri SDK RE come dipendenze di compilazione, probabilmente dovranno dichiararli in modo identico a come farebbe uno sviluppatore di app per dichiarare la stessa dipendenza. Gli SDK RE che dipendono da SDK non RE li collegherebbero in modo statico. Ciò potrebbe comportare problemi che verrebbero rilevati al momento della compilazione o durante i passaggi di test se gli SDK non RE richiedono funzionalità non supportate dal runtime dell'SDK o se devono essere eseguiti nel processo dell'app.

Gli sviluppatori di SDK RE probabilmente vorranno continuare a supportare i dispositivi non RE, come Android 12 o versioni precedenti e, come indicato nella sezione Stato del sistema del documento, i dispositivi Android 14 di livello base con risorse di sistema molto limitate. Stiamo adottando approcci per garantire che gli sviluppatori SDK possano mantenere un'unica base di codice per supportare gli ambienti RE e non RE.

Build

Sviluppatori di app

Prevediamo che gli sviluppatori di app non riscontreranno grandi cambiamenti nella fase di compilazione. Le dipendenze dell'SDK, distribuite localmente o tramite il store (RE o meno), devono essere presenti sulla macchina per il linting, la compilazione e le build. Proponiamo di fare in modo che Android Studio astragga questi dettagli dallo sviluppatore dell'app con un utilizzo normale e di rendere l'operazione il più trasparente possibile.

Sebbene ci aspettiamo che una build DEBUG debba includere tutto il codice e i simboli da includere nella build DEBUG per la possibilità di eseguire il debug, le build RELEASE eventualmente rimuoverebbero tutti gli SDK distribuiti tramite l'app store (RE o meno) dall'artifact finale.

Siamo ancora nella fase di progettazione e condivideremo ulteriori informazioni man mano che il progetto si concretizza.

Sviluppatori di SDK

Stiamo lavorando per garantire che le versioni non RE e RE di un SDK possano essere incorporate in un unico 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.

Come per le app, tutti gli SDK delle dipendenze distribuiti tramite l'app store devono essere presenti sul computer per il linting, la compilazione e le build e prevediamo che Android Studio debba semplificare questa operazione.

Test

Sviluppatori di app

Come descritto nella nostra proposta, gli sviluppatori di app potranno testare le loro app sui dispositivi con Android 14 come di consueto. Dopo aver creato la propria app, l'app potrà essere installata su un dispositivo o un emulatore RE. Questa procedura di installazione garantisce che gli SDK corretti vengano installati nel runtime SDK per il dispositivo o l'emulatore, indipendentemente dal fatto che siano stati estratti da un repository SDK remoto o dalla cache del sistema di compilazione.

Sviluppatori di SDK

In genere, gli sviluppatori di SDK utilizzano app di test interne su dispositivi ed emulatori per testare il proprio sviluppo. La nostra proposta non cambia questo aspetto e la convalida in-app seguirà gli stessi passaggi descritti sopra per gli sviluppatori di app, con un unico artefatto di compilazione sia per le app RE che per quelle non RE. Gli sviluppatori SDK potranno eseguire la procedura passo passo del codice, indipendentemente dal fatto che si trovi o meno nel runtime SDK, anche se potrebbero esserci alcune limitazioni per gli strumenti di debug e profiling avanzati. Si tratta di 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 gli SDK negli store. Si tratta di una possibilità generale, non esclusiva di un determinato store. I vantaggi sono chiari:

Assicurati la qualità e la coerenza degli SDK.
Semplificare la pubblicazione per gli sviluppatori di SDK.
Accelera l'implementazione degli aggiornamenti delle versioni secondarie dell'SDK nelle app installate.

Per supportare la distribuzione dell'SDK, un app store dovrebbe probabilmente fornire la maggior parte delle seguenti funzionalità:

Un meccanismo che consente agli sviluppatori di SDK di caricare gli SDK distribuibili tramite lo store, aggiornarli, eseguire il rollback e eventualmente rimuoverli.
Un meccanismo per garantire l'integrità di un SDK e della relativa provenienza, nonché di un'app e della relativa provenienza, e risolvere le relative dipendenze.
Un meccanismo per eseguirne il deployment sui dispositivi in modo coerente, affidabile e con un buon rendimento.

Restrizioni in evoluzione nel tempo

Prevediamo che le limitazioni affrontate dal codice nel runtime dell'SDK si evolvano con le versioni successive di Android. Per garantire la compatibilità delle applicazioni, non modificheremo queste limitazioni con gli aggiornamenti del modulo principale per un determinato livello SDK. Il comportamento associato a un determinato targetSdkVersion viene mantenuto fino a quando il supporto di questo targetSdkVersion non viene ritirato in base alle norme dello store e il ritiro del targetSdkVersion potrebbe avvenire a una cadenza più rapida rispetto alle app. Aspettati che le limitazioni cambino di frequente nelle varie versioni dell'SDK Android, soprattutto nelle prime release.

Inoltre, stiamo creando un meccanismo canary per consentire ai tester esterni e interni di partecipare a un gruppo che riceve l'insieme di limitazioni proposto per la prossima versione di Android. In questo modo potremo ricevere feedback e avere la certezza delle modifiche proposte all'insieme di limitazioni.

Domande frequenti

Che cos'è un SDK correlato alla pubblicità?

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

Sebbene l'attenzione iniziale sia rivolta agli SDK correlati agli annunci, gli sviluppatori di SDK non correlati agli annunci che cercano una posizione pro-privacy e ritengono di poter operare nelle condizioni descritte sopra possono condividere feedback sui propri SDK in esecuzione in SDK Runtime. Tuttavia, il runtime dell'SDK non è progettato per essere compatibile con tutti i design dell'SDK. Oltre alle limitazioni documentate, SDK Runtime è probabilmente inadatto per gli SDK che richiedono comunicazioni in tempo reale o con un elevato throughput con l'app host.
Perché scegliere l'isolamento dei processi anziché l'isolamento all'interno del runtime basato su Java di un processo?

Attualmente, il runtime basato su Java non facilita facilmente i confini di sicurezza necessari per le garanzie sulla privacy auspicate per gli utenti Android. Il tentativo di implementare qualcosa di simile richiederebbe probabilmente un impegno pluriennale, senza alcuna garanzia di successo. Pertanto, Privacy Sandbox utilizza i confini dei processi di utilizzo, una tecnologia collaudata e ben compresa.
Il trasferimento degli SDK nel processo di runtime dell'SDK consentirebbe di risparmiare spazio o ridurre le dimensioni dei download?

Se più app sono integrate con SDK abilitati per il runtime della stessa versione, è possibile ridurre le dimensioni del download e lo spazio su disco.
A quali tipi di eventi del ciclo di vita dell'app, ad esempio quando l'app passa in background, avranno accesso gli SDK in SDK Runtime?

Stiamo lavorando attivamente per supportare la progettazione di notifiche del runtime dell'SDK a livello di app per gli eventi di ciclo di vita della relativa applicazione client (ad es. app in background, app in primo piano). Il design e il codice di esempio verranno condivisi in una prossima anteprima per sviluppatori.

Consigliati per te

Nota: il testo del link viene visualizzato quando JavaScript è disattivato
Guida per gli sviluppatori di SDK Runtime