Panoramica di SDK Runtime

La piattaforma Android utilizza il concetto di sandbox delle app per mantenere limiti di esecuzione e sicurezza robusti per il codice delle app, insieme ai limiti dei processi. È una pratica 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 della propria app sfruttando il lavoro degli esperti in materia per ampliare l'esecuzione oltre ciò che potrebbero fare facilmente da soli.

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 autorizzazioni dell'app host, nonché l'accesso alla memoria e allo spazio di archiviazione dell'app host. Sebbene questa architettura consenta a SDK e app di integrarsi in modo flessibile, crea anche il potenziale per la raccolta e la condivisione non dichiarate di dati utente. 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 attivamente raccogliendo feedback dalla community pubblicitaria delle app mobile su questo design. Accogliamo con favore anche i feedback della community di sviluppatori più ampia per contribuire a dare forma alle future iterazioni dell'SDK Runtime, incluso il supporto per casi d'uso aggiuntivi.

Obiettivi

Questa proposta mira a raggiungere i seguenti obiettivi:

• Ridurre l'accesso e la condivisione non divulgati dei dati delle app di un utente da parte di SDK di terze parti tramite l'isolamento dei processi e il controllo dell'accesso a API e dati ben definiti. Scopri di più sull'isolamento dei processi in una sezione separata di questo documento.
• Ridurre il monitoraggio non divulgato dell'utilizzo delle app da parte di SDK di terze parti limitando l'accesso agli identificatori unici e permanenti da parte degli SDK.
• Accelera in modo sicuro la distribuzione degli aggiornamenti dell'SDK alle app riducendo il carico di lavoro per gli sviluppatori di app e gli utenti finali. Scopri di più sul modello di distribuzione attendibile degli SDK proposto in un'altra sezione di questo documento.
• Aiutare gli sviluppatori di app a tenere meglio conto delle pratiche di accesso e condivisione dei dati della loro app.
• Aiuta gli sviluppatori di SDK a impedire la manomissione da parte di altri SDK limitando determinati costrutti di linguaggio non sicuri, come il codice JNI.
• Aiutare gli SDK per gli annunci a rilevare e prevenire il traffico non valido e le frodi pubblicitarie tramite il controllo completo delle visualizzazioni remote che mostrano i contenuti multimediali.
• Ridurre al minimo l'impatto indebito 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 separato per l'app. La piattaforma facilita la comunicazione bidirezionale tra il processo dell'app e il relativo SDK Runtime. Per i dettagli, consulta la sezione Comunicazioni di questo documento. Gli SDK non RE rimarrebbero nel processo dell'app come avviene attualmente. I seguenti diagrammi illustrano queste modifiche:

---

Nuovo modello di distribuzione attendibile per gli SDK

Questa separazione proposta dell'SDK dall'app motiva un altro concetto di separazione, quello per la distribuzione di SDK e app. Per questo è necessario un meccanismo di distribuzione e installazione attendibile, per garantire che gli SDK corretti vengano installati nell'SDK Runtime di un'app.

Questo meccanismo contribuisce a proteggere gli utenti e gli sviluppatori di app dal caricamento di SDK non validi, consentendo al contempo agli store di ridurre significativamente l'onere della distribuzione degli SDK da parte degli sviluppatori di app.

Gli SDK non devono più essere collegati staticamente e raggruppati con le loro app prima di essere caricati in uno store per la distribuzione.

La procedura prevede i seguenti passaggi:

1. Gli sviluppatori di SDK caricano le loro versioni degli SDK negli store, separatamente dalle app.
2. Gli sviluppatori di app specificano le dipendenze dell'SDK in base a versione e build e caricano una release dell'app che non include le dipendenze dell'SDK effettive.
3. Quando un utente scarica questa app, la procedura di installazione utilizza le dipendenze SDK specificate dell'app per scaricarle dallo store.

Questo nuovo meccanismo di distribuzione consente aggiornamenti indipendenti dell'SDK alle seguenti condizioni:

