Alcune tecnologie Privacy Sandbox verranno ritirate gradualmente.

Consulta il nostro aggiornamento sui piani per le tecnologie Privacy Sandbox.

Stato delle funzionalità di Privacy Sandbox fornisce ulteriori informazioni sullo stato delle singole API e funzionalità della piattaforma.

Crea e utilizza un SDK abilitato per il runtime

Key concepts

Concetti fondamentali

Questa sezione descrive l'architettura di SDK Runtime, come vengono installati gli SDK abilitati per il runtime, la compatibilità con le versioni precedenti e come eseguire la migrazione degli SDK esistenti a SDK Runtime.

Glossario

SDK abilitato per il runtime (RE SDK): un SDK creato per essere eseguito nell'ambiente SDK Runtime e comunicare con l'app tramite la comunicazione interprocesso (IPC).
SDK runtime-aware (RA SDK): un SDK non abilitato per il runtime, collegato staticamente all'app, che può contenere il codice SDK esistente e il nuovo codice per chiamare l'SDK abilitato per il runtime.
- A volte viene anche chiamato collegamento statico o SDK statico.
Shim: una libreria Jetpack che aiuta ad astrarre la comunicazione tra processi o la comunicazione interprocesso (IPC) e a mantenere la stessa interfaccia app-SDK.

Architettura di SDK Runtime

SDK Runtime adotta un modello di tipo client-server.

La principale differenza è che il "client" (app) e il "server" (SDK con runtime abilitato) vengono eseguiti sullo stesso dispositivo e questa comunicazione avviene tra processi.

Per aiutarti ad affrontare queste sfide, abbiamo creato le seguenti librerie e strumenti Jetpack per semplificare l'integrazione di app e SDK all'interno di SDK Runtime:

Libreria shim:la libreria wrapper (o shim) aiuta ad astrarre la comunicazione tra processi o la comunicazione interprocesso (IPC). Inoltre, contribuisce a mantenere la stessa interfaccia app-SDK.
Libreria di compatibilità con le versioni precedenti: questa libreria gestisce la compatibilità con le versioni precedenti, assicurandosi che l'SDK sia compatibile indipendentemente dalla disponibilità o meno di SDK Runtime.
Libreria UI:forniamo anche librerie per gestire la presentazione remota, ad esempio il recupero della UI dall'SDK abilitato per l'esecuzione o il ridimensionamento e il riposizionamento delle visualizzazioni.

Panoramica dell'architettura di SDK Runtime — Diagramma che mostra un'app che interagisce con l'SDK abilitato per il runtime tramite diverse librerie.

Modifiche al flusso di installazione

Quando crei l'SDK abilitato per il runtime in Android Studio o in altri strumenti, crei un bundle SDK Android (ASB), un formato di pubblicazione per gli SDK abilitati per il runtime.

bundletool elabora l'ASB per produrre un APK per l'SDK abilitato per il runtime: questo APK separato contiene il codice dell'SDK, ma non il codice dell'app.

Il file manifest dell'app dichiara una dipendenza dal nome e dalla versione dell'SDK abilitato per il runtime e questa dipendenza viene risolta dall'app di installazione.

Una volta che l'APK dell'SDK viene recuperato dal programma di installazione, l'installazione inizia con l'installazione dell'APK dell'SDK. In caso di esito positivo, segue l'installazione dell'APK dell'app.

Il flusso è diverso se l'app è installata su Android 13 e versioni precedenti e su dispositivi che non supportano SDK Runtime. In questo scenario, lo store installa un singolo APK contenente sia l'SDK abilitato per il runtime sia il codice dell'app. Per saperne di più, leggi la sezione sulla distribuzione.

Ogni volta che un'app dipende da questo SDK in produzione, lo store crea l'APK SDK corretto da questo ASB e lo installa.

Compatibilità con le versioni precedenti

Poiché SDK Runtime è stato introdotto in Android 14, abbiamo dovuto supportare le versioni precedenti senza introdurre overhead per gli sviluppatori di SDK o app.

Per gestire la compatibilità con le versioni precedenti su Android 13 e versioni precedenti, abbiamo introdotto una libreria Jetpack in grado di eseguire senza problemi l'SDK abilitato per il runtime indipendentemente dal supporto del dispositivo per SDK Runtime.

