Tag Archives: audit Google Play Console

Navigation rapide

Navigation rapide

Résumé exécutif

Ce résumé donne une vue immédiate et synthétise ce dossier avec les éléments attendus par un auditeur et un reviewer Google Play, dans une logique d’Android Foreground Service compliance vérifiable, notamment sur Android 16 (API level 36). En effet, Android durcit l’exécution en arrière-plan (background execution) et renforce l’encadrement des services de premier plan (Foreground Services) afin de limiter l’activité invisible en arrière-plan, réduire les abus, et améliorer fiabilité et autonomie. Dans les environnements sensibles, cette contrainte peut sembler pénalisante. Pourtant, lorsqu’il est conçu correctement, un service de premier plan devient l’inverse : un marqueur de confiance qui prouve la transparence, le contrôle utilisateur et un périmètre opérationnel minimal.

Dans l’écosystème Freemindtronic, le service de premier plan sert une fonctionnalité cœur : Connexion PC. Elle permet d’utiliser des dispositifs NFC HSM sur ordinateur via une extension navigateur Freemindtronic (basée sur Chromium), sans installer de logiciel sur le poste. Ce dossier explique pourquoi ce service existe, comment l’utilisateur le maîtrise, et en quoi cette approche transforme une exigence de conformité en avantage concurrentiel.

Service premier plan Android : pourquoi il est devenu un marqueur de sécurité

Un service de premier plan est destiné aux opérations qui doivent rester actives, visibles pour l’utilisateur, et arrêtables à tout moment.
Dans la pratique, il est souvent détourné par des applications qui tentent de rester actives silencieusement, d’automatiser des actions sans intention explicite, ou de maintenir une activité en arrière-plan au-delà du strict nécessaire.

Pour un produit de sécurité, la bonne posture n’est pas de « contourner la règle », mais de s’y aligner : l’utilisateur doit toujours savoir quand une session sensible est active, ce qu’elle fait, et comment l’arrêter instantanément.
Ce point devient critique lorsque le téléphone sert de passerelle entre des modules matériels (NFC HSM) et un environnement navigateur sur ordinateur.

Android : arrière-plan vs Service premier plan Android (Foreground Service)

Android durcit depuis plusieurs versions l’exécution en arrière-plan (background execution) pour limiter l’activité invisible, réduire les abus, et préserver batterie/fiabilité. Dans ce contexte, une fonctionnalité qui doit rester active “sans être au premier plan” doit être justifiée et rendue perceptible. C’est précisément le rôle d’un service de premier plan : rendre l’activité sensible visible (notification), stoppable (STOP), et bornée dans le temps.

• Android 14+ : types de services de premier plan requis et déclarations associées : https://developer.android.com/about/versions/14/changes/fgs-types-required
• Permission manifeste : https://developer.android.com/reference/android/Manifest.permission#FOREGROUND_SERVICE

Threat Model : pourquoi la Connexion PC doit rester visible et bornée

Service premier plan Android : exigences Google Play (sources officielles)

Google Play encadre strictement l’usage des services de premier plan : ils doivent être justifiés par une fonctionnalité cœur bénéfique pour l’utilisateur, être perceptibles à tout moment (notification explicite), et rester arrêtables à la demande. Depuis Android 14, la déclaration d’un type de service de premier plan est obligatoire.

Dans ce dossier, ces exigences sont appliquées à un cas réel et vérifiable (Connexion PC + NFC HSM), en démontrant comment le contrôle utilisateur (notification, STOP, désactivation, granularité) transforme une contrainte de conformité en preuve de maturité sécurité.

Retour d’expérience : validation puis rejet sur la déclaration Foreground Service Connected Device

Ce type de situation n’est pas isolé. Plusieurs développeurs rapportent des cas similaires où une déclaration Foreground Service initialement acceptée est ensuite rejetée lors d’une mise à jour, avec un message ambigu indiquant que le problème peut se situer soit dans la description justificative, soit dans la vidéo, sans préciser lequel des deux est jugé insuffisant.

Un signal de rejet ambigu, documenté par la communauté