• Correzioni di bug compatibili con le versioni precedenti che non aggiungono nuove funzionalità, nuove API, modifiche alle API esistenti o modifiche del comportamento.
• Miglioramenti compatibili con le versioni precedenti alle funzionalità di rilevamento o valutazione delle frodi.

L'implementazione di queste funzionalità dipende dallo store.

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

---

Modifiche al modo in cui vengono creati, eseguiti e distribuiti SDK e app

Si tratta di una proposta iniziale per una tecnologia di runtime e distribuzione flessibile dell'SDK. Le seguenti sezioni propongono una serie di modifiche nelle seguenti categorie generali:

• Accesso: autorizzazioni, memoria, spazio di archiviazione
• Esecuzione: lingue, modifiche del 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 in questo modello
• Distribuzione: come distribuire, aggiornare e ripristinare le versioni di Android, delle app e degli 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, sollecitiamo attivamente il tuo feedback e ti chiediamo di farlo tramite lo strumento di monitoraggio dei problemi.

Accesso

La gestione della privacy di un sistema implica la gestione delle modalità di accesso di diverse parti 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

Come processo separato, l'SDK Runtime avrebbe un proprio insieme ben definito di autorizzazioni, anziché ereditare quelle che l'utente ha concesso 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: consente di accedere alle informazioni sullo stato dello smartphone, ad esempio il tipo di rete mobile.
• Autorizzazioni per accedere alle API che tutelano la privacy, che forniscono funzionalità pubblicitarie di base senza richiedere l'accesso agli identificatori cross-app.
• AD_ID: Possibilità di richiedere l'ID pubblicità. Anche l'accesso a questa autorizzazione sarebbe controllato dall'app.

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

Memoria

L'SDK Runtime avrebbe il proprio spazio di memoria isolato in virtù del proprio processo. Questa struttura per impostazione predefinita nega all'SDK l'accesso allo spazio di memoria dell'app e l'applicazione non può accedere allo spazio di memoria dell'SDK. Proponiamo di mantenere questo comportamento predefinito per rimanere 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 persistente. Proponiamo il seguente aggiornamento alla modalità di accesso allo spazio di archiviazione attuale:

• 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, ci sarebbero sia uno spazio di archiviazione accessibile a tutti gli SDK, sia uno spazio di archiviazione privato per un determinato SDK.

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

Esecuzione

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 confini della privacy o, quantomeno, non introdurre opportunità per aggirarli. Allo stesso tempo, vogliamo preservare l'accesso alla piattaforma avanzata 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 di ART e le costruzioni del linguaggio che offre, unita alla verificabilità che offre rispetto alle alternative, in particolare al codice nativo, sembra bilanciare in modo appropriato funzionalità e privacy. Proponiamo che il codice 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 personalizzato, che, dato l'utilizzo 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 eseguiti come root) viene eseguito con un contesto SELinux specifico, consentendo al kernel di gestire il controllo dell'accesso a servizi, file, dispositivi e altri processi di sistema. Nel tentativo di preservare la maggior parte dei casi d'uso dell'SDK riducendo al minimo l'elusione delle protezioni della privacy che stiamo cercando di promuovere, proponiamo i seguenti aggiornamenti dal contesto SELinux di un'app non di sistema per l'SDK Runtime:

• Sarebbe accessibile un insieme limitato di servizi di sistema. (in fase di progettazione attiva)
• 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 attiva)

API

L'uso della reflection e l'invocazione delle API all'interno del runtime dell'SDK sono consentiti. Tuttavia, un SDK non potrà utilizzare la reflection o richiamare API su un altro SDK abilitato per il runtime. In un aggiornamento futuro condivideremo una proposta completa di API vietate.

Inoltre, le recenti release della piattaforma Android hanno limitato sempre di più l'accesso agli identificatori permanenti per migliorare la privacy. Per l'SDK Runtime proponiamo di limitare ulteriormente l'accesso agli identificatori che potrebbero essere utilizzati per il monitoraggio cross-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 la generazione di un'eccezione SecurityException.

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

