Eseguire la migrazione di Connessione Salute da Android 13 (APK) ad Android 14 (framework)

Connessione Salute verrà inclusa con Android 14 come livello di archiviazione dati comune. dati sulla salute dei consumatori, protetti da autorizzazioni granulari e accessibili App di sistema Android (in questo documento viene chiamata "framework" .

Gli sviluppatori dovrebbero considerare l'APK Connessione Salute (Android 13) come un'alternativa di compatibilità per il modello del framework. Il modello del framework conserverà Il 100% di parità di funzionalità rispetto all'APK precedente.

Durante la transizione da Android 13 ad Android 14, è di vitale importanza che l'esperienza utente rimane il più fluida e intuitiva possibile.

Questo documento illustra il piano di migrazione e fornisce alcuni esempi di migrazione. scenari di deployment ed elenca le modifiche all'SDK Jetpack, che facilita l'accesso API Health Connect.

Piano di migrazione

1. Una volta rilasciato Android 14, Google passerà a fornire Connessione Salute come app di sistema Android.
2. Verrà poi eseguito il backfill dei dati dall'APK una volta raggiunta la parità di funzionalità.
3. Tutti i punti di ingresso avranno come target l'UI dell'app di sistema.
4. Verrà avviata la migrazione dei dati. Mentre la migrazione è in corso, Le API dei moduli verranno sospese con un errore "Migrazione in corso" . Questo saranno visibili anche nella UI di Connessione Salute.
5. Al termine della migrazione, l'APK potrà essere disinstallato.

di Gemini Advanced.

Nota: non è previsto che la migrazione dei dati superi le 2 ore.

Scenari di migrazione di esempio

Ecco alcuni scenari di esempio che spiegano il processo di migrazione per Tipi di dati di interval e series:

Esempio 1 - In esecuzione (dati a intervalli)

Un utente ha raccolto record per 10 anni di esecuzione per un'ora ogni giorno. Questo equivale a:

• Record della sessione di allenamento: 365 * 10 * 1
• Passi: 365 * 10 * 1
• Calorie: 365 * 10 * 1
• Totale = 365 * 10 * 3 (365 * 30) = 10.150

Dato che 1 blocco equivale a 3000 record, i dati sopra riportati ammontano a circa 4 o blocchi di testo.

I nostri test interni hanno confermato che un blocco tipico richiede circa un il secondo da inserire, quindi la migrazione dei dati sopra indicati verrà eseguita secondi.

Esempio 2 - Battito cardiaco (dati serie)

Un utente ha raccolto cinque anni di dati del battito cardiaco (con un record creato ogni al minuto) per un totale di 2.628.000 record.

A 3000 record per blocco, i dati sono distribuiti su 876 blocchi. Dato impiega circa un secondo per l'inserimento, i dati verranno migrati in meno di 15 minuti.

Flusso di migrazione proposto

Abbiamo deciso di optare per la migrazione istantanea. In pratica, questo significa che l'APK diventerà inattivo non appena verrà eseguito l'upgrade del dispositivo a Android 14, con un intervento minimo dell'utente.

Vediamo un flusso di migrazione generale:

1. L'utente esegue l'upgrade del dispositivo ad Android 14.
2. Jetpack 14 indirizza l'utente alle API del modulo e lo blocca mentre è in corso la migrazione.
3. Il processo di migrazione inizia quando la versione del modulo è compatibile con le funzionalità con l'APK, ovvero la versione del modulo contiene lo stesso insieme di funzionalità oppure altro ancora. Una volta iniziato il processo di migrazione, l'APK eseguirà la migrazione delle autorizzazioni e dati.
   1. Se entrambe le versioni non sono compatibili con le funzionalità, la versione del modulo di cui è necessario eseguire l'upgrade. Una volta completato l'upgrade, il processo di migrazione in ogni circostanza.
4. Al termine della migrazione, lo stato viene modificato in "Migrazione Complete", le API del modulo saranno sbloccate.
5. Ora l'APK può essere disinstallato.

Elementi UI della migrazione

Le seguenti schermate vengono visualizzate dal modulo Framework per la formazione degli utenti prima e durante la migrazione:

Figura 1. Se l'APK Connessione Salute non è "con conoscenza della migrazione", viene visualizzata una richiesta. che invita l'utente ad aggiornare l'APK. Se l'utente rifiuta l'aggiornamento, continua a funzionare e inizia ad accumulare autorizzazioni e dati:

Figura 2. Se il modulo del framework richiede un aggiornamento per poter diventare funzionalità compatibile, viene visualizzato un messaggio che chiede all'utente di eseguire l'aggiornamento riavviare il dispositivo. Se l'utente rifiuta l'aggiornamento, il modulo continua per funzionare e inizia ad accumulare autorizzazioni e dati:

Figura 3. Durante il processo di migrazione viene visualizzata una rotellina con un testo che spiega che i dati sono in fase di sincronizzazione:

Dati deduplicati

Se il modulo del framework ha iniziato ad acquisire dati e autorizzazioni prima di qualsiasi migrazione o ripristino basato su cloud, quanto segue si applicano tutte le regole.

Autorizzazioni

Se nel modulo del framework sono presenti autorizzazioni, eventuali duplicati le autorizzazioni acquisite dall'APK vengono ignorate durante il processo di migrazione.

Dati

Durante la migrazione, i dati duplicati provenienti dall'APK vengono ignorati. Altro viene data la preferenza ai dati recenti del modulo.

I dati vengono deduplicati il giorno clientRecordId se l'ID record viene fornito dal di alto profilo. In caso contrario, gli intervalli di tempo (startTime e endTime per e time per i record istantanei) vengono trattati come chiave, insieme ai dati il tipo e il nome del pacchetto dell'app.

Modifiche nell'SDK Jetpack

L'SDK Jetpack funge da punto di integrazione comune sia per l'integrità Collega l'APK e le API del framework Connessione Salute.

Gli OEM possono iniziare l'integrazione con Jetpack 13 in modo che quando Jetpack 14 diventi disponibili, puoi acquisire la nuova libreria e compilarla Android 14.

Rilasceremo una nuova versione dell'SDK che supporta la transizione a Android 14. Dovrai apportare alcune modifiche all'integrazione esistente per per garantire una transizione senza problemi.

Dichiarazione delle autorizzazioni

In Android 13, dichiari le autorizzazioni utilizzando un formato di autorizzazioni personalizzato, in un di risorse collegato al manifest:

#AndroidManifest.xml

<activity>
    android:name=".RationaleActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="androidx.health.ACTION_SHOW_PERMISSIONS_RATIONALE"/>
    </intent-filter>
    <meta-data
        android:name="health_permissions"
        android:resource="@array/health_permissions"/>
</activity>

<queries>
    <package android:name="com.google.android.apps.healthdata" />
</queries>

#health_permissions.xml

<resources>
  <array name="health_permissions">
    <item>androidx.health.permission.SleepSession.READ</item>
    <item>androidx.health.permission.SleepStage.READ</item>
    <item>androidx.health.permission.Weight.READ</item>
    <item>androidx.health.permission.Weight.WRITE</item>
  </array>
</resources>

Per supportare Android 14, gli sviluppatori devono passare alle autorizzazioni standard formato:

#AndroidManifest.xml

<uses-permission android:name=”android.permission.health.READ_SLEEP” />
<uses-permission android:name=”android.permission.health.READ_WEIGHT” />
<uses-permission android:name=”android.permission.health.WRITE_WEIGHT” />

<activity>
    android:name=".RationaleActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="androidx.health.ACTION_SHOW_PERMISSIONS_RATIONALE" />
    </intent-filter>
</activity>

<queries>
    <package android:name="com.google.android.apps.healthdata"/>
</queries>

Apri Connessione Salute

La maggior parte delle app di terze parti dispone di un pulsante che consente di aprire l'app Connessione Salute, come come "Gestisci accesso" in Fitbit.

In Android 13, apri l'app Connessione Salute utilizzando il nome del pacchetto oppure tramite l'azione androidx.health.ACTION_HEALTH_CONNECT_SETTINGS.

In Android 14, devi utilizzare un'azione intent, specificata nell'SDK Jetpack, che ha valori diversi in base alla versione di Android su cui agisce:

@get:JvmName("getHealthConnectSettingsAction") @JvmStatic val ACTION_HEALTH_CONNECT_SETTINGS

Recupero del client Connessione Salute in corso...

Abbiamo creato una singola API denominata sdkStatus, disponibile in Jetpack 11, per sostituire altre due API deprecate: IsSdkSupported() e isProviderAvailable().

Modifiche all'API Session Record

Sono stati eliminati quattro sottotipi ExerciseSession nell'ambito di alpha10 release:

• ExerciseEvent
• ExerciseLaps
• ExerciseRepetitions
• SwimmingStrokes

di Gemini Advanced.

Importante: gli eventuali dati di questo tipo verranno eliminati durante la pulizia. Dovresti smettere di utilizzare questi tipi di dati.

Come in ExerciseSessionRecord, SleepStage diventerà un sottotipo di SleepSession.

Verranno apportate sia le modifiche (ExerciseSessionRecord) che i sottotipi (SleepSession) sono state rilasciate nell'ambito dell'aggiornamento dell'SDK di aprile.

Aggiornamento del tipo di sessione di allenamento

I seguenti tipi di sessione di allenamento non saranno più supportati e verranno invece aggiunti i tipi di segmento in una data successiva:

• EXERCISE_TYPE_BACK_EXTENSION
• EXERCISE_TYPE_BARBELL_SHOULDER_PRESS
• EXERCISE_TYPE_BENCH_PRESS
• EXERCISE_TYPE_BENCH_SIT_UP
• EXERCISE_TYPE_BURPEE
• EXERCISE_TYPE_CRUNCH
• EXERCISE_TYPE_DEADLIFT
• EXERCISE_TYPE_DUMBBELL_CURL_LEFT_ARM
• EXERCISE_TYPE_DUMBBELL_CURL_RIGHT_ARM
• EXERCISE_TYPE_DUMBBELL_FRONT_RAISE
• EXERCISE_TYPE_DUMBBELL_LATERAL_RAISE
• EXERCISE_TYPE_DUMBBELL_TRICEPS_EXTENSION_LEFT_ARM
• EXERCISE_TYPE_DUMBBELL_TRICEPS_EXTENSION_RIGHT_ARM
• EXERCISE_TYPE_DUMBBELL_TRICEPS_EXTENSION_TWO_ARM
• EXERCISE_TYPE_FORWARD_TWIST
• EXERCISE_TYPE_JUMPING_JACK
• EXERCISE_TYPE_JUMP_ROPE
• EXERCISE_TYPE_LAT_PULL_DOWN
• EXERCISE_TYPE_LUNGE
• EXERCISE_TYPE_PLANK
• EXERCISE_TYPE_SQUAT
• EXERCISE_TYPE_UPPER_TWIST

Tipi di sostituzioni:

• EXERCISE_TYPE_HIGH_INTENSITY_INTERVAL_TRAINING
• EXERCISE_TYPE_STRENGTH_TRAINING
• EXERCISE_TYPE_CALISTHENICS

Gestione del log delle modifiche

Nell'ambito del passaggio dall'APK ad Android 14, non verrà eseguita la migrazione dei log delle modifiche.

Al termine della migrazione, inizierai a ricevere TOKEN_EXPIRED o TOKEN_INVALID eccezioni. Questi aspetti devono essere gestiti nei seguenti modi (ad ordine di preferenza):

1. Legge e deduplica tutti i dati dall'ultima lettura o per l'ultimo timestamp 30 giorni

Archivia il timestamp dell'ultima lettura dei dati di Connessione Salute da parte di un'app. Sul token scadenza, i dati devono essere rilegati da questo valore o dai 30 giorni precedenti (a seconda di quale sia pari al minimo) e li deduplica in base ai dati letti in precedenza utilizzando l'UUID.

2. Dati letti dall'"ultima lettura" timestamp

Stabilisci un timestamp che indichi quando sono stati letti i dati per l'ultima volta da Connessione Salute e alla scadenza del token, leggi tutti i dati dopo quel valore.

3. Eliminare e rileggere i dati degli ultimi 30 giorni

Elimina tutti i dati letti da Connessione Salute degli ultimi 30 giorni e leggi tutti di quei dati (ad esempio, come avviene quando le app si integrano per la prima volta con l'app Salute) Connetti).

4. Non fare nulla (ad esempio rileggere i dati degli ultimi 30 giorni e non eseguire la deduplicazione)

Questa opzione deve essere utilizzata come ultima risorsa, con un rischio associato di visualizzazione duplicati. Gli sviluppatori dovrebbero invece esplorare le opzioni 1-3, dato che gli UUID dovrebbe essere già presente.

Test delle API Android 14 con l'SDK Jetpack

Il rilascio dell'SDK Android 14 Jetpack è previsto per il 7 giugno 2023, insieme Versione beta 3 di Android 14. Dovrai iniziare a compilare la tua app in base a Android 14 per poter utilizzare l'SDK Android 14 Jetpack.

Se vuoi testare la tua soluzione rispetto alle build di Anteprima per gli sviluppatori Android prima del 7 giugno, contatta il tuo PDC Google per ricevere assistenza.

Se vuoi testare la tua soluzione rispetto alla release beta 3, devi fare le seguenti modifiche nel tuo APK:

1. Imposta compileSDKPreview = UpsideDownCake.
2. Aggiorna il file manifest in modo da includere un intent per Android 14:

# AndroidManifest.xml

<uses-permission android:name=”android.permission.health.READ_SLEEP”/>
<uses-permission android:name=”android.permission.health.READ_WEIGHT”/>
<uses-permission android:name=”android.permission.health.WRITE_WEIGHT”/>

<activity>
    android:name=".RationaleActivity"
    android:exported="true">
    <intent-filter>
        <action android:name="androidx.health.ACTION_SHOW_PERMISSIONS_RATIONALE"/>
    </intent-filter>
</activity>

<activity-alias>
      android:name="AndroidURationaleActivity"
      android:exported="true"
      android:targetActivity=".RationaleActivity"
      android:permission="android.permission.START_VIEW_PERMISSION_USAGE">
      <intent-filter>
        <action android:name="android.intent.action.VIEW_PERMISSION_USAGE" />
        <category android:name="android.intent.category.HEALTH_PERMISSIONS" />
      </intent-filter>
</activity-alias>

<queries>
    <package android:name="com.google.android.apps.healthdata" />
</queries>

Personalizzazione OEM

In Android 14, privacy e funzionalità di Connessione Salute i controlli di gestione dei dati si trovano nelle Impostazioni di sistema.

Per fare in modo che le schermate di gestione dei dati e delle autorizzazioni abbiano l'aspetto e il design dispositivo, Connessione Salute offre la tematizzazione OEM tramite overlay personalizzati.

Per la documentazione sullo stile OEM, consulta Google Mobile Services di Connessione Salute documentazione.