Quiz sugli aspetti fondamentali di SDK Runtime

L'obiettivo di SDK Runtime è fornire diversi vantaggi chiave all'ecosistema Android. Quali dei seguenti sono i vantaggi principali messi in evidenza per gli sviluppatori di app e SDK, nonché per gli utenti?

Scegli tutte le risposte che ritieni adeguate.

Privacy degli utenti e sicurezza delle applicazioni migliorate grazie all'isolamento del codice e delle risorse degli SDK di terze parti in un processo di runtime separato e con limitazioni.

Stabilità dell'app migliorata e responsabilità per gli arresti anomali più precisa grazie al contenimento delle operazioni dell'SDK all'interno di un processo dedicato, separato dall'applicazione host.

È stato concesso agli SDK di terze parti un accesso diretto maggiore all'insieme completo di autorizzazioni dell'app host per massimizzare la loro funzionalità.

Un modello di distribuzione degli SDK più flessibile, che consente di aggiornare gli SDK indipendentemente dalle release delle app tramite i canali di distribuzione delle app, con un potenziale miglioramento della velocità di correzione dei problemi critici.

Imporre a tutti gli SDK di terze parti di utilizzare un unico ambiente di runtime condiviso per tutte le app su un dispositivo per ottimizzare l'utilizzo delle risorse di sistema.

Quale affermazione descrive con precisione un SDK abilitato in fase di runtime (RE SDK)?

Viene eseguito nel processo dell'app e comunica direttamente con altri SDK in-app.

Si tratta principalmente di un livello di traduzione che aiuta le app a eseguire la migrazione all'utilizzo degli SDK in SDK Runtime.

Viene eseguito all'interno del processo SDK Runtime isolato.

Viene utilizzato solo per il debug delle funzionalità dell'SDK in Android Studio.

Considerando il nuovo paradigma di distribuzione per gli SDK abilitati in fase di runtime (RE SDK), quale affermazione descrive meglio il modo in cui gli SDK RE vengono resi disponibili per le app e installati sui dispositivi degli utenti?

Gli SDK RE vengono sempre compilati direttamente nell'APK dell'app host, come gli SDK tradizionali, ma vengono attivati solo quando è presente il runtime dell'SDK.

Gli SDK RE possono essere pubblicati negli store come entità distinte. L'app store gestisce quindi la loro installazione sul dispositivo e ogni app carica gli SDK RE richiesti nel proprio processo di runtime SDK privato.

Tutti gli SDK RE necessari sono preinstallati nel sistema operativo Android e le app dichiarano semplicemente quali intendono utilizzare.

Le app scaricano gli SDK RE direttamente dai server del fornitore di SDK ogni volta che sono necessari, garantendo così l'utilizzo della versione più recente senza il coinvolgimento dello store.

SDK Runtime cambia radicalmente l'integrazione degli SDK eseguendo gli SDK di terze parti in un processo separato. In che modo questo isolamento dei processi risolve principalmente una sfida chiave del modello SDK tradizionale fortemente accoppiato?

Garantisce che gli SDK RE consumino molta meno batteria trasferendo tutte le attività a un thread di sistema con priorità bassa.

Consente agli SDK RE di operare con privilegi di sistema elevati, bypassando il modello di autorizzazione dell'app per eseguire operazioni avanzate.

Crea confini chiari, limitando l'accesso diretto di un SDK ai dati e alle risorse interne dell'app host, riducendo così i rischi associati alla raccolta di dati non divulgati e migliorando la sicurezza complessiva.

Standardizza i componenti dell'interfaccia utente che tutti gli SDK RE devono utilizzare, garantendo un aspetto coerente in tutte le app che li utilizzano.

Qual è lo scopo principale degli strumenti di generazione di "shim" nel contesto del runtime dell'SDK?

Per pacchettizzare gli SDK abilitati per il runtime in bundle SDK Android (ASB).

Per applicare limitazioni delle autorizzazioni agli SDK abilitati per il runtime durante la compilazione.

Per astrarre la complessità della comunicazione interprocessuale (IPC) a basso livello tra l'app/Runtime Aware (SDK RA) e l'SDK RE.

Fornire componenti dell'interfaccia utente predefiniti per gli SDK RE per la visualizzazione degli annunci.

Quando crea un SDK RE, cosa deve implementare lo sviluppatore dell'SDK per definire il punto di contatto dell'SDK, che in genere estende una classe generata da uno shim?

Un'attività che avvia le funzionalità principali dell'SDK.

Una classe che estende "SandboxedSdkProviderCompat" (o un derivato generato da uno shim basato su "@PrivacySandboxService") e sostituisce il relativo metodo "create*".

Un BroadcastReceiver che ascolta le richieste di caricamento dell'SDK dall'app.

Un ContentProvider per condividere i dati di configurazione iniziale con l'app.

Quando esegui il debug di un SDK RE su un dispositivo o un emulatore in cui è attivo il runtime dell'SDK, a quale processo deve essere collegato il debugger per ispezionare il codice dell'SDK RE?

La procedura di applicazione principale del client.

Il processo "system_server".

Il processo "_sdk_sandbox".

La procedura di debug interna di Android Studio.

In base alle fasi di migrazione consigliate per un SDK esistente al runtime dell'SDK, qual è in genere il primo passaggio?

Richiedi immediatamente a tutte le app di utilizzare direttamente l'SDK abilitato per il runtime senza alcun livello di traduzione.

Crea un SDK abilitato per il runtime snello con tutta la logica di business esistente che rimane in un SDK in-app precedente.

Crea un SDK abilitato per il runtime durante il periodo di transizione insieme a un SDK consapevole del runtime per la migrazione incrementale e i test A/B.

Interrompere l'SDK esistente e offrire solo il nuovo SDK abilitato per il runtime fin dall'inizio.