Tests Google Play
À chaque import d'un bundle, Google l'installe sur une série d'appareils de test, laisse un robot d'exploration le parcourir pendant quelques minutes et consigne ce qui a mal tourné. Pour une app web encapsulée, une grande partie du bruit vient du contenu web et des SDK ; tout l'art consiste à savoir quels constats un examinateur rencontrerait aussi et lesquels vous pouvez simplement noter avant de passer à autre chose.
Dès $109 en paiement unique par plateforme, ou notre équipe s'occupe de tout dès $698.
Quand vous importez un app bundle dans la Play Console, Google l'installe automatiquement sur une sélection d'appareils de son laboratoire de test (téléphones, tablettes et parfois Chromebooks, sous Android 9 ou plus récent), laisse un robot l'explorer pendant plusieurs minutes en touchant, en tapant et en balayant, puis le désinstalle. Les résultats sont généralement prêts en une heure environ, parfois après plusieurs heures. Si un rapport n'est pas terminé au bout de deux jours, un nouvel import en lance un nouveau.
Le rapport compte les erreurs, les avertissements et les problèmes mineurs, les regroupe en constats de stabilité, de performances, d'accessibilité et de sécurité, et ajoute des captures d'écran et des vidéos par appareil. C'est un outil de diagnostic, pas un verdict d'examen : un avertissement ne vous empêche pas de déployer. Mais au premier lancement, le robot et un examinateur humain voient votre app de la même façon, donc tout ce qui bloque le robot bloque probablement aussi l'examinateur. Pour les causes des plantages et des écrans blancs, voir le guide sur les fonctionnalités défaillantes ; cette page explique comment lire le rapport.
Google indique que les identifiants de compte de test ne peuvent pas être utilisés quand une app connecte les utilisateurs via un parcours web dans une WebView. Derrière un écran de connexion, le robot voit une seule page sur chaque appareil.
Les contrôles d'accessibilité lisent ce que la WebView expose, si bien qu'un bouton icône sans libellé dans votre code React devient un constat pour votre app.
Les avertissements sur les interfaces non SDK ou les versions de bibliothèques viennent souvent des SDK de publicité, de push ou d'analytics, pas de quoi que ce soit que vous ayez écrit.
Pas de cookies, pas de consentement enregistré, pas de session. Un bandeau cookies ou une fenêtre d'onboarding apparaît sur chaque appareil et masque ce que vous vouliez montrer au robot.
| Constat | Signification habituelle dans une app WebView | Priorité |
|---|---|---|
| Plantage ou ANR | Une fonctionnalité activée sans sa configuration, par exemple des annonces sans ID d'app AdMob ou le push Firebase sans google-services.json | À corriger avant la publication. La trace de pile nomme généralement le SDK |
| Captures d'écran vides ou blanches | L'URL était inaccessible, la protection anti-bots a bloqué le trafic du laboratoire de test, ou du contenu mixte a bloqué la page | À corriger avant la publication. Un examinateur verrait la même chose |
| Les captures ne montrent que la page de connexion | Le robot n'a pas pu se connecter via la connexion web | À corriger pour être prêt pour l'examen : une zone publique ou de démonstration plus des liens profonds, voir ci-dessous |
| Bandeau cookies sur chaque capture | Une surcouche de consentement affichée lors de la première visite | Rendez-la compacte pour que le contenu reste visible ; gardez toute demande de consentement que la loi vous oblige à afficher |
| Avertissement de sécurité sur la gestion SSL | La WebView est autorisée à continuer malgré des erreurs de certificat | À corriger. Mettez BLOCK_SELF_SIGNED_AND_FAULTY_SSL_CERTS sur true et réparez la chaîne de certificats chez votre hébergeur |
| Avertissement de sécurité sur une version de bibliothèque | Une ancienne version de SDK issue d'un modèle obsolète | Corrigez en compilant à partir du modèle WebViewGold actuel |
| Accessibilité : taille des zones tactiles | Liens et boutons icônes de votre app web plus petits qu'environ 48 x 48 dp | Corrigez la navigation principale et les boutons principaux ; les petits liens dans le texte peuvent attendre |
| Accessibilité : libellés de contenu | Boutons uniquement composés d'une icône et images sans nom accessible | Corrigez dans l'app web avec aria-label et des textes alt |
| Accessibilité : contraste faible | Texte gris clair, texte d'espace réservé, boutons pâles | Corrigez là où cela touche le texte courant et les actions principales |
| Performances : démarrage lent ou images saccadées | Un bundle JavaScript lourd ou de grandes images sur la page de démarrage | Améliorez quand vous le pouvez ; pas bloquant |
| Utilisation d'interfaces non SDK | API Android cachées appelées par un SDK | En général informatif ; gardez le modèle et ses SDK à jour |
Je suis très content d'avoir acheté cette application ! Extrêmement facile et excellente documentation. J'ai été en contact avec le service client, ils ont répondu très rapidement et très amicalement. Ils ont résolu ma question en un jour. 10/10 recommanderaient.
Ces changements aident à la fois le robot, l'examinateur et vos captures d'écran pour le store.
Si votre produit le permet, ouvrez l'app sur une zone publique : un mode démo, une visite guidée du produit ou du contenu consultable sans compte. Le robot parcourt ce qu'il trouve ; un formulaire de connexion seul ne lui donne rien à faire.
Dans les paramètres du rapport de pré-lancement, vous pouvez indiquer jusqu'à trois liens profonds. Après l'exploration principale, le robot ouvre chacun d'eux et l'explore pendant environ 30 secondes ; chaque lien doit correspondre à un filtre d'intent de votre app. Avec WebViewGold, activez le schéma personnalisé (IS_CUSTOM_SCHEME_ENABLED et CUSTOM_DEEPLINK_SCHEME) ou des App Links validés comme le décrit la documentation App Links, puis utilisez des liens comme yourscheme://https://www.example.com/demo pour envoyer le robot vers des pages publiques.
Le champ d'identifiants des paramètres du rapport n'aide pas pour une connexion web dans une WebView. Gardez quand même un compte de démonstration fonctionnel sous Identifiants de connexion (Sign-in details), car les examinateurs humains l'utilisent.
Chaque appareil de test démarre de zéro. Gardez la demande de consentement assez petite pour que la page reste visible derrière, et évitez les fenêtres d'onboarding en plusieurs étapes dans l'app.
Importez sur le canal de tests internes avec un nouveau code de version. Ouvrez le rapport, utilisez Afficher les détails sur chaque constat et regardez les vidéos des appareils : elles montrent exactement où le robot s'est bloqué.
Les constats d'accessibilité et de performances se corrigent surtout dans votre app web et passent en ligne sans nouveau build. Les constats natifs (plantages, avertissements de SDK et de sécurité) exigent une recompilation et un nouvel import.
WebViewGold applique le custom.css du projet à chaque page chargée dans l'app. C'est donc un endroit rapide pour corriger les zones tactiles pendant que vous corrigez proprement l'app web. Les libellés ont leur place dans l'app web elle-même, par exemple aria-label="Open menu" sur un bouton icône.
/* custom.css dans le projet Android WebViewGold : ajustements pour l'app uniquement */
/* Zones tactiles minimales pour la navigation et les actions principales */
nav a,
button,
[role="button"],
.icon-button {
min-height: 48px;
min-width: 48px;
}
/* Garder le bandeau de consentement compact pour que le contenu reste visible */
.cookie-banner {
max-height: 30vh;
overflow: auto;
}Non. Les constats sont des diagnostics et n'empêchent pas un déploiement. Corrigez quand même les plantages, les écrans vides et les constats de sécurité, car un examinateur peut rencontrer les mêmes problèmes.
Les rapports dépendent de la capacité du laboratoire de test et prennent généralement jusqu'à une heure, parfois plusieurs. Si rien n'est apparu au bout de deux jours, importez à nouveau le bundle avec un nouveau code de version pour lancer un nouveau rapport.
Pas pour une connexion web. Google indique que les identifiants de compte de test ne peuvent pas être utilisés quand l'app connecte les utilisateurs via un parcours web dans une WebView, ce qui est le cas normal pour une app encapsulée. Proposez plutôt une zone publique ou de démonstration et ajoutez des liens profonds.
Les plus importants, oui. Des libellés sur les boutons icônes, un contraste lisible et des zones tactiles assez grandes aident les vrais utilisateurs et donnent à l'app un côté natif. Ils se corrigent dans votre code web et passent en ligne sans nouveau build.
En général non. Ils viennent surtout de SDK qui utilisent des API Android cachées et sont informatifs. Garder le modèle WebViewGold et ses SDK à jour est la bonne réponse ; vous n'avez pas besoin de corriger vous-même les bibliothèques.
Les appareils de test couvrent d'autres tailles d'écran et versions d'Android et démarrent toujours avec un profil vierge. Une mise en page qui casse sur un petit téléphone ou une tablette dans le rapport est un vrai problème ; corrigez-la dans votre CSS.
Même résultat, charge de travail différente de votre côté. Les trois formules incluent la garantie d'approbation et le support humain 24/7.
$109 par plateforme, paiement unique
La licence WebViewGold : un projet Xcode ou Android Studio prêt à l'emploi. Collez votre URL, définissez le nom et l'icône, activez les fonctionnalités, compilez et soumettez. Mises à jour gratuites à vie.
Voir les offres sur la page principale$349 par licence, extension en paiement unique
Ni Mac, ni Xcode, ni Android Studio : configurez dans le navigateur, nous compilons les deux apps dans le cloud et les transmettons à App Store Connect et à la Play Console.
Comment fonctionne le Cloud Builder Essayer la démo gratuite$698 par plateforme $798
Envoyez-nous votre URL et votre icône. Notre équipe configure, compile et livre votre app sous 72 heures, en marque blanche, projets sources inclus. Les deux plateformes pour $1,158.
Détails du Full Service Propulsé par
Prix Soldes d'hiver valables jusqu'au 31 décembre 2026.
Garantie d'approbation App Store & Google Play – ou remboursement sous 14 jours
Vous préférez déléguer ? Full Service : nous configurons, compilons et livrons sous 72 heures, dès $698 par plateforme. Des questions ? Chattez avec nous 24/7.
Les remboursements sont accordés aux conditions indiquées dans notre FAQ : un refus non lié au contenu par Apple et/ou Google, demandé dans les 14 jours suivant l'achat.