Migration Auth0.Android v3 vers v4

Migre une intégration Auth0.Android (com.auth0.android:auth0) v3 existante vers v4. Chaque modification de code est conditionnée par une vérification qui confirme que le projet utilise réellement l'API affectée — si le projet n'utilise jamais SecureCredentialsManager, aucun code SecureCredentialsManager n'est touché. Les modifications respectent l'architecture existante du projet (Kotlin ou Java, callback ou coroutine) et les conventions Android.

La version cible est basée sur un argument

Cette compétence accepte un argument de version cible optionnel :

• /auth0-android-major-migration 4.0.0 — migrer vers le tag exact 4.0.0 (validé avant utilisation).
• /auth0-android-major-migration (sans argument) — auto-résoudre la dernière version dans la prochaine majeure (v4.x), y compris les pré-versions.

$ARGUMENTS, s'il est présent, est le tag cible demandé. L'étape 2 le valide et résout le <TARGET_TAG> final utilisé pour le reste de la migration.

Quand NE PAS utiliser

• Nouvelle intégration Auth0 (pas de SDK Auth0.Android existant) : Utiliser auth0-android
• Mise à jour mineure/patch (ex. 3.18 → 3.19) : Mettre à jour la version com.auth0.android:auth0 dans Gradle — aucune migration nécessaire
• Applications iOS / macOS : Utiliser auth0-swift-major-migration
• React Native / Expo : Utiliser auth0-react-native ou auth0-expo
• Flutter : Utiliser le SDK natif Auth0 Flutter

Prérequis

• Intégration Auth0.Android v3 existante (com.auth0.android:auth0:3.x)
• SDK Android / chaîne d'outils Gradle installés ; le projet se compile correctement sur la version actuelle
• Projet sous contrôle de version git avec un répertoire de travail propre

Flux de migration

Instruction d'agent : Exécuter chaque étape dans l'ordre. L'objectif est une compilation verte avec le plus petit ensemble de modifications correct. Chaque étape de modification de code est contrôlée par l'audit de lecture de fichier de l'étape 5 — si l'API n'a pas été trouvée dans les fichiers source du projet, ignorer l'étape entière pour cette zone. Ne jamais ajouter de code que le projet n'appelle pas déjà. v4 augmente également les exigences de plateforme (étape 3) qui peuvent bloquer la migration jusqu'à satisfaction — gérer celles-ci avant de toucher à tout site d'appel Auth0 API.

Étape 1 — Vérification préalable et sauvegarde de sécurité

# 1a. Vérifier que le répertoire de travail est propre — arrêter s'il y a des modifications non validées
git status --porcelain

Si la sortie n'est pas vide, demander à l'utilisateur :

« Vous avez des modifications non validées. Dois-je les ranger avant de continuer (git stash), ou préférez-vous valider d'abord ? »

# 1b. Créer une branche de sécurité vers laquelle l'utilisateur peut revenir à tout moment
git checkout -b auth0-v4-migration-backup
git checkout -

# 1c. Confirmer que le projet se compile sur la version actuelle avant de toucher à quoi que ce soit
./gradlew assembleDebug 2>&1 | tail -15

Si la compilation échoue, arrêter. Demander à l'utilisateur de corriger les problèmes existants en premier — ne pas migrer un projet qui ne se compile pas.

Étape 2 — Détecter la version actuelle et résoudre la version cible

Détecter la version actuelle d'Auth0.Android (vérifier chaque emplacement applicable) :

# Dépendance intégrée dans un fichier build de module (Groovy ou Kotlin DSL)
grep -rEn "com\.auth0\.android:auth0:[0-9]" --include=build.gradle --include=build.gradle.kts .

# Catalogue de versions Gradle
grep -rEn "auth0" --include=libs.versions.toml .

# Fichier de verrouillage résolu (plus fiable s'il existe)
grep -rEn "com\.auth0\.android:auth0:[0-9]" --include=gradle.lockfile .