• Reddit – r/androiddev : des développeurs décrivent des rejets répétés liés aux Foreground Services, avec des demandes de clarification sans indication précise sur la partie à corriger (texte ou vidéo). Lien : https://www.reddit.com/r/androiddev/comments/1fsuii4/has_anyone_had_repeat_issues_with_app_submission/
• Forum développeurs Zoom : rejet d’une mise à jour Play Store lié à des permissions Foreground Service, avec exigence de vidéo démonstrative jugée insuffamment explicite, sans guidance opérationnelle claire. Lien : https://devforum.zoom.us/t/app-update-rejected-due-to-foreground-service-permissions/103026
• Support Google Play Console : retours de développeurs signalant des rejets pour « information insuffisante » concernant l’usage d’un Foreground Service, sans précision sur le critère exact manquant. Lien : https://support.google.com/googleplay/android-developer/thread/299748806

Pourquoi ce type de rejet est difficile à diagnostiquer

• Absence de granularité : le message de rejet ne précise pas si la non-conformité concerne la description Play Console, la vidéo ou leur cohérence.
• Évolution implicite des attentes reviewer : une justification jugée suffisante à un instant T peut être réévaluée différemment lors d’une mise à jour.
• Critères implicites : Play attend souvent une démonstration encore plus explicite du triptyque user-initiated → perceptible → stoppable, ainsi que de la dépendance fonctionnelle immédiate.

Stratégie de résolution : rendre la justification non équivoque

Face à un rejet générique, la seule approche robuste consiste à supprimer toute ambiguïté d’interprétation.

• Texte Play Console : formuler la justification comme un test vérifiable : « si l’utilisateur appuie sur STOP, la session est interrompue immédiatement et l’extension perd l’accès au NFC HSM ».
• Vidéo : montrer sans coupe l’enchaînement action utilisateur → notification visible → STOP → perte immédiate de session côté extension.
• Alignement sémantique : reprendre explicitement les termes utilisés par Google Play : core feature, user benefit, perceptible, stoppable, cannot be deferred.
• Élimination des malentendus : rappeler explicitement « pas un VPN, pas un proxy, pas de routage, périmètre strictement local ».

Ce retour d’expérience explique pourquoi ce dossier inclut une checklist d’implémentation, un mapping preuves ↔ exigences Google Play et un kit de preuves reproductible : lorsqu’un rejet est formulé de manière générique, la seule réponse efficace reste une démonstration qui ne laisse plus de place à l’interprétation.

Android 14+ — Service premier plan Android (FGS) : type déclaré et justification vérifiable

• Type déclaré : FOREGROUND_SERVICE_CONNECTED_DEVICE
• Fonctionnalité cœur dépendante : Connexion PC (téléphone ↔ extension Chromium)
• Justification : le téléphone agit comme passerelle active vers un dispositif NFC HSM utilisé depuis un ordinateur, sur initiative explicite de l’utilisateur.

Si le service de premier plan est arrêté (bouton STOP dans la notification ou désactivation de l’auto-login), la session Connexion PC est immédiatement interrompue et l’extension navigateur perd l’accès au NFC HSM. La tâche ne peut pas être différée par le système sans empêcher la fonctionnalité attendue.

Référence Android — Types de Foreground Services : https://developer.android.com/develop/background-work/services/fgs/service-types

Continuité Android 15 : Android 15 renforce encore la discipline autour des services de premier plan (démarrage, usage, attentes de comportement) et la cohérence entre action utilisateur, durée d’exécution et finalité. Cette trajectoire confirme le principe “visible, stoppable, borné”, et favorise les implémentations démontrables (notification explicite + STOP + dépendance fonctionnelle immédiate). Référence : https://developer.android.com/about/versions/15/changes/foreground-services

Foreground services — changes (inclut Android 16 / API level 36) (inclut Android 16 / API level 36) : https://developer.android.com/develop/background-work/services/fgs/changes

Cap Android 16 : Android 16 introduit également un cadre de quotas/limites et des considérations opérationnelles (notamment diagnostics et cas d’échec) qui renforcent l’intérêt des workflows local-only, courts et contrôlés, plutôt que des sessions implicites. Référence (diagnostic) : https://developer.android.com/develop/background-work/services/fgs/troubleshooting

