« Votre appareil n'est pas compatible avec cette version » dans un test fermé

Votre testeur s'est inscrit, a ouvert l'app dans le Play Store et, au lieu d'un bouton d'installation, a obtenu « Votre appareil n'est pas compatible avec cette version » (en anglais : « Your device isn't compatible with this version »). Le compte et le lien sont bons. Google Play décide, à partir de votre build et de vos réglages dans la Play Console, que ce téléphone-là ne doit pas recevoir l'app.

La bonne nouvelle : contrairement à la plupart des problèmes de test fermé, celui-ci laisse une trace claire dans la Play Console. Vous trouvez en général la raison exacte en deux minutes.

Sur le site web de Google Play, la même situation affiche l'appareil du testeur en grisé. Google explique que « cela se produit généralement parce que l'application n'est pas disponible dans votre pays ou qu'elle n'est pas conçue pour la taille d'écran ou la version Android de votre appareil » (Aide Google Play).

Un testeur, ou tout le monde ?

Étape 1 : chercher l'appareil dans le Catalogue d'appareils

Demandez au testeur le modèle exact de son téléphone et sa version d'Android (Paramètres > À propos du téléphone). Ouvrez ensuite Surveiller et améliorer > Portée et appareils > Catalogue d'appareils dans la Play Console et cherchez le modèle (Aide Play Console).

L'état vous dit où chercher :

• Non compatible : votre manifeste exige une fonctionnalité ou une propriété que l'appareil n'a pas, comme un niveau de SDK, une taille d'écran ou un capteur.
• Partiellement compatible : certaines variantes du modèle fonctionnent et d'autres non, souvent à cause de la version d'Android ou de la RAM.
• Exclu par la règle, Partiellement exclu par la règle, Exclu manuellement : vous, ou quelqu'un de votre équipe, l'avez exclu dans la Play Console.

Regardez l'état pour la piste de test fermé. Google affiche la compatibilité piste par piste, car chaque piste peut porter un build différent : « si la version bêta de votre application nécessite plus de fonctionnalités que la version de production, vous pouvez remarquer qu'un appareil est compatible avec la version de production, mais pas avec la version bêta. »

Causes et solutions, dans l'ordre où les essayer

1. Votre version minimale d'Android est trop haute

Si minSdk dépasse la version d'Android du testeur, Google Play n'affiche pas l'app sur ce téléphone (Android Developers).

Solution : baissez minSdk si votre code le permet, ou acceptez que ce testeur ne fasse pas partie de vos 12 et recrutez quelqu'un avec une version d'Android plus récente. Ne confondez pas minSdk et targetSdk : les nouvelles apps doivent cibler l'API 36, ce qui ne dit rien de la plus ancienne version d'Android que vous prenez en charge. Voyez API cible 36.

2. Une fonctionnalité matérielle est marquée comme requise

Chaque <uses-feature> que vous déclarez écarte les appareils qui n'ont pas ce matériel. L'exemple de Google : une app qui déclare le capteur de lumière n'est pas proposée sur un appareil qui n'en a pas. Les autorisations comptent aussi : Google Play interprète certains éléments <uses-permission> comme des exigences de fonctionnalités implicites (Android Developers). Demander l'autorisation d'utiliser l'appareil photo peut faire de l'appareil photo une exigence, même si votre app ne s'en sert que sur un écran facultatif.

Solution : pour chaque fonctionnalité dont votre app peut se passer, déclarez-la explicitement avec android:required="false", et vérifiez sa présence à l'exécution. Envoyez ensuite un nouveau build avec un code de version plus élevé.

<uses-feature android:name="android.hardware.camera" android:required="false" />

Bibliothèques et plugins peuvent ajouter des autorisations à votre manifeste fusionné sans que vous le remarquiez. Regardez le manifeste fusionné du build de release, pas seulement le fichier que vous modifiez.