Résoudre la version cible. Il y a deux chemins :

Chemin A — l'utilisateur a passé un argument de version cible ($ARGUMENTS) :

Le valider contre les versions publiées avant de l'utiliser. Il doit passer les trois vérifications :

# Lister tous les tags de version publiés d'Auth0.Android
gh api repos/auth0/Auth0.Android/releases --paginate \
  --jq '.[] | select(.draft==false) | .tag_name'

1. Existe — le tag demandé apparaît dans la liste de version publiée ci-dessus.
2. Prochaine majeure — le tag est dans la ligne v4 (tag_name commence par 4). Un tag 3.x ou inférieur n'est pas la prochaine majeure ; le rejeter.
3. Pas une régression — le tag est plus récent que la version détectée dans le projet.

Si une vérification échoue, ARRÊTER et demander à l'utilisateur. Ne pas se replier silencieusement. Par exemple :

• « 4.9.9 n'est pas une version publiée d'Auth0.Android. Les versions v4 publiées sont : 4.0.0-beta.1, … . Veuillez passer un tag v4 valide, ou omettez l'argument pour auto-résoudre la dernière version v4. »
• « 3.19.0 est une version v3, pas la prochaine majeure. Cette compétence migre vers v4. Passez un tag v4 (ex. 4.0.0) ou omettez l'argument. »
• « 4.0.0-beta.0 est plus ancien que 4.0.0-beta.1 déjà dans votre projet — c'est une régression. Passez un tag v4 plus récent ou omettez l'argument. »

Chemin B — pas d'argument : auto-résoudre la dernière version v4 (y compris les pré-versions) :

# Tag de version v4.x le plus récent (stable ou pré-version), du plus récent d'abord
gh api repos/auth0/Auth0.Android/releases --paginate \
  --jq '[.[] | select(.draft==false) | select(.tag_name|startswith("4"))] | .[0].tag_name'

Enregistrer le résultat comme <TARGET_TAG> et l'utiliser dans chaque étape suivante.

Si <TARGET_TAG> est une pré-version (contient -beta, -rc, etc.), dire à l'utilisateur avant de continuer : « v4 n'est pas encore généralement disponible — la dernière version v4 est <TARGET_TAG> (une pré-version). Je vais migrer vers cela. Vous pouvez épingler un tag différent en le passant en argument. »

Si aucune version v4 n'existe encore (le résolveur retourne vide), arrêter et dire à l'utilisateur qu'il n'y a pas de version v4 publiée vers laquelle migrer.

Étape 3 — Porte des prérequis (changements d'exigences)

v4 augmente les exigences de la chaîne d'outils de compilation et du plancher de plateforme. Vérifier chaque exigence avant de migrer une API. Si une exigence n'est pas satisfaite, inviter l'utilisateur et appliquer la modification du fichier build (ou bloquer jusqu'à confirmation) — un projet qui ne satisfait pas celles-ci ne se compilera pas contre v4 indépendamment des modifications d'API.

Confirmer les versions exactes requises pour <TARGET_TAG> à partir du fichier build.gradle / gradle-wrapper.properties propre du SDK récupéré à l'étape 4 s'ils diffèrent des valeurs ci-dessous (celles-ci reflètent la ligne de base v4).

# Inspecter les valeurs actuelles
grep -rEn "minSdk(Version)?\s*[ =]" --include=build.gradle --include=build.gradle.kts .
grep -rEn "sourceCompatibility|targetCompatibility|jvmTarget" --include=build.gradle --include=build.gradle.kts .
grep -En "distributionUrl" gradle/wrapper/gradle-wrapper.properties
grep -rEn "com\.android\.tools\.build:gradle|kotlin_version|kotlin(\"|-)" --include=build.gradle --include=build.gradle.kts --include=libs.versions.toml .

minSdk inférieur à 26 est un blocage dur. Si le projet cible l'API 25 ou inférieure, dire à l'utilisateur que cela augmente la version Android minimale supportée (les appareils sous Android 7.1 et inférieur ne seront plus supportés) et lui demander de confirmer avant de augmenter minSdk à 26 — ou de rester sur v3.

