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. È pratica comune che le app includano codice di terze parti, sotto forma di SDK, ad esempio SDK per gli annunci o SDK di 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, negli SDK Android vengono eseguiti all'interno del sandbox 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 consente un'integrazione flessibile di SDK e app, oltre a creare il potenziale raccolta e condivisione di dati utente non dichiarati. 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 13 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 chiedendo attivamente feedback dalla community pubblicitaria di app mobile su di questo design. Inoltre, siamo lieti di ricevere feedback dalla più ampia community di sviluppatori per per aiutarti a modellare le future iterazioni di SDK Runtime, compreso il supporto per e altri 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 separata di questo documento.
Ridurre il monitoraggio non divulgato dell'utilizzo delle app da parte di un utente da parte di SDK di terze parti limitando l'accesso agli identificatori univoci e permanenti da parte degli SDK.
Accelera in modo sicuro la distribuzione degli aggiornamenti dell'SDK nelle app riducendo il per gli sviluppatori di app e gli utenti finali. Scopri di più sul modello proposto modello di distribuzione SDK attendibile in un'altra sezione di questo documento.
Aiuta gli sviluppatori di app a tenere conto meglio delle prassi di accesso e condivisione dei dati della propria 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. Consulta le sezione relativa alle comunicazioni del presente documento. Gli SDK non RE rimarrebbero nel processo dell'app come avviene 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

Dopo il diagramma che mostra i processi suddivisi 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 affidabile 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 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. Le seguenti si verifica invece:

Gli sviluppatori di SDK possono caricare gli SDK sottoposti al controllo delle versioni negli app store, direttamente dalle app.
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 innovativo meccanismo di distribuzione consentirebbe agli sviluppatori di SDK di modifiche senza interruzioni (ossia nessuna modifica alle API o alla semantica) della propria Gli SDK vengono distribuiti 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 essere ancora aggiornate dagli sviluppatori di app, ma gli sviluppatori di SDK potrebbero rendere disponibili più rapidamente e in modo più uniforme le modifiche e le correzioni non che comportano interruzioni a un maggior numero di utenti, riducendo al minimo il supporto delle versioni.

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

Diagramma Prima — Prima dell'introduzione di SDK Runtime, gli sviluppatori inviano i propri SDK direttamente nelle app.

di Gemini Advanced.

Dopo il diagramma — Dopo l'introduzione di SDK Runtime, d, l'SDK gli sviluppatori utilizzeranno un'interfaccia utente di caricamento SDK per pubblicare i propri SDK in uno store. Lo store gestirà quindi la distribuzione delle app, insieme a qualsiasi SDK per i 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 sezioni seguenti propongono una serie di modifiche seguenti ampie categorie:

Accesso: autorizzazioni, memoria, spazio di archiviazione
Esecuzione: lingue, modifiche di 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 eseguire il rollback tra le versioni di Android, app e SDK

Questo documento include anche le Domande frequenti per rispondere ai quesiti più comuni.

Si tratta di una proposta di progettazione iniziale e sappiamo che potrebbe essere significativa cambiamento 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: consente di accedere alle informazioni sullo stato del telefono, 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à. L'accesso viene controllato anche l'accesso a questa autorizzazione.

Al momento stiamo valutando se e come autorizzare autorizzazioni, limitando l'impatto sugli utenti finali sia da un punto di vista dell'usabilità. Me richiedere feedback per i casi d'uso che potrebbero non essere soddisfatti da questa serie di autorizzazioni.

Memoria