Lifecycle

Gli SDK delle app attualmente seguono il ciclo di vita della loro app host, il che significa che quando l'app entra o esce dal primo piano, si chiude o viene arrestata forzatamente dal sistema operativo a causa della pressione della memoria, anche gli SDK dell'app fanno lo stesso. 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 chiusa dall'utente o dal sistema operativo. L'SDK Runtime terminerebbe automaticamente subito dopo.

• L'SDK Runtime può essere terminato dal sistema operativo a causa di problemi di memoria o di un'eccezione non gestita in un SDK, ad esempio.

  Per Android 14, quando un'app è in primo piano, l'SDK Runtime viene eseguito con priorità elevata ed è improbabile che venga terminato. Quando l'app passa in background, la priorità del processo SDK Runtime diminuisce e diventa idoneo alla terminazione. La priorità del processo SDK Runtime rimane bassa anche se l'app torna in primo piano. Di conseguenza, è molto probabile che venga chiusa per pressione della memoria rispetto all'app.

  Per Android 14 e versioni successive, le priorità di processo dell'app e dell'SDK Runtime sono allineate. Le priorità di processo per ActivityManager.RunningAppProcessInfo.importance per l'app e l'SDK Runtime devono essere più o meno le stesse.

  Nel caso in cui SDK Runtime venga terminato mentre l'app è attiva, ad esempio se si verifica un'eccezione non gestita nell'SDK, 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 chiusura di SDK Runtime utilizzando uno dei seguenti metodi:

  • La proposta offre metodi di callback del ciclo di vita correlati agli sviluppatori di app per rilevare quando si è verificata la terminazione di SDK Runtime.
  • Se l'SDK Runtime termina durante la visualizzazione degli annunci, è possibile che gli annunci non funzionino 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 termina mentre ha SDK caricati e se lo sviluppatore dell'app non ha registrato i metodi di callback del ciclo di vita menzionati in precedenza, l'app termina per impostazione predefinita. Solo i processi dell'app che hanno caricato gli SDK terminano ed escono normalmente.
  • Gli oggetti Binder restituiti dall'SDK per comunicare con esso (ad esempio SandboxedSdk) generano un DeadObjectException se utilizzati dall'app.

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

  In caso di errori persistenti, lo sviluppatore dell'app deve pianificare un degrado controllato senza l'SDK o notificare all'utente se l'SDK è fondamentale per la funzionalità di base dell'app. Per ulteriori dettagli su questa interazione app-SDK, consulta la sezione Comunicazioni di questo documento.

Gli SDK non RE possono continuare a utilizzare le primitive standard del sistema operativo 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 generare un comportamento imprevisto:

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

Rendering multimediale

Esistono SDK che eseguono il rendering di contenuti come testo, immagini e video in una visualizzazione specificata dall'app. Per farlo, proponiamo un approccio di rendering remoto in cui l'SDK esegue il rendering dei contenuti multimediali all'interno di SDK Runtime, ma utilizza l'API SurfaceControlViewHost per consentire il rendering dei contenuti multimediali in una visualizzazione specificata dall'app. In questo modo, l'SDK può eseguire il rendering di questi contenuti multimediali in modo privato per l'utente, contribuendo a prevenire e rilevare interazioni utente non valide o fraudolente con i contenuti multimediali sottoposti a rendering.

Gli annunci nativi, quelli di cui non viene eseguito il rendering dall'SDK ma dall'app, sarebbero supportati dagli SDK in SDK Runtime. La raccolta dei segnali e il recupero delle creatività avverranno in modo coerente con gli annunci non nativi. Si tratta di un'area di indagine attiva.

Gli annunci video in-stream vengono riprodotti 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 altri formati di annuncio. Stiamo esplorando attivamente 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 l'SDK Runtime ha sui dispositivi degli utenti finali e stiamo progettando modi per farlo. Molto probabilmente, tuttavia, alcuni dispositivi Android 14 entry-level con risorse di sistema molto limitate, come Android (Go Edition), non supporteranno l'SDK Runtime a causa dell'impatto sull'integrità del sistema. A breve condivideremo i requisiti minimi necessari per utilizzare correttamente l'SDK Runtime.