Appliquer les augmentations requises (formes d'exemple — adapter au DSL du projet) :

android {
    defaultConfig { minSdk 26 }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_17
        targetCompatibility JavaVersion.VERSION_17
    }
    kotlinOptions { jvmTarget = '17' }
}

Voir references/process.md pour les cas limites Kotlin DSL, catalogue de versions, et Gradle/AGP wrapper.

Étape 4 — Récupérer et lire la source du SDK v4

Récupérer la source Kotlin actuelle pour <TARGET_TAG>. Les signatures ici sont la référence authoritative pour chaque modification apportée à l'étape 7. Ne pas migrer de mémoire ou du guide seul — confirmer chaque signature dans la source récupérée.

TAG=<TARGET_TAG>   # la version résolue à l'étape 2, ex. 4.0.0-beta.1
BASE="https://raw.githubusercontent.com/auth0/Auth0.Android/${TAG}/auth0/src/main/java/com/auth0/android"

# Lister tous les fichiers Kotlin publics du SDK (confirmer les chemins pour ce tag)
gh api "repos/auth0/Auth0.Android/git/trees/${TAG}?recursive=1" \
  --jq '.tree[].path | select(startswith("auth0/src/main/") and endswith(".kt"))'

# Récupérer les fichiers qui soutiennent les changements majeurs
for FILE in \
  provider/WebAuthProvider.kt \
  authentication/AuthenticationAPIClient.kt \
  authentication/mfa/MfaApiClient.kt \
  authentication/storage/SecureCredentialsManager.kt \
  authentication/storage/CredentialsManager.kt \
  authentication/storage/BaseCredentialsManager.kt \
  authentication/storage/Storage.kt \
  dpop/DPoPException.kt \
  result/SSOCredentials.kt \
  request/DefaultClient.kt ; do
    CONTENT=$(curl -sf "${BASE}/${FILE}")
    [ -n "$CONTENT" ] && echo "=== ${FILE} ===" && echo "$CONTENT"
done

Si un tag de version n'a pas encore de source (ex. pendant la phase de développement v4, avant que le premier tag ne porte l'arborescence complète), se replier sur la branche v4_development pour la confirmation de signature : remplacer ${TAG} par v4_development dans les URL ci-dessus. Toujours préférer le tag choisi quand il a une source.

Lire la source récupérée et noter, pour chaque fichier :

• Les signatures de méthodes publiques qui ont changé (paramètres, type de retour, @Throws)
• Les constructeurs qui ont été supprimés
• Les types/classes qui ont été supprimés ou renommés
• Les valeurs de paramètres par défaut qui ont changé (ex. minTtl)

C'est la source de vérité. Chaque modification à l'étape 7 doit correspondre à une signature réelle dans ces fichiers.

Étape 5 — Audit des APIs Auth0 utilisées par le projet

Trouver tous les fichiers source qui importent le SDK Auth0 — c'est la portée de la migration :

grep -rlE "import com\.auth0\.android" --include="*.kt" --include="*.java" .

Lire chaque fichier de cette liste. Ne pas faire un grep pour des motifs individuels d'API et s'arrêter là — lire la source complète pour voir exactement comment Auth0, WebAuthProvider, AuthenticationAPIClient, SecureCredentialsManager/CredentialsManager, et tout type Auth0 sont utilisés, y compris les chaînes de constructeur multi-lignes et tout conformance Storage personnalisée.

Pour chaque fichier, identifier :

Construire une liste de contrôle : « Ce projet utilise : [liste] » et « Ce projet N'utilise PAS : [liste] ». Travailler uniquement sur les sections §7.x / §9.x qui apparaissent dans la liste « utilise ». Ignorer le reste entièrement.

Étape 6 — Mettre à jour la dépendance du SDK

Appliquer le style de déclaration correspondant. Utiliser <TARGET_TAG> de l'étape 2.