Se segui questa guida, l'SDK abilitato per il runtime è compatibile con le versioni precedenti per impostazione predefinita e non devi eseguire altri passaggi.

Mettiamo in evidenza le azioni connesse alla compatibilità con le versioni precedenti nelle fasi pertinenti, ma in termini generali devi assicurarti di aver dichiarato le dipendenze corrette e di utilizzare le classi *Compat, se applicabile.

Migrazione degli SDK esistenti

Se hai un SDK esistente di cui vuoi eseguire la migrazione al runtime, non devi eseguire il refactoring dell'intero codebase in una sola volta. Puoi invece scegliere di eseguire la migrazione della logica dell'SDK esistente in modo incrementale nel nuovo SDK abilitato per il runtime.

Per eseguire la migrazione di un SDK esistente nell'SDK Runtime, ti consigliamo di seguire queste tre fasi:

Creazione di un SDK abilitato per il runtime del periodo di transizione insieme a un SDK spesso equivalente compatibile con il runtime. In questo modo, puoi eseguire la migrazione incrementale della logica di business dal tuo SDK esistente e disporre di una piattaforma di test per i test A/B.
Trasferimento di tutta la logica di business dell'SDK esistente a uno stato stazionario insieme a un SDK sottile e consapevole del runtime per semplificare la migrazione delle app
Supportare le app interessate con la migrazione completa per utilizzare direttamente l'SDK abilitato per il runtime senza un SDK thin compatibile con il runtime

Fase 1: periodo di transizione. SDK Thick runtime-aware

Puoi iniziare scegliendo di mantenere parte della logica di business nell'SDK runtime-aware. Questo tipo di SDK viene chiamato SDK spesso compatibile con il runtime o wrapper in-app.

Questo approccio ti consente di mantenere tutte o alcune delle funzionalità dell'SDK nella libreria statica dell'app, insieme a un SDK abilitato per il runtime appena creato.

In questo modo puoi eseguire la migrazione incrementale dei tuoi casi d'uso nell'SDK abilitato per il runtime e testare l'SDK abilitato per il runtime rispetto all'SDK esistente.

In questa fase, lo sviluppatore dell'app non deve modificare nulla nel modo in cui utilizza l'SDK, perché è la libreria statica dell'app (SDK runtime-aware) a svolgere il lavoro necessario per utilizzare l'SDK runtime-aware.

L'app chiama al suo interno un SDK statico e compatibile con il runtime che può contenere un livello di traduzione per chiamare l'SDK abilitato per il runtime, nonché altra logica di business.

Fase 2 - Stato stazionario: SDK leggero e consapevole del runtime

A differenza dell'SDK spesso compatibile con il runtime, un wrapper sottile o un SDK sottile compatibile con il runtime (SDK sottile RA), contiene solo codice di chiamata dell'SDK abilitato per il runtime e di traduzione dell'API nell'SDK della libreria collegata staticamente.

A questo punto, dovresti aver eseguito la migrazione di tutto il codice SDK dall'SDK della libreria statica dell'app all'SDK abilitato per l'esecuzione.

Gli sviluppatori di app non devono apportare modifiche rispetto alla fase 1 perché l'SDK thin runtime-aware in-app gestisce le chiamate all'SDK abilitato per il runtime all'interno di SDK Runtime.

L'app chiama un SDK statico al suo interno che contiene solo un livello di traduzione.

Fase 3: migrazione completa

In questa fase finale, hai eseguito la migrazione di tutte le funzionalità dell'SDK nell'SDK abilitato per il runtime e hai rimosso tutte le librerie statiche dall'app.

A questo punto, i client della tua app non devono più includere le tue librerie nelle loro build, ma solo elencare le dipendenze dell'SDK nel manifest e includere le chiamate SDK nel codice dell'app.

Le chiamate SDK vengono indirizzate dal sistema a SDK Runtime, dove l'SDK abilitato per il runtime viene caricato automaticamente.

Architettura della fase di migrazione completa, in cui il codice dell'annuncio dell'app richiama direttamente l'SDK abilitato per il runtime.

Introduzione

Passaggio 2: configura l'ambiente di sviluppo