Que feriez-vous si la version de production de l'application échouait à l'endroit où la version de débogage fonctionne correctement?

1. Collecte des logs et rapports de crash: Activer et vérifier la journalisation dans la version de release (par exemple, en utilisant Firebase Crashlytics ou l'analyse). Collecter tous les rapports de crash disponibles.

2. Analyse des différences entre les builds:

   • Optimisations du compilateur: La build de release utilise souvent ProGuard/R8 pour obfusquer, minimiser et optimiser le code. Vérifier les règles de ProGuard/R8 pour détecter des erreurs qui auraient pu supprimer du code ou des ressources nécessaires, ou changer le comportement de l'application. Étudier le fichier généré mapping.txt pour déobfusquer les stacks.
   • Signatures (signing): S'assurer que la build de release est signée avec la bonne clé.
   • Drapeau Debuggable: Vérifier que dans la build de release, android:debuggable est à false.
   • Différences dans les dépendances: Vérifier les versions des bibliothèques utilisées dans les deux types de build.
   • Configurations de build (build flavors/types): Examiner les fichiers gradle pour des configurations spécifiques à la release pouvant influencer le comportement (par exemple, URLs API différentes, fonctionnalités désactivées).
   • Vérification des ressources: S'assurer que toutes les ressources nécessaires (drawable, layout, strings) sont présentes et accessibles dans la build de release.

3. Déobfuscation des stacks: Si le crash se produit dans du code obfusqué, utiliser mapping.txt pour déobfusquer le stack trace et comprendre où l'erreur se produit.

4. Reproduire l'erreur dans des conditions proches de la release:

   • Tenter de compiler une build de release avec des parties de ProGuard/R8 désactivées pour réduire le champ de recherche.
   • Créer une build de test localement, aussi proche que possible de la release (par exemple, avec ProGuard/R8 mais sans signature de release).

5. Désactiver les optimisations et l'obfuscation: Désactiver progressivement les optimisations de ProGuard/R8 dans la build de release (par exemple, désactiver l'obfuscation, puis la minimisation) pour identifier quelle optimisation cause le problème.

6. Journalisation dans la build de release: Ajouter temporairement des logs dans les parties critiques du code dans la build de release pour suivre l'exécution jusqu'au crash.

7. Vérification des facteurs externes: Considérer que le comportement peut dépendre de l'environnement (par exemple, connexion internet, version du système d'exploitation sur l'appareil de l'utilisateur).

8. Utilisation du débogueur: Si possible, se connecter à la build de release sur l'appareil (ce qui peut être difficile si debuggable est à false) ou utiliser un émulateur pour tenter de reproduire et déboguer.

9. Régression (si possible): Vérifier à quel moment le problème est apparu (par exemple, après l'ajout d'une nouvelle fonction ou mise à jour d'une bibliothèque).

10. Recherche de problèmes connus: Vérifier les problèmes connus de ProGuard/R8 avec les bibliothèques utilisées.

android {
    buildTypes {
        release {
            // Exemple de désactivation temporaire de l'obfuscation pour le débogage
            minifyEnabled true // Laissez la minimisation
            shrinkResources true // Laissez la compression des ressources
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
            // désactiver temporairement l'obfuscation pour le débogage
            // consumerProguardFiles 'proguard-debug.pro' // Ajouter des règles de débogage si nécessaire
        }
    }
}