SDK Runtime avrà il proprio spazio di memoria isolato in virtù di un 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 punta a bilanciare la necessità che gli SDK accedano allo spazio di archiviazione il normale funzionamento e ridurre al minimo il monitoraggio tra app e processi l'archiviazione permanente dei dati. 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 relativi SDK e viceversa.
La memoria esterna del dispositivo non sarà accessibile agli SDK.
In ogni SDK Runtime, entrambi gli spazi di archiviazione saranno accessibili a tutti gli SDK, 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 stessa (formati di codice, costrutti linguistici, API accessibili e dati di sistema) deve rafforzare i confini della privacy o perlomeno non introdurre opportunità per aggirarle. Allo stesso tempo, vogliamo mantenere l'accesso alla piattaforma avanzata e alla maggior parte delle funzionalità di runtime che SDK che al momento hanno. 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 il codice SDK abilitato per il runtime consistere esclusivamente in bytecode Dex, piuttosto che supportare l'accesso JNI.

Siamo consapevoli che esistono casi d'uso come l'utilizzo di pacchetti SQLite, che, dato l'uso del codice nativo, dovrà essere sostituito con un'alternativa come la versione SQLite integrata 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 cercare di preservare la maggior parte dei casi d'uso degli SDK riducendo al minimo l'elusione della privacy di protezione che stiamo cercando di far progredire, proponiamo le seguenti aggiornamenti dal contesto SELinux di un'app non di sistema per SDK Runtime:

Un insieme limitato di servizi di sistema sarebbe accessibile. (in fase di progettazione)
Gli SDK sarebbero in grado di caricare ed eseguire il codice solo nel loro APK.
Un insieme limitato di proprietà di sistema sarebbe accessibile. (in fase di progettazione attiva)

API

L'uso della riflessione e dell'invocazione di API all'interno del runtime dell'SDK è consentito. Tuttavia, un SDK non potrà utilizzare la riflessione o richiamare le API su un altro abilitato per il runtime. Condivideremo una proposta completa di API proibite in un aggiornamento futuro.

Inoltre, le recenti release delle piattaforme Android sono state soggette a limitazioni in modo sempre più limitato. 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. Tentativo di accesso alle API di SdkSandboxManager dalle app in corso... in background fa sì che venga Lanciare 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 chiusa dall'utente o dal sistema operativo. SDK Runtime terminava 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 13, quando un'app è in primo piano, SDK Runtime viene eseguito in ed è improbabile che venga terminato. Quando l'app passa in background, la priorità del processo di runtime dell'SDK si abbassa e diventa idonea per l'interruzione. La priorità del processo di runtime dell'SDK rimane bassa anche se l'app torna in primo piano. Di conseguenza, è molto che venga terminato sotto pressione di memoria rispetto dell'app.

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

Nel caso in cui SDK Runtime termini mentre l'app è attiva, ad esempio Ad esempio, se nell'SDK è presente un'eccezione non gestita, SDK Runtime inclusi tutti gli SDK caricati in precedenza e le visualizzazioni remote, andranno persi. 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 SDK Runtime termina mentre gli annunci vengono visualizzati, gli annunci potrebbero non funzionino come previsto. Ad esempio, le visualizzazioni potrebbero essere bloccate sullo schermo e non più interattivo. L'app può rimuovere la visualizzazione dell'annuncio se questo non influisce un'esperienza utente positiva.
- L'app può fare un altro tentativo di caricare gli SDK e richiedere gli annunci.
- Per Android 14, se SDK Runtime termina mentre vengono caricati gli SDK, Se lo sviluppatore di app non ha registrato il ciclo di vita indicato in precedenza di callback, l'app termina 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 nella e il processo di sviluppo.

Rendering multimediale

Esistono SDK che eseguono il rendering di contenuti come testo, immagini e video in un specifica dell'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 visualizzare i contenuti multimediali in modo privato per l'utente, nonché di impedire e rilevare le interazioni degli utenti non valide o fraudolente con i contenuti multimediali visualizzati.

Gli annunci nativi, ovvero quelli il cui rendering non viene eseguito dall'SDK ma dall'app, essere supportata 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 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 progettando dei modi per farlo. Molto probabilmente, però, alcuni dispositivi Android 13 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 condivisione anche se 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.

Da app a SDK