Intégré — DSL Groovy (build.gradle) :

implementation 'com.auth0.android:auth0:<TARGET_TAG>'

Intégré — DSL Kotlin (build.gradle.kts) :

implementation("com.auth0.android:auth0:<TARGET_TAG>")

Catalogue de versions (gradle/libs.versions.toml) :

[versions]
auth0 = "<TARGET_TAG>"

Les tags pré-version (ex. 4.0.0-beta.1) doivent être épinglés exactement — ne pas utiliser de plage dynamique comme 4.+ ou [4.0,5.0), que Gradle peut résoudre à un artefact différent. Pour les versions v4 stables, une version exacte est toujours recommandée pour la reproductibilité.

Ne pas compiler pour le moment — appliquer toutes les modifications de code connues d'abord (étape 7), puis compiler (étape 8) pour surfacer les restants.

Étape 7 — Appliquer les changements majeurs

Instruction d'agent : Travailler uniquement sur les sections §7.x qui ont correspondu pendant l'audit de l'étape 5. Ignorer chaque section dont l'API n'est pas utilisée par le projet — ne pas toucher ces fichiers. Appliquer chaque modification exactement comme montré, confirmé par la source récupérée à l'étape 4. Ne pas renommer les variables, reformater, ou moderniser le code qui n'est pas en cours de migration. Adapter au style existant du projet : callback → callback, coroutine await → coroutine await, Kotlin → Kotlin, Java → Java.

7.1 — PasskeyAuthProvider supprimé

S'applique si : L'étape 5 a trouvé PasskeyAuthProvider dans les fichiers source du projet.

La classe com.auth0.android.provider.PasskeyAuthProvider a été supprimée. Les opérations de clé d'accès vivent maintenant sur AuthenticationAPIClient : passkeyChallenge(), signupWithPasskey(), et signinWithPasskey(). Confirmer les signatures exactes dans AuthenticationAPIClient.kt récupéré à l'étape 4, puis migrer chaque site d'appel vers la méthode client correspondante. Si un flux de clé d'accès ne peut pas être migré avec confiance à partir de la source, ajouter un // TODO: et le lister dans le résumé de l'étape 10 plutôt que de deviner.

7.2 — API Management supprimée (UsersAPIClient)

S'applique si : L'étape 5 a trouvé UsersAPIClient, ManagementException, ou ManagementCallback dans les fichiers source du projet.

Le client entier d'API Management a été supprimé du SDK en v4. Appeler l'API Management directement à partir d'une application mobile n'a jamais été recommandé — cela nécessite un jeton privilégié sur l'appareil. Ne pas supprimer silencieusement les sites d'appel. Ajouter un // TODO: qui préserve l'intention et surfacer ceci dans le résumé de l'étape 10 comme travail de backend requis.

// v3 — appel direct d'API Management depuis l'app (ex. mise à jour user_metadata)
val users = UsersAPIClient(account, accessToken)
users.updateMetadata(userId, metadata)
    .start(object : Callback<UserProfile, ManagementException> { /* ... */ })

// v4 — client Management supprimé ; préserver l'intention, déplacer vers un backend
// TODO: Auth0.Android v4 a supprimé le client d'API Management (UsersAPIClient).
// Exposer un point de terminaison sur votre propre backend (ex. PATCH /me/metadata) qui effectue
// cette opération. L'appeler depuis l'app avec le jeton d'accès de l'utilisateur comme jeton
// Bearer. Sur le backend, obtenir un jeton machine-à-machine via Client Credentials
// et appeler l'API Management avec les portées minimales requises.
// NE JAMAIS intégrer un jeton d'API Management dans l'app.
// Voir : https://auth0.com/docs/manage-users/user-accounts/manage-user-metadata

Ceci nécessite du travail de backend — l'enregistrer dans le résumé de l'étape 10.

7.3 — Méthodes MFA dépréciées supprimées de AuthenticationAPIClient → MfaApiClient