Android continue d’outiller le diagnostic et de resserrer les scénarios autorisés ; par conséquent, un workflow local-only, visible et stoppable reste la stratégie la plus robuste face aux durcissements successifs.

Précision de fonctionnement — application Android NFC Freemindtronic : le service de premier plan est strictement événementiel. Le lancement de l’application ne suffit pas à l’activer : il démarre uniquement lorsqu’un tag NFC est présenté, puis reste inactif en l’absence d’événement NFC, sans serveur local ni service persistant.

Impact produit et mitigation (Android 15/16, NFC, BAL et spécificités OEM)

Symptôme

• Symptôme : le tag NFC est correctement détecté par le système, mais la tentative de relance ou de remise au premier plan de l’interface via PendingIntent est bloquée par le mécanisme BAL (Background Activity Launch). L’utilisateur perçoit une absence de réaction, ou un comportement dégradé, alors que l’événement NFC est bien reçu.

Cause

• Cause : Android 15 et plus encore Android 16 durcissent officiellement les règles de lancement d’activités depuis l’arrière-plan. Les PendingIntent créés par l’application ne bénéficient plus implicitement du droit de lancer ou de ramener une activité au premier plan. Ce durcissement impacte directement les parcours NFC historiques reposant sur la relance d’UI via PendingIntent, y compris lorsque l’activité cible est déjà en état RESUMED. Référence officielle Android : https://developer.android.com/guide/components/activities/background-starts

Ce comportement est observable y compris sur Google Pixel (AOSP), confirmant qu’il s’agit d’un changement structurel de la plateforme et non d’une spécificité OEM.

Facteur aggravant NFC (plateforme)

• Facteur aggravant NFC (plateforme) : en parallèle des restrictions BAL, des instabilités et changements de comportement de la pile NFC sont observés sur Android 15 et Android 16, incluant des crashs du service NFC (DeadObjectException), des échecs intermittents de lecture de tags et des différences de comportement entre versions. Ces points sont documentés dans l’Issue Tracker Google, notamment sur Android 16 : https://issuetracker.google.com/issues/456078994

Facteur aggravant NFC (OEM)

• Facteur aggravant NFC (OEM) : la problématique est accentuée sur certains appareils en raison des surcouches constructeur et des politiques d’optimisation agressives. Des retours publics et tickets font état de comportements NFC dégradés ou incohérents sur :
  • Samsung Galaxy (One UI 7/8 – Android 15/16) : suspension agressive des activités, désactivation intermittente du NFC après mise à jour, et différences de comportement entre états écran allumé/éteint.
  • Xiaomi / Redmi / Poco (MIUI / HyperOS – Android 15/16) : restrictions fortes en arrière-plan, interactions entre NFC, Bluetooth et économie d’énergie, entraînant des échecs de scans NFC ou des non-relances d’UI.
  • OnePlus / Oppo (OxygenOS / ColorOS – Android 15/16) : gestion restrictive des tâches en arrière-plan et comportements variables du service NFC selon les builds.
  • Fairphone 5 (Android 15) : régressions signalées après mise à jour, avec reconnaissance incomplète ou retardée de certains tags NFC.
  • Google Pixel (Android 15/16 AOSP) : référence AOSP montrant que le blocage BAL est structurel même sans surcouche OEM, confirmant que le problème n’est pas uniquement constructeur.

Mitigation robuste

• Mitigation robuste : abandonner toute dépendance à une relance implicite d’UI via PendingIntent. Le traitement NFC doit être effectué dans l’instance existante de l’activité lorsque celle-ci est déjà active (launchMode adapté, traitement via onNewIntent()), ou bien être poursuivi via une action explicitement initiée par l’utilisateur (notification avec action), conformément au modèle Android “user-initiated” recommandé pour Android 15+.

Preuve et audit

• Preuve et audit : les journaux système Android permettent d’identifier explicitement les blocages BAL (“Background activity launch blocked” ou messages équivalents) lors d’événements NFC. Ces logs constituent des preuves techniques objectives à archiver dans le kit de conformité interne et à produire en cas de revue Google Play ou d’audit sécurité.

Charge de compatibilité et impacts sur le cycle de mise à jour