3. Vos bibliothèques natives ne couvrent pas le processeur du testeur

Google indique qu'« une application qui inclut des bibliothèques natives ciblant une architecture de processeur spécifique (ARM EABI v7 ou x86, par exemple) n'est visible que sur les appareils compatibles avec cette architecture » (Android Developers). Cela touche les apps construites avec des moteurs ou des frameworks dont un réglage de build supprime une architecture pour gagner de la place.

Solution : vérifiez quelles ABI votre build inclut (vos réglages de build, ou les dossiers sous lib/ dans le bundle) et ajoutez celles qu'utilisent les téléphones de vos testeurs.

4. Vous avez exclu l'appareil dans la Play Console

Les utilisateurs d'appareils exclus « ne pourront pas voir ni installer votre application sur Google Play » (Aide Play Console). Les exclusions peuvent viser un modèle, ou passer par une règle sur la RAM ou le système sur puce. Elles s'appliquent à toute l'app et priment sur votre manifeste.

L'indice qui ne trompe pas : Google indique que « les règles d'exclusion d'appareils ne s'appliquent pas aux testeurs internes » (Aide Play Console). Si l'app fonctionne en test interne sur le même téléphone, vérifiez d'abord les exclusions.

Solution : dans le Catalogue d'appareils, ouvrez Gérer les règles d'exclusion et l'onglet Appareils exclus. Supprimez la règle ou l'exclusion manuelle si elle n'était pas voulue.

5. Taille d'écran ou format d'appareil

Les déclarations de taille d'écran et les exigences graphiques (comme les formats de compression de texture) filtrent aussi les appareils (Android Developers). Un testeur sur tablette, Chromebook ou appareil TV peut être écarté alors que les téléphones fonctionnent. Si votre app est faite uniquement pour téléphone, c'est normal : recrutez des testeurs sur téléphone.

6. Contrôles d'intégrité de l'appareil

Google permet de limiter la distribution aux appareils qui passent les contrôles d'intégrité, depuis Tester et publier > Intégrité de l'appli. Google note que certains appareils annoncent un nom de modèle certifié sans réussir les contrôles d'intégrité de Play (Aide Play Console). Si vous avez activé cette restriction, les testeurs sur ces appareils ne peuvent pas obtenir l'app. Gardez-la si votre app en a besoin, et recrutez des testeurs sur des appareils d'origine.

7. Vous avez corrigé, mais le testeur voit toujours l'ancien message

Toute correction passe par une nouvelle version, et une nouvelle version met du temps à atteindre les testeurs. Côté testeur, l'application Play Store peut afficher des informations périmées. L'aide Google Play présente le vidage du cache du Play Store comme la solution la plus courante aux problèmes de téléchargement (Aide Google Play).

Une correction relance-t-elle les 14 jours ?

L'aide de Google ne dit nulle part que les testeurs doivent se réinscrire après un nouveau build. Elle recommande même de mettre à jour votre app en test fermé pendant que vous corrigez ce que signalent les testeurs (Aide Play Console). Les 14 jours ne comptent que les testeurs qui restent inscrits : un testeur qui ne peut pas installer risque de partir. Remplacez-le tôt.

Un problème d'appareil découvert pendant le test fermé, c'est exactement à ça que sert le test. Notez-le : le formulaire de demande d'accès production demande ce que vous avez modifié grâce au test. Voyez Item not found si le store n'affiche aucune app, et le guide de configuration pour revérifier votre piste depuis le début.

Quand contacter Google

Si le Catalogue d'appareils indique le modèle du testeur comme compatible sur votre piste de test fermé, qu'il n'y a aucune exclusion et que le message persiste plusieurs jours après un vidage du cache, contactez Google via le lien Contactez-nous de l'aide Play Console. Indiquez le modèle de l'appareil, la version d'Android, le nom de package et la piste. Pour la vue d'ensemble, voyez le guide des tests fermés Google Play.