Comunicazioni

Poiché app e SDK vengono attualmente 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 libera consente vari casi d'uso e allo stesso tempo introduce la possibilità di condivisione di 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.

Da app a SDK

L'interfaccia tra l'app e l'SDK è il percorso di comunicazione più comune con un SDK e l'API di un SDK è il luogo in cui risiedono gran parte della differenziazione e dell'innovazione rivolte agli utenti. Cerchiamo di preservare la capacità di innovazione e differenziazione degli SDK. Di conseguenza, la nostra proposta consente agli SDK di esporre le API alle app e garantire che queste possano trarre vantaggio da tutte queste innovazioni.

Data la struttura dei limiti di processo di SDK Runtime, proponiamo di creare un livello di marshalling, accessibile all'interno dell'app, per trasportare le chiamate API e le risposte o i callback oltre questo limite tra l'app e l'SDK. Proponiamo che l'interfaccia di questo livello di marshalling venga definita dagli sviluppatori di SDK e generata da strumenti di compilazione open source ufficiali che svilupperemo.

Con questa proposta cerchiamo di rimuovere il lavoro di marshalling standard dagli sviluppatori di app e SDK, fornendo al contempo flessibilità per gli sviluppatori di SDK e garantendo che il codice SDK venga eseguito in SDK Runtime per raggiungere i nostri obiettivi di privacy. Se dovessimo intraprendere questa strada, il linguaggio di definizione delle API e gli strumenti dovrebbero essere progettati con il tuo contributo.

Il modello di interazione generale sarebbe il seguente:

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

Una conseguenza della nuova struttura multiprocesso di questa proposta è che devono essere gestiti due cicli di vita del processo: uno per l'app stessa e l'altro per l'SDK Runtime. La nostra proposta mira ad automatizzare il più possibile questo processo, riducendo al minimo l'impatto su sviluppatori di app e SDK. Il seguente diagramma mostra un approccio che stiamo prendendo in considerazione:

La piattaforma esporrebbe nuove API per consentire alle app di caricare dinamicamente gli SDK nel processo SDK Runtime, ricevere notifiche sulle modifiche allo stato del processo e interagire con gli SDK caricati in SDK Runtime.

Il grafico nella figura precedente mostra la comunicazione da app a SDK a un livello inferiore, senza il livello di marshalling.

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

1. Prima che un'app possa interagire con un SDK, l'app richiederebbe 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 consentiti per il caricamento.

   Il seguente snippet di codice fornisce un esempio illustrativo dell'API:

   SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
       OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
   

2. L'SDK riceve una notifica che indica che è stato caricato e restituisce la sua interfaccia. Questa interfaccia è pensata per essere utilizzata dal processo dell'app. Per condividere l'interfaccia al di fuori del limite del processo, deve essere restituita come oggetto IBinder.

   La guida ai servizi vincolati fornisce diversi modi per fornire IBinder. In entrambi i casi, la modalità scelta deve essere coerente tra l'SDK e l'app chiamante. I diagrammi utilizzano AIDL come esempio.

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

4. L'app riceve IBinder e lo trasmette all'interfaccia SDK, chiamando le relative 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:

1. Come spiegato nella sezione 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 SurfaceControlViewHost.SurfacePackage appropriato.

   Il seguente snippet di codice fornisce un esempio illustrativo dell'API:

   SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
           Executor executor,
           OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
   

2. L'app potrebbe quindi incorporare il SurfacePackage restituito nel SurfaceView tramite l'API setChildSurfacePackage in SurfaceView.

   Il seguente snippet di codice fornisce un esempio illustrativo dell'API:

   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 chiamate dal riferimento API generato descritto sopra, in un livello "shim", per ridurre il carico sugli sviluppatori di app.

Da SDK a SDK

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

