Google Play 2027 : auditer la mémoire et la restauration
Préparez les exigences qualité Google Play 2027 : mémoire, optimisation DEX, restauration de session, preuves et scénarios de recette.
Les exigences qualité Google Play 2027 ajoutent deux contrôles distincts pour les applications Android. À partir de février, Google Play évalue la consommation de mémoire et l’optimisation du code DEX. À partir d’avril, les applications mobiles et tablettes qui proposent une connexion doivent restaurer la session lors d’un changement d’appareil. Ces sujets ne se règlent ni avec une simple montée de targetSdk, ni avec une déclaration dans la console.
Le plan utile comporte donc deux pistes menées en parallèle : mesurer et réduire l’empreinte réelle de l’application, puis préserver l’identité de session sans restaurer aveuglément les données ou les droits sensibles. Pour chaque écart, il faut une mesure, un risque utilisateur, une preuve après correction, un scénario de recette et un responsable.
Que demande Google Play en 2027 ?
Google a annoncé un calendrier en deux temps. Les exigences de février portent sur la qualité technique observée dans le parc réel et sur le bundle livré. L’exigence d’avril porte sur la continuité de connexion après la migration d’un téléphone ou la restauration d’une sauvegarde.
| Échéance annoncée | Applications concernées | Contrôle principal | Preuve à préparer |
|---|---|---|---|
| février 2027 | applications mobiles et tablettes distribuées par Google Play | mémoire d’application et de bitmap, mesurée dans Android Vitals | tendances sur 28 jours, segments d’appareils, reproduction et mesure après correction |
| février 2027 | applications dont le code DEX dépasse 10 Mo, ou 50 Mo pour les jeux | au moins 25 % d’optimisation, d’obscurcissement et de réduction | artefact de production, rapport de build, symboles conservés et test des parcours sensibles |
| avril 2027 | applications mobiles et tablettes avec connexion, hors jeux dans la première phase | restauration automatique de la connexion sur Android 9 et versions ultérieures | migration appareil à appareil, restauration cloud, déconnexion, compte invité et contrôles de sécurité |
Google précise que le non-respect peut affecter la visibilité et les capacités de publication. Il ne faut pourtant pas traiter chaque seuil comme un score isolé. L’objectif reste d’éviter une application évincée de la mémoire, une installation inutilement lourde ou une personne obligée de retrouver ses identifiants après avoir remplacé son téléphone.
Ces exigences sont différentes de la mise à niveau vers l’API 36. La cible SDK concerne la compatibilité et l’accès à la publication d’une version. Le nouveau contrôle qualité observe la mémoire, la transformation du code et la reprise de session. Une même release peut satisfaire l’API cible tout en conservant une empreinte excessive ou une migration de compte cassée.
Lire Android Vitals sans transformer le seuil en objectif de laboratoire
La mesure de mémoire publiée dans Android Vitals s’appuie sur une fenêtre glissante de 28 jours et sur le 90e centile. Elle sépare l’état de l’application — premier plan, service ou arrière-plan, cache — ainsi que la quantité de mémoire vive de l’appareil. Les données concernent Android 13 et les versions ultérieures lorsqu’elles sont disponibles.
Cette lecture évite une moyenne trompeuse. Une application peut sembler raisonnable sur un téléphone récent tout en mettant régulièrement en difficulté les appareils dotés de 4 ou 6 Go. Elle peut aussi libérer correctement ses ressources au premier plan, puis conserver des bitmaps après le passage en arrière-plan. Le diagnostic doit donc partir du segment qui dépasse, pas d’une moyenne globale produite sur une machine de développement.
Les seuils annoncés pour la mémoire totale varient avec la RAM de l’appareil :
| RAM de l’appareil | Application au premier plan | Service ou arrière-plan |
|---|---|---|
| 4 Go | 2 Go | 1 Go |
| 6 Go | 2,25 Go | 1,25 Go |
| 8 Go | 2,25 Go | 1,5 Go |
| 12 Go | 3,25 Go | 1,75 Go |
| 16 Go | 4,25 Go | 2 Go |
Pour les bitmaps, Google affiche 200 Mo lorsque l’application est perceptible ou en arrière-plan et 400 Mo lorsqu’elle est en cache. Les cases non renseignées dans la documentation ne doivent pas être converties en seuils inventés. Ces valeurs restent par ailleurs des limites de conformité, pas une cible acceptable : attendre deux gigaoctets d’empreinte au premier plan avant d’agir serait une mauvaise stratégie produit.
Commencez par trois questions : quel segment produit le dépassement, quel parcours y conduit et quelle ressource reste vivante plus longtemps que nécessaire ? Une galerie peut garder plusieurs images décodées ; une carte peut multiplier les surfaces ; un moteur hybride peut conserver un écran précédent ; un SDK peut charger un cache important au démarrage. La correction utile vise la cause et vérifie ensuite que le parcours reste fluide.
Optimiser le DEX sans casser les parcours sensibles
La seconde exigence de février concerne les applications de plus de 10 Mo de code DEX, avec un seuil porté à 50 Mo pour les jeux. Google demande au moins 25 % pour chacune des trois dimensions annoncées : optimisation, obscurcissement et réduction. L’outil n’est pas imposé ; R8 est une solution courante, mais le résultat compte davantage que son nom.
La réduction ne doit jamais être validée uniquement par la taille du fichier. L’obscurcissement peut révéler des dépendances qui utilisent la réflexion, la sérialisation, le chargement dynamique ou des ponts natifs. Une règle de conservation trop large protège la compatibilité mais annule une part du gain. Une règle trop agressive allège le bundle mais casse parfois seulement un paiement, une authentification ou une notification en production.
Le dossier de preuve doit réunir l’artefact signé proche de la production, les rapports avant et après, les fichiers de correspondance nécessaires au diagnostic des incidents et une recette des parcours qui traversent des bibliothèques sensibles. Pour une application hybride ou multiplateforme, ajoutez les ponts entre le code Android et le runtime concerné. Le résultat attendu est un bundle mesurable et débogable, pas une case verte obtenue au prix d’un support aveugle.
Ce que restaure réellement la connexion automatique
L’exigence d’avril s’appuie sur l’API Restore Credentials. Lorsqu’une personne se connecte, l’application crée une clé de restauration associée à son compte et à son package. Android peut transférer cette clé lors d’une migration appareil à appareil ou d’une restauration cloud. Au premier lancement sur le nouvel appareil, l’application récupère la clé, la valide côté serveur et recrée la session.
Ce mécanisme restaure une identité, pas tout le produit. Il ne transporte pas automatiquement les préférences, le contenu hors ligne, l’état d’un brouillon, les autorisations système, un jeton de notification ou une étape d’authentification renforcée. La documentation recommande de gérer les données et préférences avec les mécanismes de sauvegarde adaptés. Le jeton FCM doit notamment être réenregistré sur le nouvel appareil.
Cette séparation est importante pour la sécurité. Une session peut être reprise tout en exigeant une vérification supplémentaire au moment d’ouvrir une fonction sensible. Une déconnexion doit supprimer la clé de restauration. Un compte invité doit rester invité. Pour une application multicomptes, la première version du dispositif restaure un seul compte actif ou le dernier compte utilisé : l’interface doit l’assumer au lieu de laisser croire que tous les profils ont migré.
La restauration automatique ne remplace donc ni le dossier de vérification du développeur, des packages et des clés, ni la politique d’authentification du service. La vérification Android prouve qui distribue le package. Restore Credentials aide une personne déjà connue à retrouver sa session sur un nouvel appareil.
La matrice d’audit Zence : relier exigence, risque et preuve
Une liste de recommandations produit facilement des tâches sans décision. La matrice suivante relie chaque contrôle à l’effet utilisateur et à une preuve reproductible.
| Exigence | Mesure ou observation | Risque réel | Preuve attendue | Test | Responsable |
|---|---|---|---|---|---|
| mémoire au premier plan | P90 par classe de RAM et version | fermeture du processus, lenteur, concurrence avec le système | tendance Vitals et profil de la ressource dominante | rejouer le parcours le plus coûteux sur appareil contraint | responsable mobile |
| mémoire en arrière-plan | P90 après changement d’écran ou mise en veille | éviction plus fréquente, retour lent, tâche interrompue | profil avant/après et durée de rétention | quitter le parcours, attendre, revenir | responsable mobile |
| mémoire bitmap | métrique bitmap selon l’état | galerie ou carte qui sature progressivement | dimensions, cache et cycle de vie documentés | ouvrir, faire défiler, quitter puis répéter | responsable interface |
| optimisation DEX | taux par dimension et taille finale | bundle lourd ou code inutilisé conservé | rapport de build et règles de conservation justifiées | installer la release et rejouer les SDK sensibles | responsable livraison |
| création de la clé | événement après connexion et au lancement | compte non transférable malgré une session valide | clé enregistrée côté serveur sans secret exposé | connecter puis déclencher sauvegarde ou transfert | responsable identité |
| restauration de session | résultat de validation sur le nouvel appareil | reconnexion manuelle et abandon | journal technique pseudonymisé et session créée | migration appareil à appareil puis restauration cloud | responsable identité |
| déconnexion et invité | suppression ou absence de clé | réouverture indue d’un compte | événement de suppression et état anonyme confirmé | se déconnecter, restaurer, tester un invité | responsable sécurité |
| services liés | nouveau jeton et droits recalculés | notifications perdues ou droits périmés | réenregistrement et contrôle serveur | restaurer puis recevoir une notification et ouvrir une action sensible | responsable backend |
Le propriétaire n’est pas nécessairement la personne qui corrige le code. Il est celui qui accepte le résultat, conserve la preuve et décide du déploiement. Sans ce rôle, les captures Android Vitals, règles de build et journaux de test se dispersent entre plusieurs outils sans former un dossier réutilisable.
Huit scénarios de recette avant les échéances
La recette doit utiliser un artefact proche de la production et des comptes dédiés. Elle ne doit ni exposer des identifiants réels dans les captures, ni déclarer conforme un comportement seulement simulé.
- Rejouer le parcours mémoire dominant. Sur un appareil représentatif du segment en écart, ouvrir le parcours, le répéter et constater ce qui reste alloué.
- Passer l’application en arrière-plan. Quitter un écran riche en images, verrouiller l’appareil puis revenir pour vérifier libération, reprise et absence de rechargement incohérent.
- Installer le bundle optimisé. Utiliser une piste de test, puis exercer authentification, paiement, caméra, notifications, liens profonds et sérialisation lorsque ces fonctions existent.
- Migrer vers un second appareil. Partir d’une session connectée, effectuer le transfert et confirmer que le compte attendu apparaît sans formulaire de connexion.
- Restaurer depuis une sauvegarde cloud. Reproduire le cas séparément : réussir un transfert direct ne prouve pas le chemin cloud.
- Se déconnecter avant la migration. Le nouvel appareil ne doit pas recréer la session supprimée.
- Tester un invité et plusieurs comptes. L’invité reste anonyme ; le compte restauré correspond à la règle annoncée au produit.
- Rejouer une action sensible après restauration. Vérifier droits, éventuelle authentification renforcée, nouveau jeton de notification et capacité à révoquer la session côté serveur.
Chaque scénario se termine par un état explicite : passé avec preuve, bloqué avec responsable et date, ou non applicable avec justification. « Testé sur un émulateur » n’est pas une conclusion si le risque dépend de la RAM réelle, du transfert d’appareil ou de la chaîne Google Play.
Organiser le chantier sans lancer une refonte générale
Un programme de douze semaines permet de séparer les causes et de conserver une référence mesurable.
Semaines 1 à 3 : établir la référence
Exportez les 28 jours Android Vitals, segmentez par RAM, version et état, puis récupérez le bundle actuellement distribué. Cartographiez en parallèle la connexion, la déconnexion, les comptes invités, les comptes multiples, l’authentification renforcée, les sauvegardes et les notifications. L’objectif est un état daté, pas encore une correction.
Semaines 4 à 7 : corriger le plus petit ensemble de causes
Reproduisez le segment mémoire dominant, corrigez la rétention ou le chargement identifié, puis mesurez de nouveau. Activez ou ajustez l’optimisation DEX dans une branche séparée et conservez les rapports de build. Ne mélangez pas ce chantier avec une mise à jour générale des SDK si elle n’est pas indispensable à la preuve.
Semaines 8 à 10 : intégrer la reprise de session
Implémentez la création, la lecture, la validation serveur et la suppression de la clé. Définissez le compte restauré, le comportement invité, les contrôles supplémentaires et les services à réenregistrer. La documentation Android indique une disponibilité à partir d’Android 9 et une bibliothèque Credentials 1.5.0 ou ultérieure ; vérifiez la version stable adaptée au projet au moment d’intégrer.
Semaines 11 et 12 : recetter puis observer
Exécutez les huit scénarios sur appareils et builds de test, corrigez les écarts attribués et déployez progressivement. La mémoire étant observée sur 28 jours, une amélioration ne devient pas immédiatement visible dans l’agrégat. Conservez donc la mesure locale, la version déployée et la date de changement pour interpréter la tendance sans promettre un résultat instantané.
Cette méthode complète le guide de conception et d’exploitation d’une application iOS et Android et les critères pour choisir une agence capable de maintenir le produit. Elle évite de transformer une échéance de plateforme en refonte non cadrée.
Limites, exemptions et documentation encore évolutive
Au 2 septembre 2026, les jeux sont exclus de la première phase de restauration automatique, mais ils restent concernés par les règles de mémoire et par le seuil DEX spécifique. Les applications privées distribuées uniquement dans un environnement d’entreprise géré ne relèvent pas du même parcours. Les services réglementés peuvent demander une exemption de restauration ; il ne faut pas la présumer sans décision explicite de Google.
Une application qui utilisait déjà Block Store en production au plus tard le 30 septembre 2026 peut être considérée comme conforme au mécanisme de restauration, sous les conditions annoncées. Ce point doit être vérifié dans la console et dans le produit : une ancienne dépendance présente dans le code ne prouve ni son activation en production, ni la suppression correcte de la clé à la déconnexion.
Google annonce encore des précisions. Versionnez donc la source, la date de lecture et la décision prise. Si un seuil, une exemption ou l’interface de reporting évolue, mettez à jour le dossier propriétaire au lieu de repartir d’un article d’actualité sans lien avec l’application réelle.
Commencer par une preuve complète
Le premier livrable peut rester court : un segment Android Vitals expliqué, un bundle de production mesuré, un schéma de restauration de session et deux scénarios exécutés de bout en bout. Cette preuve permet de décider si le risque vient de la mémoire, du build, de l’identité, du backend ou simplement d’un manque de recette.
Zence accompagne la conception, la maintenance et la publication d’applications mobiles en reliant expérience, architecture, mesure et exploitation. Pour préparer les échéances sans ouvrir un chantier indéfini, demandez une relecture ciblée de l’application Android.
Sources officielles
- Google Play — exigences de qualité technique pour les applications, mémoire, optimisation DEX, restauration automatique, calendrier et exemptions.
- Android Developers — mémoire dans Android Vitals, états de processus, fenêtre de mesure et diagnostic.
- Android Developers — utilisation de la mémoire bitmap, métrique et seuils annoncés.
- Android Developers — activer l’optimisation de l’application, réduction, optimisation, obscurcissement et règles de conservation.
- Android Developers — restauration des identifiants, fonctionnement, identité, données d’application et limites.
- Android Developers — implémenter Restore Credentials, création, récupération, suppression, serveur et notifications.
- Android Developers — tester Restore Credentials, transfert entre appareils, sauvegarde cloud et outils de test.