Cette section explique pourquoi ces changements ne relèvent pas d’un simple ajustement de code, mais d’une transformation structurelle des workflows Android historiques.

Depuis Android 6, la plateforme a empilé des restrictions successives qui transforment une “simple montée de targetSdk” en refactoring structurel : durcissement de l’exécution en arrière-plan et du lancement d’activités depuis l’arrière-plan (BAL), encadrement des services de premier plan (FGS) et exigences de justification associées, ainsi que variabilité du comportement NFC et de la pile système selon les versions et les implémentations OEM. À partir d’Android 15, une application qui crée des PendingIntent ne bénéficie plus implicitement des privilèges BAL : l’opt-in explicite devient requis, ce qui casse de nombreux workflows historiques (notification → relance UI, flux “événement système → ramener l’activité”, scénarios NFC, etc.).

Dans le même temps, Android 15/16 impose des changements de comportement documentés (targetSdk, compat framework changes), et des tickets publics montrent aussi des instabilités NFC à la plateforme, ce qui augmente la complexité des tests multi-appareils, multiplie les modes dégradés, et ralentit mécaniquement les cycles de publication.

Fonction cœur : Connexion PC pour NFC HSM (extension Chromium)

Cette section décrit concrètement la fonctionnalité cœur qui justifie l’usage d’un service de premier plan, et pourquoi son interruption entraîne immédiatement une perte de capacité opérationnelle.

Concrètement, l’application Android maintient une session locale téléphone ↔ ordinateur afin que l’extension Chromium puisse émettre des requêtes explicitement autorisées vers le téléphone, dans le cadre strict des opérations NFC HSM définies par l’utilisateur. Ensuite, la session s’appuie sur un canal chiffré local reposant sur un protocole à clé segmentée, avec une clé unique par session, afin d’éviter toute réutilisation de secret et de renforcer la résilience aux interceptions réseau locales.

Pour ce faire, le service expose un point de terminaison HTTP local, associé à un port configurable (par défaut 10001). Ce point de terminaison reste exclusivement dédié à la Connexion PC : il ne s’agit ni d’un proxy, ni d’un tunnel réseau, ni d’un service généraliste.

Il est important de souligner que ce mécanisme n’est pas un démon « always-on » en arrière-plan. Au contraire, il s’agit d’une session explicitement perceptible, déclenchée par l’utilisateur, bornée dans le temps, et arrêtable à tout moment. Sa seule finalité consiste à permettre l’usage d’un NFC HSM sur ordinateur via navigateur, sans dépendance cloud et sans infrastructure externe.

Côté ordinateur, cette Connexion PC s’appuie sur la technologie EviDNS Zeroconf, ce qui permet aux extensions Freemindtronic de découvrir automatiquement le téléphone sur le réseau local, d’identifier son adresse IP et son port d’appairage, puis d’établir la session, le tout sans serveur DNS/DHCP dédié et sans exposition hors du périmètre local.

EviDNS Zeroconf : appairage local serverless pour extensions desktop

La technologie EviDNS Zeroconf (serverless) est conçue pour simplifier et sécuriser la configuration réseau en environnement local : elle facilite la découverte de services et l’association entre un ordinateur et un terminal NFC (téléphone) sur le même réseau.

Concrètement, EviDNS permet aux extensions desktop de trouver le téléphone et d’identifier les paramètres nécessaires à la Connexion PC (IP + port). Cette approche améliore la robustesse multi-OS et évite de dépendre d’une infrastructure externe.

• Serverless : aucune dépendance à un serveur DNS/DHCP dédié pour l’appairage local.
• Découverte automatique : identification du terminal NFC sur le réseau local et récupération IP/port pour la session.
• Alignement souverain : l’appairage reste dans le périmètre local de l’utilisateur, sans obligation de cloud pour “tenir” la connexion.

• Référence : https://freemindtronic.com/technology/evidns-zeroconf-serverless-technology/
• Détails “How it works” : https://freemindtronic.com/technology/evidns-serverless-technology-how-it-works-find-connect-nfc-devices/
• Guides techniques : https://freemindtronic.com/support/faq-technical-guides/

Service premier plan Android : contrôles utilisateur (notification, STOP, réglages)