S'applique si : L'étape 5 a trouvé loginWithOTP(, loginWithOOB(, loginWithRecoveryCode(, ou multifactorChallenge( appelés sur un AuthenticationAPIClient dans les fichiers source du projet.

Ces quatre méthodes ont été dépréciées en v3 et supprimées en v4. Obtenir un MfaApiClient via AuthenticationAPIClient.mfaClient(mfaToken) et utiliser ses APIs. Confirmer les signatures exactes de la méthode MfaApiClient dans MfaApiClient.kt récupéré à l'étape 4 avant d'appliquer les modifications.

// v3 — méthodes supprimées sur AuthenticationAPIClient
authentication
    .loginWithOTP(mfaToken, otp)
    .start(object : Callback<Credentials, AuthenticationException> { /* ... */ })

// v4 — obtenir un MfaApiClient et utiliser son API verify (confirmer signature dans MfaApiClient.kt)
val mfaClient = authentication.mfaClient(mfaToken)
// ex. mfaClient.verifyWithOTP(otp) — utiliser la méthode/les paramètres exacts de la source récupérée

Le mfaToken vient toujours du même endroit — une AuthenticationException où le défi est requis. Lister chaque flux MFA migré dans le résumé de l'étape 10 et demander à l'utilisateur de re-tester chaque flux MFA de bout en bout contre son tenant. Voir references/process.md pour la correspondance complète des méthodes.

7.4 — WebAuthProvider.useDPoP(context) déplacé vers le constructeur de connexion

S'applique si : L'étape 5 a trouvé WebAuthProvider.useDPoP( appelé sur l'objet WebAuthProvider avant .login(. Lire la chaîne d'appels réelle — elle peut s'étendre sur plusieurs lignes.

En v4, useDPoP(context) est configuré par demande sur le constructeur de connexion plutôt que globalement sur l'objet WebAuthProvider. Déplacer l'appel .useDPoP(context) pour qu'il s'enchaîne après .login(account).

// v3 — configuration globale (ne compile plus)
WebAuthProvider
    .useDPoP(context)
    .login(account)
    .start(context, callback)

// v4 — basé sur constructeur, par demande
WebAuthProvider
    .login(account)
    .useDPoP(context)
    .start(context, callback)

7.5 — DPoPException.UNSUPPORTED_ERROR supprimé

S'applique si : L'étape 5 a trouvé DPoPException.UNSUPPORTED_ERROR dans les fichiers source du projet.

Avec le minSdk augmenté à l'API 26, DPoP est supporté sur chaque niveau API que v4 cible, donc cette constante a été supprimée. Supprimer toute référence à elle — par exemple, une branche when/if ou comparaison qui vérifiait UNSUPPORTED_ERROR. Aucun remplacement n'est nécessaire ; le cas version non supportée ne peut plus se produire.

// v3 — garder contre le cas non supporté
if (error == DPoPException.UNSUPPORTED_ERROR) {   // ❌ n'existe plus en v4
    showDeviceUnsupported()
} else {
    handle(error)
}

// v4 — la garde ne s'applique plus ; gérer les cas restants
handle(error)

7.6 — SSOCredentials.expiresIn → expiresAt (Int → Date)

S'applique si : L'étape 5 a trouvé .expiresIn accédé sur une valeur SSOCredentials dans les fichiers source du projet.

SSOCredentials.expiresIn (secondes brutes, Int) a été renommé en expiresAt et est maintenant une Date absolue (calculée lors de la désérialisation, cohérente avec Credentials.expiresAt). Renommer la propriété et mettre à jour tout calcul arithmétique qui supposait une durée en secondes.

Le format de câble JSON est inchangé — le champ est toujours @field:SerializedName("expires_in") dans le SDK. Seul le nom de propriété Kotlin et le type ont changé (expiresIn: Int → expiresAt: Date) ; ne pas s'attendre à une clé renommée expires_at si vous greppez le JSON brut.

// v3 — secondes jusqu'à l'expiration (Int)
val secondsUntilExpiry: Int = ssoCredentials.expiresIn

// v4 — Date d'expiration absolue
val expirationDate: Date = ssoCredentials.expiresAt
// Si vous aviez précédemment fait `now + expiresIn` pour obtenir une heure absolue, utiliser expiresAt directement.

7.7 — Les constructeurs SecureCredentialsManager basés sur Auth0 supprimés

S'applique si : L'étape 5 a trouvé SecureCredentialsManager( construit avec une instance Auth0 comme premier argument dans les fichiers source du projet.

Les deux constructeurs qui acceptaient une instance Auth0 ont été supprimés. Les deux constructeurs restants prennent un AuthenticationAPIClient en premier. Construire le client à partir du compte Auth0, puis passer le même client dans SecureCredentialsManager.

// v3 — constructeurs basés sur Auth0 (supprimés en v4)
val manager = SecureCredentialsManager(auth0, context, storage)
val manager = SecureCredentialsManager(auth0, context, storage, fragmentActivity, localAuthenticationOptions)

// v4 — construire un AuthenticationAPIClient d'abord, le passer en
val apiClient = AuthenticationAPIClient(auth0)
val manager = SecureCredentialsManager(apiClient, context, storage)

// v4 — variante biométrique
val apiClient = AuthenticationAPIClient(auth0)
val manager = SecureCredentialsManager(
    apiClient,
    context,
    storage,
    fragmentActivity,
    localAuthenticationOptions
)

// Java — même modification ; il n'y a pas de surcharge spécifique à Java
AuthenticationAPIClient apiClient = new AuthenticationAPIClient(auth0);
SecureCredentialsManager manager = new SecureCredentialsManager(apiClient, context, storage);

Si le projet active DPoP, le configurer sur le client avant de le passer : AuthenticationAPIClient(auth0).useDPoP(context). Confirmer les signatures du constructeur dans SecureCredentialsManager.kt récupéré à l'étape 4.

Étape 8 — Compiler jusqu'au vert

./gradlew assembleDebug 2>&1 | tail -40

Pour chaque erreur : la lire, localiser la ligne source, l'adapter à une section de l'étape 7, vérifier la correction par la signature récupérée à l'étape 4, l'appliquer dans le style existant du projet, puis recompiler.

Erreur de compilation → correspondance de cause :

Limite : Jusqu'à 10 cycles de correction de compilation. Si la compilation échoue toujours après 10 tentatives, arrêter et afficher les erreurs restantes avec contexte — ne pas deviner.

Étape 9 — Comportement et changements de valeurs par défaut (révision, généralement pas de modification de code)

Ces modifications se compilent sans éditions mais modifient le comportement lors de l'exécution. Surfacer chacune dans le résumé de l'étape 10. Modifier le code seulement si le projet dépend de l'ancien comportement.

9.1 — minTtl par défaut du Credentials Manager 0 → 60s

S'applique si : Le projet appelle getCredentials(...) / awaitCredentials(...) sans minTtl explicite, ou appelle hasValidCredentials().

v4 renouvelle les identifiants qui expirent dans les 60 secondes au lieu de seulement quand déjà expirés. C'est le comportement recommandé (évite de remettre des jetons qui expirent au milieu d'une demande). Pour restaurer le comportement v3 explicitement, passer minTtl = 0 :

// v4 — restaurer le comportement v3 explicitement si requis
credentialsManager.getCredentials(scope = null, minTtl = 0, callback = callback)

9.2 — CredentialsManager utilise maintenant l'exécuteur global

Exécution seulement. Les renouvellements entre managers soutenus par le même objet Auth0 sont maintenant sérialisés, éliminant les échanges de jeton de rafraîchissement dupliqués. Aucune modification de code requise.

9.3 — clearCredentials() efface maintenant tout le stockage

S'applique si : Le projet appelle clearCredentials().

v4 appelle Storage.removeAll(), effaçant toutes les valeurs du stockage — y compris les identifiants API stockés pour des audiences spécifiques. Si le projet doit préserver d'autres données dans le même Storage, recommander une instance Storage séparée pour les identifiants API, ou considérer le nouveau clearAll() (améliorations optionnelles de l'étape 10).

9.4 — L'interface Storage gagne removeAll()

S'applique si : Le projet a une classe implémentant l'interface Storage.

removeAll() est livré avec une implémentation vide par défaut, donc les implémentations personnalisées Storage existantes compilent toujours. Surcharger removeAll() pour effacer réellement le stockage si ce stockage personnalisé est utilisé avec clearCredentials() — sinon clearCredentials() devient un no-op pour cela.

Étape 10 — Résumé de la migration

Présenter un résumé concis couvrant :

1. Prérequis changés — minSdk / Java / Gradle / AGP / augmentations Kotlin appliquées, et que minSdk 26 abandonne le support pour Android 7.1 et inférieur.

2. Modifications appliquées — groupées par zone API (§7.x), avec les fichiers touchés par zone.

3. Nécessite une révision manuelle

• Flux §7.1 Passkey / §7.3 MFA migrés vers les nouveaux clients — re-tester de bout en bout contre le tenant.
• Tout // TODO: laissé pour §7.2 (API Management) — travail de backend requis.

4. Changements comportementaux (pas de modification de code, vérifier acceptabilité)

• §9.1 minTtl par défaut maintenant 60s — les jetons se renouvellent 60s avant expiration.
• §9.3 clearCredentials() efface maintenant tout le stockage (y compris les identifiants API).
• §9.2 CredentialsManager utilise maintenant l'exécuteur global (renouvellements sérialisés).

5. Suivi de backend / configuration

• §7.2 Suppression d'API Management — lister les opérations ébauchées avec TODO et ce qui doit se déplacer vers un backend sécurisé (jeton M2M, jamais sur appareil).

6. Améliorations optionnelles non appliquées (lister brièvement ; jamais auto-appliquer)

• clearAll() — nettoyage complet des identifiants et de la clé cryptographique à la déconnexion/suppression de compte.
• WebAuthProvider.registerCallbacks() dans onCreate() — prévient les rappels perdus / fuites mémoire lors du changement de configuration ou de la mort du processus lors de l'authentification.
• DefaultClient.Builder — le constructeur est déprécié (non supprimé) ; le constructeur ajoute des délais d'écriture/appel, des intercepteurs personnalisés, et des loggers.
• Gson 2.8.9 → 2.11.0 (transitive) — TypeToken plus strict / coercition de type ; voir references/process.md.

7. Demander à l'utilisateur s'il souhaite valider la migration, explorer une amélioration optionnelle, ou parcourir des fichiers spécifiques ensemble.

Rappel de sécurité : Ne jamais inclure de jetons, secrets, identifiants clients, ou valeurs d'identifiants stockés dans le résumé ou tout journal de compilation.

Références détaillées

• Processus de migration — validation d'argument de version, gestion des prérequis/chaîne d'outils, cas limites de système de compilation (DSL Groovy, DSL Kotlin, catalogues de versions), correspondance des méthodes MFA, motif de backend d'API Management, notes transitives Gson, rollback, et guidance « déprécié ≠ supprimé ».
• Liste de vérification de sécurité — invariants qui doivent se maintenir avant et après la migration.

Erreurs courantes

Compétences connexes

• auth0-android — Nouvelle intégration Auth0.Android à partir de zéro
• auth0-swift-major-migration — Mises à jour de version majeure Auth0.swift
• auth0-mfa — Configurer l'authentification multifacteur

Références

• Auth0.Android GitHub
• Versions d'Auth0.Android
• Guide de migration V4
• Documentation du SDK Android d'Auth0

Sécurité : Ne jamais afficher les jetons, secrets clients, ou identifiants dans les journaux de compilation ou la sortie terminal. Ne jamais valider les secrets dans le contrôle de version.