L'interfaccia tra l'app e l'SDK è il percorso di comunicazione più comune a un SDK e l'API di un SDK è in cui gran parte della differenziazione rivolta all'utente e innovazione. Cerchiamo di preservare la capacità degli SDK di innovare e distinguersi. Di conseguenza, la nostra proposta consente agli SDK di esporre le API app e garantire che le app possano trarre vantaggio da tutte queste innovazioni.

Data la struttura dei confini dei processi di SDK Runtime, proponiamo creare un livello di marshaling, accessibile all'interno dell'app, per effettuare le chiamate API e o callback oltre il confine tra l'app e l'SDK. Stiamo proponendo che l'interfaccia di questo livello di marshalling sarebbe stata definita dall'SDK per gli sviluppatori e generati da strumenti di creazione open source ufficiali che lo sviluppo di applicazioni.

Con questa proposta cerchiamo di rimuovere il lavoro di marshalling boilerplate dall'app e SDK, offrendo al contempo flessibilità agli sviluppatori e garantendo il codice SDK viene eseguito in SDK Runtime per raggiungere i nostri obiettivi di privacy. Dovremmo di questo percorso, il linguaggio e gli strumenti di definizione delle API devono progettato con il tuo input.

Il modello di interazione generale è il seguente:

L'app chiama l'SDK tramite l'interfaccia, passando i callback.
L'SDK soddisfa le richieste e risponde in modo asincrono utilizzando i callback.
Può essere generalizzato a qualsiasi modello publisher-iscritto, il che significa che un'app può abbonarsi agli 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 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 ad automatizzare il più possibile, riducendo al minimo l'impatto per gli sviluppatori di app e SDK. La il seguente diagramma mostra un approccio che stiamo prendendo in considerazione:

Diagramma di sequenza che mostra il processo da app a SDK le interazioni durante l'avvio dell'app e dell'SDK.

La piattaforma esporrebbe nuove API per consentire alle app di caricare dinamicamente gli SDK 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 dall'app all'SDK in un di livello inferiore, senza lo strato di marshalling.

L'app comunica con l'SDK in esecuzione nel processo SDK Runtime tramite la 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 deve 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 soluzione scelta, deve essere coerente tra l'SDK e app chiamante. I diagrammi utilizzano AIDL come esempio.
SdkSandboxManager riceve l'interfaccia IBinder e la restituisce all'app.

L'app riceve il IBinder e lo trasmette nell'interfaccia dell'SDK, chiamando la sua :

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 relativa al rendering dei contenuti multimediali di questo documento, documento, per fare in modo che un'app riesca a far sì che un SDK esegua il rendering di contenuti multimediali in una vista, potresti effettuare una chiamata a requestSurfacePackage() e recuperare SurfaceControlViewHost.SurfacePackage.