Ci sono due casi chiave 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 sue 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 di oggetti SandboxedSdk per tutti gli SDK RE caricati. In questo modo, un RE-SDK può comunicare con altri SDK caricati in SDK Runtime.
• Quando è abilitato per il runtime un solo SDK.
  • Se l'SDK per le chiamate viene eseguito nell'app, il funzionamento non è diverso da quello dell'app stessa che chiama il secondo SDK all'interno di SDK Runtime.
  • Se l'SDK chiamante viene eseguito all'interno di SDK Runtime, questa proposta consiglia di esporre un metodo che utilizza IBinder descritto nella sezione da app a SDK che il codice nell'app ascolta, elabora e a cui risponde con i callback forniti.
  • Gli SDK per gli annunci non abilitati per l'esecuzione potrebbero non essere in grado di registrarsi. Proponiamo la creazione di un SDK di mediazione che includa tutti 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.

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

• Comunicazione tra SDK all'interno di SDK Runtime (disponibile nell'ultima anteprima per gli sviluppatori)
• Comunicazione tra SDK e SDK tra un'app e SDK Runtime (disponibile nell'ultima anteprima per gli sviluppatori)
• Come dovrebbero funzionare le visualizzazioni e il rendering remoto per la mediazione (proposta in sviluppo)

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

1. Mediazione e asta. Molti SDK pubblicitari offrono una funzionalità di mediazione o offerta in cui l'SDK chiama vari altri SDK per un'impressione 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.
2. Scoperta delle funzionalità. Alcuni prodotti SDK sono costituiti da SDK più piccoli che, tramite un processo di rilevamento inter-SDK, determinano il set di funzionalità finale esposto allo sviluppatore di app. Si prevede che i primitivi di registrazione e scoperta consentano questo caso d'uso.
3. Modelli di abbonamento dell'editore. Alcuni SDK sono progettati per avere un publisher centrale di eventi a cui altri SDK o app possono iscriversi per ricevere notifiche tramite callback. I primitivi sopra dovrebbero supportare questo caso d'uso.

Da app ad app

La comunicazione tra app si verifica quando almeno uno dei due processi che comunicano è un SDK abilitato per il runtime ed è un potenziale vettore per la condivisione di dati non divulgati. Di conseguenza, SDK Runtime non è in grado di stabilire un canale di comunicazione diretto con qualsiasi app diversa dall'applicazione client o con gli SDK in un altro SDK Runtime creato per un'altra app. Questo risultato viene ottenuto nei seguenti modi:

• L'SDK non può definire componenti come <service>, <contentprovider> o <activity> nel suo 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 limiti su ciò che può essere inviato nell'intent. Ad esempio, non è possibile aggiungere extra o azioni personalizzate a questo intent.
• L'SDK può avviare o collegarsi solo a un elenco consentito di servizi.
• L'SDK è in grado di accedere solo a un sottoinsieme del sistema ContentProvider (ad esempio com.android.providers.settings.SettingsProvider), dove i dati ottenuti non hanno 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 potrebbe non dichiarare un <permission> nel manifest. I tag la cui installazione non è riuscita non sono supportati in SDK Runtime. I tag che non causano errori di installazione, ma vengono ignorati automaticamente, potrebbero essere supportati nelle versioni future 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 nello store.

Supporto per l'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 vengono richieste 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 avviare l'attività.

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

Sviluppo

Un principio fondamentale di questa proposta è ridurre al minimo l'impatto sull'ecosistema degli sviluppatori, per quanto possibile. Questa proposta offre agli sviluppatori un insieme completo di strumenti di sviluppo per scrivere, creare ed 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 per supportare SDK Runtime, contribuendo a garantire che gli sviluppatori abbiano configurato correttamente le proprie app e i propri SDK e assicurando che le chiamate legacy o non supportate vengano aggiornate alle alternative più recenti, ove pertinente. Durante la fase di creazione, ci sono alcuni passaggi che la nostra proposta richiederebbe agli sviluppatori.

Sviluppatori di app