Un service de premier plan est défendable lorsque le contrôle utilisateur est explicite, constant et vérifiable, aussi bien pour l’utilisateur final que pour un auditeur ou un reviewer.

L’auto-connexion peut être activée par défaut afin d’offrir une expérience fluide. Toutefois, elle reste totalement réversible : arrêt immédiat via le bouton STOP dans la notification, et désactivation de l’auto-login (switch avec pictogramme Wi-Fi) dans les paramètres « Extension Freemindtronic ».

La Connexion PC s’appuie sur quatre contrôles concrets qu’un auditeur peut valider en quelques secondes :

Moindre privilège : autorisations granulaires

Beaucoup d’applications considèrent une session persistante comme une capacité sans limites. Freemindtronic adopte l’approche inverse.
La Connexion PC intègre une autorisation granulaire par catégories de requêtes, permettant à l’utilisateur de décider explicitement ce que l’extension a le droit de demander pendant une session active.

Autrement dit : le service de premier plan ne signifie pas « accès étendu ». Il fournit une frontière de session, et l’utilisateur contrôle ce qui peut se produire à l’intérieur de cette frontière.

Preuve clé : contrôle utilisateur total et granulaire (données, alertes, port, arrêt)

Un point décisif l’utilisateur ne subit pas le service de premier plan. Il le contrôle entièrement : notification persistante, arrêt instantané, désactivation dans les paramètres, et autorisation granulaire par type de données.

Actif par défaut, mais jamais imposé

Le service d’auto-connexion peut être actif par défaut à l’installation afin d’assurer une disponibilité immédiate de la Connexion PC. Ce choix d’ergonomie est encadré par des mécanismes d’arrêt et de désactivation accessibles en un geste, ce qui répond au principe : “actif par défaut ≠ permanent ≠ incontrôlable”.

Moindre privilège appliqué au niveau des données

L’un des points les plus rares sur le marché est la capacité à limiter la Connexion PC au strict nécessaire en contrôlant
individuellement chaque type de requête autorisée entre l’extension navigateur et le téléphone.
Cela transforme une session persistante en session bornée par l’utilisateur.

Contrôle des alertes : notifications, vibration, sonnerie

L’utilisateur peut également configurer la manière dont la session est signalée, ce qui renforce la perceptibilité sans imposer une expérience intrusive.

Portée locale : ni proxy, ni VPN, ni routage

« Session locale » n’est pas un argument marketing. C’est un engagement d’architecture.
La Connexion PC est conçue pour réduire le périmètre opérationnel :

• Pas de proxy : l’application n’est pas un proxy HTTP/SOCKS généraliste.
• Pas de VPN : elle ne tunnelise pas le trafic, n’intercepte pas la navigation, ne redirige pas des flux tiers.
• Pas de routage : la fonctionnalité ne relaye pas de trafic distant.
• Pas de dépendance cloud : aucun serveur externe n’est requis pour maintenir la session.

Cela s’inscrit dans le modèle souverain Freemindtronic : pas de compte, pas d’identification, pas de base centrale. Les secrets restent sous contrôle utilisateur et sont conçus pour rester confinés aux dispositifs NFC HSM.

Ce que la Connexion PC ne fait pas

• Ne collecte pas de données utilisateur pour analyse ou profilage.
• Ne transfère pas les secrets vers un serveur distant : la session est conçue pour rester local-only.
• Ne fonctionne pas comme un proxy/VPN : aucune interception générale de trafic.
• Ne reste pas actif “en cachette” : la notification et STOP rendent l’état observable.

Transformer la conformité en avantage concurrentiel

Au-delà du minimum attendu, la Connexion PC applique le moindre privilège au niveau des données via des permissions granulaires par catégorie — une exigence rarement implémentée dans les solutions concurrentes. Les règles des stores obligent désormais les applications de sécurité à documenter et à démontrer leur fonctionnement. Ce n’est pas qu’une formalité : c’est un filtre de maturité.
À terme, les solutions incapables d’expliquer une activité persistante de manière vérifiable s’exposent à :

• des refus de publication et des cycles de revue prolongés,
• des restrictions au niveau du système d’exploitation,
• une érosion de la confiance liée à l’opacité,
• un renforcement de la pression réglementaire sur les usages sensibles.