Il seguente snippet di codice fornisce un esempio pratico dell'API:
```
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 pratico 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 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 in modo da essere composto da SDK che lo compongono e può verificarsi quando Gli SDK di diverse parti devono collaborare per soddisfare una richiesta del app per chiamate.

Esistono due casi principali da considerare:

Quando entrambi gli SDK sono abilitati per il runtime. In questo caso, entrambi gli SDK sono in esecuzione SDK Runtime con tutte le sue protezioni. Gli SDK non sono in grado di comunicare che fanno con un'app. Di conseguenza, un'API in L'utente SdkSandboxController è stato aggiunto per abilitare il recupero SandboxedSdk oggetti per tutti i RE-SDK caricati. Ciò consente a un RE-SDK comunicare con altri SDK caricati in SDK Runtime.
Quando un solo 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 che chiama è in esecuzione in SDK Runtime, questa proposta consiglia di esporre un metodo utilizzando il IBinder descritto nella sezione app-to-SDK che il codice nell'app ascolta, elabora e risponde 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 eventuali 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 SDK-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)

Vengono presi in considerazione i seguenti casi d'uso poiché le primitive progettato:

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 l'esecuzione di un'asta (offerta). In genere, l'SDK di coordinamento chiama altri SDK tramite un adattatore fornito dall'SDK di coordinamento. Date le primitive descritte sopra, le risorse di coordinamento SDK, RE o devono poter accedere a tutti gli SDK RE e non RE per il normale funzionamento. Il rendering in questo contesto è un'area di indagine attiva.
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à definitivo esposto allo sviluppatore di app. Primitive di registrazione e scoperta per abilitare questo caso d'uso.
Modelli di abbonamento all'editore. Alcuni SDK sono progettati per avere un editore centralizzato di eventi a cui altri SDK o app possono iscriversi per ricevere notifiche tramite callback. Le primitive riportate sopra dovrebbero supportare questo utilizzo per verificare se è così.

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, SDK Runtime non è in grado di stabilire canale di comunicazione diretta con qualsiasi app diversa dall'applicazione client, oppure con SDK in un altro runtime dell'SDK creato per un'altra app. Questo è ottenuti 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 non definire componenti quali <service>, <activity>, <provider> o <receiver> e non può dichiarare <permission> nel file manifest. I tag per i quali l'installazione non va a buon fine non sono supportati in SDK Runtime. Tag corretti ma vengono ignorati automaticamente potrebbero essere supportati in Android futuri e versioni successive.

Questi controlli possono essere applicati anche con qualsiasi strumento per la fase di creazione utilizzato dall'SDK creare il bundle SDK e al momento del caricamento nell'archivio applicazioni.

Assistenza per le attività

Gli SDK nell'ambiente SDK Runtime non possono aggiungere un tag attività al file manifest e non potrà 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à sulla piattaforma inizia da una delle attività dell'app e fa parte delle sue attività. FLAG_ACTIVITY_NEW_TASK non supportato.

Affinché un SDK possa iniziare un'attività, deve registrare un'istanza di tipo SdkSandboxActivityHandler, utilizzato per la notifica della creazione di attività quando l'app chiama SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) a iniziare l'attività.

Il flusso per richiedere un'attività è mostrato nel grafico seguente.

Sviluppo

Un principio chiave di questa proposta è ridurre al minimo l'impatto per lo sviluppatore dell'ecosistema nella misura 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, è necessario alcune modifiche al modo in cui le app e gli SDK RE vengono configurati, creati e creati.

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, trattiamo questa come la fonte di verità dello sviluppatore dell'applicazione. Ad esempio:

Nome: nome del pacchetto dell'SDK o della libreria.
Versione principale:il codice di versione principale dell'SDK.
Digest del certificato: il digest del certificato della compilazione 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 nello store, indipendentemente dal fatto che RE o meno. Le app che collegano in modo statico gli SDK userebbero gli attuali meccanismi di dipendenza.

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 collegarli in modo statico. Ciò potrebbe introdurre problemi che verrebbero rilevati tempo di creazione o durante il superamento del test, se gli SDK non RE richiedono funzionalità, SDK Runtime non lo supporta o se deve essere eseguito 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 13 di livello base con risorse di sistema molto limitate. Stiamo lavorando ad alcuni approcci per garantire che l'SDK gli sviluppatori possono mantenere un'unica codebase per supportare gli ambienti RE e non RE.

Build

Sviluppatori di app

Ci aspettiamo che gli sviluppatori di app registrino variazioni minime il passaggio di build. 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. Proporremo che Android Studio astragga questi dettagli da parte dello sviluppatore dell'app con il normale utilizzo e garantire la trasparenza il più 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 rimuovere tutti gli SDK distribuiti tramite lo 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. Questo potrebbe evitare che gli sviluppatori di app debbano supportare build separate per RE e versioni non RE di un SDK.

Proprio come per le app, qualsiasi SDK per le dipendenze distribuito nello store dovrà esistenti sulla macchina per l'analisi tramite lint, la compilazione e le build e ci aspettiamo 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 proprie app sui dispositivi con Android 13 come di consueto. Dopo che hanno creato l'app, l'app potrebbe essere installata su un emulatore o un dispositivo 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

Gli sviluppatori di SDK in genere utilizzano app di test interne sui dispositivi e emulatori per testare il loro 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 singolo artefatto di compilazione sia per le app RE che per quelle non RE. SDK gli sviluppatori potranno esaminare il codice se si trova nell'SDK Runtime o meno, anche se potrebbero esserci alcune limitazioni relative a debug avanzato e strumenti di profilazione. Questo è un'area di indagine attiva.

Distribuzione

La nostra proposta di progettazione per la separazione di un'app dai suoi SDK ha creato possibilità di distribuzione di SDK negli app store. Si tratta di una possibilità generale, non esclusiva di un determinato store. I vantaggi sono evidenti:

Garantire la qualità e la coerenza degli SDK.
Pubblicazione semplificata per sviluppatori di SDK.
Accelera l'implementazione degli aggiornamenti delle versioni secondarie dell'SDK nelle app installate.

Per supportare la distribuzione dell'SDK, uno store dovrebbe probabilmente offrono 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 applicate dal codice nel runtime dell'SDK si evolveranno in un secondo momento tutte le versioni di Android. Per garantire la compatibilità delle applicazioni, non le modificheremo limitazioni con gli aggiornamenti dei moduli principali per un determinato livello di SDK. Comportamento associati a un determinato targetSdkVersion viene conservato fino al relativo supporto L'app targetSdkVersion è deprecata tramite i criteri dello store e Il ritiro di targetSdkVersion potrebbe avvenire con una frequenza maggiore rispetto a quella delle 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 l'accesso ai tester di unirsi a un gruppo che riceve l'insieme di limitazioni proposto per i prossimi di Android. Questo ci aiuterà a ricevere feedback e fiducia sulle modifiche proposte all'insieme di restrizioni.

Domande frequenti

Che cos'è un SDK correlato alla pubblicità?

Un SDK relativo agli annunci è quello che facilita qualsiasi parte del targeting di utenti con messaggi a fini commerciali, nelle app che non sono di proprietà 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 si concentri sugli SDK relativi agli annunci, gli sviluppatori di non correlati agli annunci che cercano un atteggiamento a favore della privacy e ritengono di poter operare nel rispetto delle le condizioni descritte sopra possono condividere feedback sui loro SDK in esecuzione in SDK Runtime. Tuttavia, il runtime SDK non è progettato per essere compatibile con tutti i design dell'SDK. Al di là delle limitazioni documentate, l'SDK Il runtime non è probabilmente adatto per gli SDK che richiedono una velocità effettiva elevata o in tempo reale le comunicazioni con l'app di hosting.
Perché scegliere l'isolamento dei processi invece che all'interno Runtime basato su Java?

Attualmente, il runtime basato su Java non facilita immediatamente la sicurezza limiti necessari per le garanzie della privacy desiderate per Android utenti. Il tentativo di implementare qualcosa di simile richiederebbe probabilmente impegno pluriennale, senza la garanzia di successo. Pertanto, la Privacy La sandbox utilizza i confini dei processi, un processo collaudato e tecnologia.
Il trasferimento degli SDK nel processo di runtime dell'SDK consentirebbe di risparmiare spazio o ridurre le dimensioni del download?

Se più app sono integrate con SDK abilitati per il runtime della stessa della versione precedente, si riducono le dimensioni di 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 al supporto della progettazione per la notifica del runtime dell'SDK a livello di app del ciclo di vita della sua applicazione client (ad es. app in background, di un'app in primo piano). La progettazione e il codice di esempio verranno condivisi in imminente anteprima per gli sviluppatori.

di Gemini Advanced.

Consigliati per te

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