Le app devono specificare le dipendenze dell'SDK RE e del certificato SDK nel file manifest dell'app. Nella nostra proposta, questo viene trattato come fonte di verità dello sviluppatore dell'applicazione per tutta la durata della proposta. 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 build, proponiamo allo sviluppatore dell'SDK di ottenere e registrare questo valore tramite lo store pertinente.

Ciò vale solo per gli SDK distribuiti dallo store, indipendentemente dal fatto che siano RE o meno. Le app che collegano staticamente gli SDK utilizzerebbero i meccanismi di dipendenza attuali.

Considerando il nostro obiettivo di ridurre al minimo l'impatto sugli sviluppatori, è importante che, una volta specificato un livello API di destinazione che supporta l'SDK Runtime, gli sviluppatori di app debbano avere una sola build, indipendentemente dal fatto che venga eseguita su dispositivi che supportano o meno l'SDK Runtime.

Sviluppatori di SDK

Nel nostro progetto proposto, gli sviluppatori di SDK RE devono dichiarare esplicitamente un nuovo elemento che rappresenti l'entità SDK o libreria nel manifest. Inoltre, è necessario fornire un insieme di valori simile a quello della dipendenza, più una versione secondaria:

• 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 RE SDK hanno altri RE SDK come dipendenze in fase di compilazione, dovranno probabilmente dichiararli in modo identico a quello in cui uno sviluppatore di app dichiarerebbe la stessa dipendenza. Gli SDK abilitati per il runtime che dipendono da SDK non abilitati per il runtime li collegherebbero staticamente. Ciò potrebbe introdurre problemi che verrebbero rilevati in fase di compilazione o durante i passaggi di test se gli SDK non RE richiedono funzionalità non supportate da SDK Runtime o se devono essere eseguiti nel processo dell'app.

Gli sviluppatori di RE SDK probabilmente vorranno continuare a supportare i dispositivi non abilitati a RE, come Android 12 o versioni precedenti e, come indicato nella sezione Integrità del sistema del documento, i dispositivi Android 14 di base con risorse di sistema molto limitate. Stiamo esaminando approcci per garantire che gli sviluppatori di 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 noteranno poche modifiche nel passaggio di build. Le dipendenze dell'SDK, distribuite localmente o tramite l'app store (RE o meno), devono esistere sulla macchina per il linting, la compilazione e le build. Proponiamo che Android Studio estragga questi dettagli dallo sviluppatore di app con l'utilizzo normale e li renda il più trasparenti possibile.

Sebbene ci aspettiamo che una build DEBUG debba includere tutto il codice e i simboli da includere nella build DEBUG per la debuggabilità, le build RELEASE potrebbero facoltativamente rimuovere tutti gli SDK distribuiti dallo store (RE o meno) dall' artefatto finale.

Siamo ancora nelle prime fasi della progettazione e condivideremo maggiori dettagli man mano che si concretizzano.

Sviluppatori di SDK

Stiamo lavorando a 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.

Come per le app, gli SDK delle dipendenze distribuiti dall'app store devono esistere sul computer per linting, compilazione e build e prevediamo che Android Studio dovrebbe facilitare questa operazione senza problemi.

Test

Sviluppatori di app

Come descritto nella nostra proposta, gli sviluppatori di app potranno testare le loro app su dispositivi con Android 14 come di consueto. Dopo aver creato l'app, questa potrà essere installata su un dispositivo RE o un emulatore. Questo processo di installazione garantisce che gli SDK corretti vengano installati in SDK Runtime per il dispositivo o l'emulatore, indipendentemente dal fatto che gli SDK siano stati recuperati da un repository SDK remoto o dalla cache del sistema di build.

Sviluppatori di SDK