L’implémentation Freemindtronic rend le service de premier plan mesurable : session visible, arrêt immédiat, auto-login configurable, périmètre local strict.
Cette clarté opérationnelle correspond aux attentes des environnements à forte assurance, et devient un différenciateur quand d’autres solutions reposent sur des comportements flous en arrière-plan.

Transparence vérifiable : téléchargements, signatures, historique des versions

Un marqueur de confiance ne se limite pas à “dire” : il doit permettre de vérifier. Freemindtronic publie des ressources qui facilitent l’audit et la traçabilité logicielle dans le temps.

Cette transparence documentée renforce la crédibilité d’une architecture “local-only” et la capacité à répondre aux exigences de conformité sans dépendre d’un cloud opaque.

Checklist d’implémentation pour auditeurs

• Visible : notification persistante indiquant la session active.
• Arrêtable : action STOP accessible directement depuis la notification.
• Configurable : auto-connexion désactivable dans les paramètres utilisateur (extension : Auto-login).
• Durée minimale : service actif uniquement durant la session Connexion PC.
• Périmètre borné : communication locale ; aucun comportement proxy/VPN/routage.
• Moindre privilège : autorisations granulaires par catégories.
• Transparence opérationnelle : port configurable ; comportement déterministe.

Kit de preuves (review Google Play / audit interne)

Pour éviter les allers-retours, voici les preuves minimales à fournir dans une revue :

• Capture 1 : notification persistante “Service d’auto-connexion active”.
• Capture 2 : bouton STOP visible dans la notification.
• Capture 3 : paramètre “Extension Freemindtronic” avec switch Auto-login + pictogramme Wi-Fi.
• Capture 4 : écran du port (défaut 10001) + nom du téléphone (appairage).
• Capture 5 : exemple de contrôle granulaire (au moins 5 catégories ON/OFF).

Ce kit de preuves est conçu pour répondre explicitement aux attentes d’un Google Play reviewer foreground service, en fournissant des éléments observables, reproductibles et directement alignés sur les exigences officielles.

Audit rapide : vérifier un Service premier plan Android et la portée local-only (2 minutes)

Cette procédure permet à un auditeur (ou à un reviewer) de vérifier rapidement : visibilité, arrêt immédiat, et caractère local-only.

1. Vérifier la perceptibilité : activer la Connexion PC, puis ouvrir le centre de notifications Android et confirmer la présence de la notification persistante.
2. Vérifier l’arrêt : cliquer sur STOP dans la notification ; confirmer que la session s’arrête immédiatement.
3. Vérifier la désactivation : dans les paramètres “Extension Freemindtronic”, désactiver l’auto-login (switch + pictogramme Wi-Fi), puis confirmer l’absence de relance automatique.
4. Vérifier la dépendance fonctionnelle : constater que l’extension navigateur perd la session quand le service s’arrête.
5. Vérifier la portée locale : confirmer que le port (défaut 10001) est un paramètre local et que la session n’implique pas de service cloud pour fonctionner.

Cas d’usage souverain : transparence et continuité opérationnelle

Dans les environnements souverains ou à forte contrainte, le pire scénario n’est pas seulement l’incident : c’est l’impasse opérationnelle provoquée par un outil opaque.
Une fonctionnalité qui dépend silencieusement de l’arrière-plan peut être restreinte par l’OS, puis échouer au moment critique.

En concevant la Connexion PC autour d’un service de premier plan visible, stoppable, configurable et strictement local, l’utilisateur peut prouver — en temps réel — ce qui s’exécute et pourquoi.
Cette transparence rend le système plus résilient face au durcissement des politiques, et réduit le risque d’incompatibilité de dernière minute lors d’un déploiement sensible.

Enfin, lorsqu’un scénario comparable implique des tentatives d’exfiltration, une approche souveraine fondée sur le matériel borne les impacts :
si les secrets restent confinés aux dispositifs NFC HSM et que les opérations demeurent explicitement médiées par l’utilisateur, les données récupérées hors contexte restent inexploitables en clair.

Glossaire

FAQ : Service premier plan Android (Foreground Service)

À relier avec…