Gli sviluppatori di SDK in genere utilizzano app di test interne su dispositivi ed emulatori per testare il proprio sviluppo. La nostra proposta non cambia questa situazione e la convalida in-app seguirà gli stessi passaggi descritti sopra per gli sviluppatori di app, con un singolo artefatto di build sia per le app RE che per quelle non RE. Gli sviluppatori di SDK potranno eseguire il debug del proprio codice indipendentemente dal fatto che si trovi o meno nell'SDK Runtime, anche se potrebbero esserci alcune limitazioni agli strumenti avanzati di debug e profilazione. Si tratta di un'area di indagine attiva.

Distribuzione

La separazione di un'app dai suoi SDK ha creato la possibilità di distribuire gli SDK negli store. Si tratta di una funzionalità della piattaforma, non specifica di alcun canale di distribuzione.

Questa opzione offre i seguenti vantaggi:

• Garantire la qualità e la coerenza degli SDK.
• Semplificare la pubblicazione per gli sviluppatori di SDK.
• Accelerare l'implementazione degli aggiornamenti delle patch critiche dell'SDK alle app installate.

Per supportare la distribuzione dell'SDK, un canale di distribuzione deve supportare le seguenti funzionalità:

• Gli sviluppatori di SDK possono pubblicare i propri SDK nello store o nella piattaforma ed eseguire operazioni di manutenzione.
• Garantisci l'integrità di SDK e app e risolvi le loro dipendenze.
• Esegui il deployment degli SDK sui dispositivi in modo coerente, affidabile e performante.

Evoluzione delle limitazioni nel tempo

Prevediamo che le limitazioni a cui è soggetto il codice nel runtime SDK si evolveranno con le versioni successive di Android. Per garantire la compatibilità delle applicazioni, non modificheremo queste limitazioni con gli aggiornamenti dei moduli mainline per un determinato livello SDK. Il comportamento associato a un determinato targetSdkVersion viene mantenuto fino a quando il supporto per quel targetSdkVersion non viene ritirato tramite le norme dello store e il ritiro di targetSdkVersion potrebbe avvenire a una velocità maggiore rispetto a quella delle app. Prevedi che le limitazioni cambieranno spesso nelle varie versioni dell'SDK Android, soprattutto nelle prime release.

Inoltre, stiamo creando un meccanismo canary per consentire a tester esterni e interni di entrare a far parte di un gruppo che riceve il set di limitazioni proposto per la prossima versione di Android. Questo ci aiuterà a ricevere feedback e a valutare la validità delle modifiche proposte all'insieme di limitazioni.

Domande frequenti

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

   Un SDK correlato agli annunci è un SDK che facilita qualsiasi parte del targeting degli utenti con messaggi per scopi commerciali, su app non 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 anti-frode per gli annunci, gli SDK di coinvolgimento e gli SDK di attribuzione.

2. 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 mirano a una posizione a favore della privacy e ritengono di poter operare alle condizioni sopra descritte possono condividere feedback sugli SDK in esecuzione in SDK Runtime. L'SDK Runtime non è progettato per essere compatibile con tutti i design degli SDK. Oltre alle limitazioni documentate, SDK Runtime è probabilmente inadatto agli SDK che richiedono comunicazioni in tempo reale o ad alta velocità con l'app di hosting.

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

   Al momento, il runtime basato su Java non facilita facilmente i confini di sicurezza necessari per le garanzie di privacy desiderate per gli utenti Android. Tentare di implementare qualcosa di simile richiederebbe probabilmente un impegno pluriennale, senza garanzia di successo. Pertanto, Privacy Sandbox utilizza i limiti di processo, una tecnologia collaudata e ben compresa.

4. Lo spostamento degli SDK nel processo SDK Runtime offre un risparmio di spazio o una riduzione delle dimensioni del download?

   Se più app sono integrate con SDK abilitati per il runtime della stessa versione, ciò può ridurre le dimensioni del download e lo spazio su disco.

5. 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 al supporto della progettazione per notificare all'SDK runtime gli eventi del ciclo di vita a livello di app della sua applicazione client (ad es. l'app passa in background, l'app passa in primo piano). Il design e il codice di esempio verranno condivisi in un'anteprima per sviluppatori in arrivo.

Consigliati per te

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