Service premier plan Android : conformité Google Play, contrôle utilisateur et Connexion PC NFC HSM via extension Chromium. Ce dossier montre comment une exigence Foreground Service (FGS) devient un marqueur de confiance : session local-only (sans proxy, sans VPN, sans routage), appairage local EviDNS Zeroconf, notification persistante avec bouton STOP, contrôle granulaire des données et audit rapide vérifiable.
Résumé exécutif
Contexte
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, réduire les abus et améliorer fiabilité et autonomie. Sur Android 16 (API level 36), cette exigence devient vérifiable et incontournable. Loin d’être une contrainte pénalisante, un service de premier plan correctement conçu devient un marqueur de confiance : transparence, contrôle utilisateur et périmètre opérationnel minimal.
Objectif
Documenter, de manière vérifiable, l’usage d’un service de premier plan Android comme brique indispensable à une fonctionnalité cœur : Connexion PC. L’objectif est de montrer comment une exigence Google Play devient un marqueur de transparence, de contrôle utilisateur et de maturité sécurité.
Portée
Fonction analysée : Connexion PC (téléphone ↔ ordinateur) pour utiliser des dispositifs NFC HSM via une extension navigateur Freemindtronic basée sur Chromium, sans installer de logiciel sur le poste. Session local-only (pas de proxy, pas de VPN, pas de routage), port configurable (défaut 10001).
Doctrine
Le service n’est pas utilisé pour “rester actif”, mais pour rendre une session sensible visible, stoppable et désactivable : notification persistante, bouton STOP, auto-login réversible, et contrôle granulaire des catégories de données autorisées.
Différenciateur stratégique
Dans un contexte de durcissement Android/Google Play, les solutions opaques deviennent fragiles. Une implémentation démontrable (contrôle utilisateur + périmètre local + transparence) devient un avantage concurrentiel. Ce dossier explique pourquoi ce service existe, comment l’utilisateur le maîtrise, et en quoi cette approche transforme une exigence de conformité en atout stratégique.
À retenir
Le service de premier plan Android est utilisé uniquement pour maintenir une session Connexion PC visible et stoppable (notification persistante + STOP) permettant l’usage d’un NFC HSM sur ordinateur via extension Chromium. L’utilisateur peut désactiver l’auto-login, limiter chaque catégorie de données autorisée, vérifier la portée local-only (pas de proxy/VPN/routage), et auditer la conformité en 2 minutes.
📱 Application Freemindtronic (EviPro) sur Google Play clic ici
Note technique
Temps de lecture (résumé) : ~2 minutes
Temps de lecture (intégral) : ~20–25 minutes
Temps de vérification (audit rapide) : ~2 minutes
Date de publication : 2026-01-16
Dernière mise à jour : 2026-01-20
Niveau : Android / Sécurité / Audit
Posture : Local-only, user-in-control, least privilege
Rubrique : Tech Fixes & Security Solutions
Langues disponibles : FR · EN · CAT · ES
Niveau d’enjeu : 8.4 / 10 — conformité store, transparence logicielle & sécurité des sessions locales
En sécurité mobile et Android ↑ cette note appartient à la rubrique Tech Fixes & Security Solutions et s’inscrit dans l’outillage opérationnel souverain de Freemindtronic (HSM, contrôle utilisateur, architectures local-only, audit).
- Résumé exécutif
- Service premier plan Android : pourquoi il est devenu un marqueur de sécurité
- Threat Model : session mobile ↔ desktop, risques et bornage
- Service premier plan Android : exigences Google Play (sources officielles)
- Android : arrière-plan vs Service premier plan Android (Foreground Service)
- Retour d’expérience : validation puis rejet sur la déclaration Foreground Service Connected Device
- Un signal de rejet ambigu, documenté par la communauté
- Pourquoi ce type de rejet est difficile à diagnostiquer
- Stratégie de résolution : rendre la justification non équivoque
- Android 14+ — Service premier plan Android (FGS) : type déclaré et justification vérifiable
- Impact produit et mitigation (Android 15/16, NFC, BAL et spécificités OEM)
- Charge de compatibilité et impacts sur le cycle de mise à jour
- Fonction cœur : Connexion PC pour NFC HSM (extension Chromium)
- EviDNS Zeroconf : appairage local serverless pour extensions desktop
- Service premier plan Android : contrôles utilisateur (notification, STOP, réglages)
- Moindre privilège : autorisations granulaires
- Preuve clé : contrôle utilisateur total et granulaire (données, alertes, port, arrêt)
- Actif par défaut, mais jamais imposé
- Moindre privilège appliqué au niveau des données
- Contrôle des alertes : notifications, vibration, sonnerie
- Portée locale : ni proxy, ni VPN, ni routage
- Ce que la Connexion PC ne fait pas
- Transformer la conformité en avantage concurrentiel
- Transparence vérifiable : téléchargements, signatures, historique des versions
- Checklist d’implémentation pour auditeurs
- Kit de preuves (review Google Play / audit interne)
- Mapping preuves ↔ exigences Google Play (reviewer)
- Audit rapide : vérifier un Service premier plan Android et la portée local-only (2 minutes)
- Cas d’usage souverain : transparence et continuité opérationnelle
- Glossaire
- FAQ : Service premier plan Android (Foreground Service)
- À relier avec…
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 et 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.
Cette approche s’inscrit dans une “foreground service Android security architecture”, alignée sur les exigences de service de premier plan Android conformité Google Play, où visibilité, arrêt immédiat et périmètre local-only constituent des critères centraux.
Point clé : le bon raisonnement n’est pas « comment rester actif en arrière-plan », mais « comment rendre une dépendance persistante auditable et contrôlable ». Un Foreground Service bien conçu devient ainsi un marqueur de transparence, pas un contournement.
Source officielle Android Developers — types de services de premier plan requis (Android 14+, y compris connectedDevice pour interactions avec des périphériques comme NFC et Bluetooth) :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
Hypothèse réaliste : un téléphone utilisé comme passerelle (mobile ↔ desktop) est une surface d’attaque. Le service de premier plan est ici un mécanisme de contrôle et de preuve (notification + STOP), pas un moyen de persister silencieusement.
| Risque | Exemple | Mesure Freemindtronic |
|---|---|---|
| Persistance invisible | Service actif sans que l’utilisateur le sache | Foreground Service + notification persistante + arrêt immédiat |
| Sur-autorisation | Session ouverte = accès trop large | Contrôle granulaire par type de données (moindre privilège) |
| Élargissement réseau | Proxy/VPN déguisé, routage implicite | Local-only : pas de proxy, pas de VPN, pas de routage |
| Défaillance opérationnelle | OS stoppe le service → rupture de workflow | Session explicitement dépendante du FGS, donc prévisible et vérifiable |
Protection contre les attaques par capture et interception : l’application Freemindtronic applique un verrouillage système des captures d’écran sur l’ensemble des écrans sensibles.
Ce mécanisme empêche toute capture via screenshot, screen recording ou API équivalente, y compris par des malwares résidents.
Les démonstrations et captures fournies à des fins de revue ont été réalisées à partir d’une version de debug dans laquelle cette protection est volontairement désactivée.
De plus, la Connexion PC repose sur un modèle sans contact et sans saisie clavier, ni sur le téléphone ni sur l’ordinateur.
En conséquence, les attaques par keylogger sont structurellement inopérantes, ce qui réduit significativement la surface d’attaque côté poste de travail.
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.
Références officielles Android & Google Play :
- Android 14 — Types de services de premier plan requis : https://developer.android.com/about/versions/14/changes/fgs-types-required
- Android SDK Platforms (inclut Android 16 / API 36) : https://developer.android.com/tools/releases/platforms
- Android Manifest — Permission
FOREGROUND_SERVICE: https://developer.android.com/reference/android/Manifest.permission#FOREGROUND_SERVICE - Google Play Policy — Foreground service requirements : https://support.google.com/googleplay/android-developer/answer/13392821
- Android Developers — Déclarer un Foreground Service (API 34+) : https://developer.android.com/develop/background-work/services/fgs/declare
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
Contexte réel de publication : la déclaration du type FOREGROUND_SERVICE_CONNECTED_DEVICE a été acceptée lors d’une première soumission, avec vidéo démonstrative et description justificative couvrant les exigences Android 14 et Android 15. Toutefois, lors d’une mise à jour fin décembre, la même déclaration a été rejetée avec une demande générique de « précisions supplémentaires », sans indication exploitable sur les nouveaux détails attendus.
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
Exigence Android 14 : justification explicite et vérifiable
Type déclaré et dépendance fonctionnelle immédiate
- 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é de la doctrine sur Android 15
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
Évolutions Android 16 (API level 36) : quotas, diagnostics et limites opérationnelles
Foreground services — changes (inclut Android 16 / API level 36) : https://developer.android.com/develop/background-work/services/fgs/changes
Cap Android 16 : Android 16 introduit un cadre renforcé de quotas, de limites d’exécution et de diagnostics, ce qui favorise les workflows courts, local-only et explicitement contrôlés plutôt que des sessions implicites ou prolongées. 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
Précision de fonctionnement : 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
PendingIntentest 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
PendingIntentcréé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 viaPendingIntent, y compris lorsque l’activité cible est déjà en étatRESUMED. 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.
Preuve technique — blocage BAL (Android 15 / 16)
Sur Android 15 et plus encore Android 16 (API level 36), le blocage du lancement d’activité depuis l’arrière-plan (Background Activity Launch) est un mécanisme structurel de la plateforme, observable directement dans les journaux système.
Extrait Logcat typique (anonymisé) lors d’un événement NFC tentant de relancer l’UI via PendingIntent :
Background activity launch blocked:
pkg=com.freemindtronic.EviPro
reason=background_activity_launch_not_allowed
intent=Intent { act=android.nfc.action.TAG_DISCOVERED ... }
callerApp=ProcessRecord{...}
Ce message confirme que :
- l’événement NFC est bien reçu par le système,
- la tentative de relance d’interface est explicitement bloquée par Android,
- le refus est indépendant de l’application et résulte du durcissement BAL de la plateforme.
Cette preuve permet de distinguer clairement : changement structurel Android ≠ bug applicatif.
- 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 (launchModeadapté, traitement viaonNewIntent()), 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+.
À retenir : à partir d’Android 15, la détection NFC peut fonctionner correctement sans que l’interface utilisateur ne soit relancée. Le blocage Background Activity Launch (BAL) empêche toute relance implicite via PendingIntent. Une implémentation conforme doit donc traiter l’événement dans l’instance existante ou exiger une action explicite de l’utilisateur.
Limites connues / comportements non garantis par Android
- Android ne garantit pas la relance automatique d’une activité UI après un événement système (NFC, intent, PendingIntent), en particulier à partir d’Android 15 (BAL).
- Le comportement exact de la pile NFC peut varier selon la version Android, l’état du système (écran éteint, Doze, restrictions OEM) et les implémentations constructeur.
- La continuité d’une session dépend du respect du modèle user-initiated et du maintien du service de premier plan Android conformité Google Play (notification visible, STOP, durée bornée).
Ces limites sont structurelles à la plateforme Android et ne constituent ni un bug applicatif ni une déviation fonctionnelle.
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é.
Cette dépendance fonctionnelle démontrable constitue un point clé de service de premier plan Android conformité Google Play, tel qu’attendu par les reviewers depuis Android 14+.
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.
Références officielles (Android/Google) :
• Restrictions BAL (Android 15+), opt-in requis pour PendingIntent : https://developer.android.com/guide/components/activities/background-starts
• Android 15 — behavior changes (targeting API 35) : https://developer.android.com/about/versions/15/behavior-changes-15
• Android 15 — compat framework changes (BAL privileges rescind by creator) : https://developer.android.com/about/versions/15/reference/compat-framework-changes
• Android 16 — behavior changes (Android 16 / API level 36) : https://developer.android.com/about/versions/16/behavior-changes-16
• Set up the Android 16 SDK (API 36) : https://developer.android.com/about/versions/16/setup-sdk
• Exigence Google Play target API level (cadence de migration imposée) : https://developer.android.com/google/play/requirements/target-sdk
• Android Developers Blog (Android 15 AOSP) — PendingIntent creators block BAL by default : https://android-developers.googleblog.com/2024/09/android-15-is-released-to-aosp.html
Retours développeurs & tickets publics (problèmes similaires) :
• StackOverflow (BAL hardening Android 15, activité bloquée via PendingIntent) : https://stackoverflow.com/questions/77679032/with-android-15-bal-hardening-this-activity-start-may-be-blocked-if-the-pi-creat
• GitHub (Flutter community — demande support opt-in BAL Android 15+, activité ne se lance plus) : https://github.com/fluttercommunity/plus_plugins/issues/3688
• Reddit (React Native — activity launch bloqué sur Android 15) : https://www.reddit.com/r/reactnative/comments/1k1zpk0/android_15_background_activity_launch_issue/
• Google Issue Tracker (NFC cassé Android 15 Beta 2) : https://issuetracker.google.com/issues/340933949
• Google Issue Tracker (NFC service dead / tentative recover) : https://issuetracker.google.com/issues/341807213
• Google Issue Tracker (Crash NFC DeadObjectException Android 16) : https://issuetracker.google.com/issues/456078994
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.
Session locale téléphone ↔ ordinateur : finalité et bornage
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.
Canal chiffré local : protocole à clé segmentée et clé unique par session
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.
Point de terminaison HTTP local : port configurable et anti-ambiguïté (10001)
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.
Ce point de terminaison est strictement borné à la session (clé unique par session, durée limitée, arrêt immédiat via STOP) et n’a aucune vocation de relais réseau (ni proxy, ni tunnel, ni routage).
Déclenchement user-initiated : visible, stoppable, borné
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.
Point reviewer : le démarrage de la session Connexion PC est strictement user-initiated : sans action explicite de l’utilisateur (activation Connexion PC / usage attendu), aucun service de premier plan n’est maintenu.
Sa seule finalité consiste à permettre l’usage d’un NFC HSM sur ordinateur via navigateur, sans dépendance cloud et sans infrastructure externe.
Découverte locale : EviDNS Zeroconf (serverless)
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.

Scénario sécurisé Freemindtronic — Une requête initiée depuis l’extension Chromium déclenche l’interaction NFC HSM côté téléphone Android. Le secret est lu localement et transmis via un canal chiffré local basé sur un protocole à clé segmentée avec clé unique par session. Aucun serveur externe n’intervient à aucun moment.
Dépendance fonctionnelle démontrable
La fonctionnalité Connexion PC chiffré de bout en bout repose sur une session continue, visible et maîtrisée sur le téléphone Android. Dès que le service de premier plan est interrompu (STOP ou désactivation), l’extension navigateur perd immédiatement la session, rendant l’usage des NFC HSM sur ordinateur indisponible.
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/

Point clé
Côté ordinateur, les extensions Freemindtronic s’appuient sur la technologie EviDNS Zeroconf pour découvrir automatiquement le téléphone sur le réseau local et obtenir son adresse IP et son port d’appairage — sans serveur DNS/DHCP dédié.
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 :
| Contrôle | Où il apparaît | Ce que cela démontre |
|---|---|---|
| Notification persistante | Centre de notifications Android | Session visible ; aucune activité cachée |
| Action STOP | Bouton dans la notification | Arrêt immédiat à la demande (stoppable) |
| Auto-connexion configurable | Paramètres de l’extension (Auto-login + pictogramme Wi-Fi) | « Actif par défaut » ≠ « imposé » ; désactivation simple |
| Port local configurable | Paramètres de l’application (défaut 10001) | Transparence opérationnelle ; périmètre prévisible |
Note importante : lorsque l’utilisateur appuie sur STOP, la notification de service de premier plan et la session associée sont interrompues immédiatement. Par conception, aucun état résiduel n’est maintenu à l’écran, ce qui rend impossible la capture d’un « écran après STOP ». Cette disparition immédiate constitue précisément la preuve du caractère stoppable et non persistant du service.
Cas limite (Android 13+) : si l’utilisateur refuse l’autorisation POST_NOTIFICATIONS, la session ne peut plus être pleinement “perceptible”. Par cohérence avec les exigences Google Play, le parcours doit soit guider l’utilisateur pour réactiver les notifications, soit empêcher l’activation d’une session Connexion PC non visible.
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.
| Paramètre (exemple) | Objet | Rationale sécurité |
|---|---|---|
| isLogIn (identifiants) | Autoriser les requêtes d’identifiants | Réduit l’exposition si non nécessaire au workflow |
| isLogWeb (web) | Autoriser les requêtes web | Sépare navigation et gestion de secrets |
| isLogCard (cartes) | Autoriser les requêtes cartes | Garde sous contrôle une catégorie à forte valeur |
| isLogCryptoMain / isLogCrypto (crypto) | Autoriser les requêtes cryptomonnaies | Réduit la surface de risque pour les actifs |
| isLogBip39 (seed) | Autoriser les requêtes BIP39 / seed | Garde un verrou explicite sur la classe la plus sensible |
| isLogCipher (clés) | Autoriser les requêtes de clés de chiffrement | Segmente la manipulation des clés |
| isLogPing (connexion) | Autoriser les pings | Contrôle et diagnostic transparents |
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”.
| Preuve observable | Où | Ce que cela démontre |
|---|---|---|
| Notification persistante “Service d’auto-connexion active” | Téléphone (barre d’état Android) | Session perceptible ; transparence |
| Bouton STOP (action d’arrêt) | Notification Android | Arrêt immédiat par l’utilisateur (stoppable) |
| Switch “Auto-login” (picto Wi-Fi) | Paramètres utilisateur > “Extension Freemindtronic” | Désactivation simple du démarrage automatique |
| Port HTTP configurable (défaut 10001) | Paramètres de service | Périmètre local explicite ; diagnostic clair |
| Nom du téléphone personnalisable | Paramètres d’appairage | Traçabilité locale et maîtrise de l’association |
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.
| Paramètre | Type de données / usage | Contrôle |
|---|---|---|
| isLogIn | Requêtes d’identifiants | ON / OFF |
| isLogWeb | Requêtes via extension web | ON / OFF |
| isLogInAdd | Ajout de nouveaux comptes | ON / OFF |
| isLogCard | Requêtes cartes de crédit | ON / OFF |
| isLogWebCard | Cartes via extension web | ON / OFF |
| isLogCryptoMain | Requêtes cryptomonnaies | ON / OFF |
| isLogCrypto | Données crypto détaillées | ON / OFF |
| isLogIOTA | Informations IOTA | ON / OFF |
| isLogBank | Requêtes comptes bancaires | ON / OFF |
| isLogBip39 | Seed phrases BIP39 | ON / OFF |
| isLogPhone | Numéros de téléphone | ON / OFF |
| isLogNote | Notes sécurisées | ON / OFF |
| isLogCipher | Clés de chiffrement (AES) | ON / OFF |
| isLogCloud | Données cloud (si applicable) | ON / OFF |
| isLogPing | Ping de connexion | ON / OFF |
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.
| Paramètre | Fonction |
|---|---|
| isLogPingNotification | Notification lors d’un ping |
| isLogVibrate | Vibration lors des requêtes |
| isLogRing | Sonnerie lors des requêtes |
Pourquoi c’est structurant : un service de premier plan conforme n’est pas seulement “visible”.
Il doit être arrêtable, désactivable, et idéalement borné en droits.
Ici, l’utilisateur garde la main sur la session et sur chaque classe de données exposée à l’extension.
À retenir : le service de premier plan ne confère aucun accès étendu par défaut. Il matérialise une frontière de session visible et stoppable, à l’intérieur de laquelle chaque catégorie de données reste explicitement contrôlée par l’utilisateur. Cette approche combine visibilité, contrôle utilisateur et réduction mesurable de la surface d’attaque, notamment via l’absence de saisie clavier et le verrouillage des captures d’écran.
Portée locale : ni proxy, ni VPN, ni routage
« Session locale » n’est pas un argument marketing. C’est un engagement d’architecture mesurable et vérifiable.
L’illustration ci-dessous montre un point clé de cette transparence : le port de communication utilisé pour l’échange entre le téléphone Android et l’extension navigateur Freemindtronic est explicitement configurable par l’utilisateur (10001 par défaut).
Ce choix volontaire permet à l’utilisateur, à un auditeur ou à un reviewer Google Play de vérifier immédiatement que la Connexion PC repose sur un périmètre réseau borné, local et non ambigu. Il démontre que le service de premier plan ne masque aucun comportement de tunnel, de relais générique ou de redirection réseau implicite.
La Connexion PC est conçue pour réduire strictement le périmètre opérationnel :
- Pas de proxy : l’application n’est pas un proxy HTTP/SOCKS généraliste et ne relaie pas des flux tiers.
- Pas de VPN : elle ne crée aucun tunnel réseau, n’intercepte pas la navigation et n’implémente pas de
VpnService. - Pas de routage : la fonctionnalité ne redirige pas de trafic distant et ne sert pas de passerelle réseau.
- Port explicite et configurable : le port d’échange (10001 par défaut) est visible, modifiable et limité à la Connexion PC.
- Pas de dépendance cloud : aucun serveur externe n’est requis pour maintenir la session.
Ce bornage réseau explicite s’inscrit dans le modèle souverain Freemindtronic : pas de compte, pas d’identification, pas de base centrale. Les échanges restent confinés au réseau local de l’utilisateur, et les secrets demeurent sous contrôle utilisateur, protégés par les dispositifs NFC HSM.
À retenir : la possibilité de modifier le port n’est pas un détail d’implémentation. C’est une preuve que la Connexion PC ne fonctionne ni comme un proxy, ni comme un VPN, mais comme une session locale, visible et auditabile, rendue possible par un service de premier plan Android strictement borné.
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.
| Approche | Visible (notification) | Arrêt immédiat | Granularité par type de données | Portée locale | Dépendance cloud |
|---|---|---|---|---|---|
| Freemindtronic (Connexion PC) | Oui | Oui (STOP + désactivation auto-login) | Oui (par catégorie) | Oui (local-only) | Non |
| Approche “background” (générique) | Souvent non | Souvent non | Rarement | Variable | Souvent oui |
| Approche “cloud-first” | Variable | Variable | Variable | Non (dépend réseau) | Oui |
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.
| Ressource | Ce que cela apporte | Lien |
|---|---|---|
| Téléchargements officiels | Accès direct aux logiciels, informations de version, empreintes (MD5/SHA256 selon les pages) : transparence et vérification reproductible | https://freemindtronic.com/support/download/ |
| Historique des versions | Traçabilité des évolutions dans le temps (audit interne, conformité, justification des changements) | https://freemindtronic.com/version-history-of-software-freemindtronic-andorra/ |
| Guides techniques (FAQ) | Procédures, repères IP/port, explications d’architecture (support et audit) | https://freemindtronic.com/support/faq-technical-guides/ |
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
Les points suivants sont vérifiables rapidement par un reviewer, un auditeur ou une équipe sécurité.
Cette checklist sert aussi de guide pratique à toute solution qui doit justifier un service de premier plan dans un contexte sensible.
- 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.
Ce que Google Play peut vérifier sans analyser le code
- Présence d’une notification persistante lors de l’usage Connexion PC
- Arrêt immédiat du service via STOP (sans état résiduel)
- Perte instantanée de session côté extension navigateur
- Absence de déclaration
VpnService - Port local explicite (10001 par défaut, configurable)
Ces éléments suffisent à établir la conformité FGS sans inspection du code source.
Ce que l’auditeur ne verra PAS
- Pas de code source à analyser pour comprendre le comportement.
- Pas de serveur distant, pas de cloud, pas d’API tierce impliquée.
- Pas de tunnel réseau, pas de VPN, pas de proxy implicite.
- Pas d’activité persistante invisible après STOP.
- Aucune capture d’écran possible sur les écrans sensibles en version de production (verrouillage système des screenshots).
- Aucune saisie clavier lors de l’utilisation de la Connexion PC (téléphone et ordinateur), rendant les keyloggers inopérants.
Plan vidéo (60–90 s) : activer Connexion PC → montrer notification → STOP → relancer → désactiver Auto-login → constater absence de redémarrage → montrer port 10001 → démontrer perte de session côté extension quand STOP.
Service premier plan Android : mapping preuves ↔ exigences Google Play (reviewer)
| Exigence Google Play | Preuve fournie | Ce que le reviewer vérifie |
|---|---|---|
| Fonctionnalité cœur bénéfique | Démonstration “Connexion PC” (extension ↔ téléphone) | Le service est indispensable au workflow principal |
| Perceptible à tout moment | Notification persistante | Aucune exécution “cachée” |
| Arrêtable à la demande | Bouton STOP dans la notification | Arrêt immédiat sans friction |
| Ne peut pas être différé sans casse UX | Perte immédiate de session côté extension quand STOP | Dépendance fonctionnelle démontrable |
| Durée minimale / bornée | Service actif uniquement durant la session Connexion PC | Pas de persistance hors besoin |
- Politique Google Play (FGS requirements) : https://support.google.com/googleplay/android-developer/answer/13392821
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.
- Vérifier la perceptibilité : activer la Connexion PC, puis ouvrir le centre de notifications Android et confirmer la présence de la notification persistante.
- Vérifier l’arrêt : cliquer sur STOP dans la notification ; confirmer que la session s’arrête immédiatement.
- 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.
- Vérifier la dépendance fonctionnelle : constater que l’extension navigateur perd la session quand le service s’arrête.
- 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.
Astuce : côté extension, la découverte automatique du téléphone (IP + port) peut s’appuyer sur EviDNS Zeroconf (serverless), ce qui facilite l’appairage local sans infrastructure dédiée.
Références : https://freemindtronic.com/technology/evidns-zeroconf-serverless-technology/ et https://freemindtronic.com/support/faq-technical-guides/
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.
Note : la Connexion PC ne dépend ni de Play Integrity API, ni de SafetyNet pour fonctionner. La conformité repose sur des mécanismes observables (notification, STOP, périmètre local), et non sur une attestation distante ou opaque.
Glossaire
Type de service de premier plan (FGS type)
Foreground service type API 34+
Déclaration Foreground Service dans Play Console
FGS declaration + vidéo reviewer
Permission Foreground Service
FOREGROUND_SERVICE_* permissions
Notification de service de premier plan
Notification persistante + contrôle immédiat
POST_NOTIFICATIONS
Permission notifications Android 13+
shortService / systemExempted
Exceptions FGS (cas particuliers)
Dépendance fonctionnelle démontrable
Test immédiat (preuve STOP)
FAQ : Service premier plan Android (Foreground Service)
Pourquoi faut-il déclarer le FGS dans Play Console, et pas seulement dans le manifeste ?
Exigences reviewer Google Play : description, impacts, vidéo
Pourquoi choisir CONNECTED_DEVICE, et pas REMOTE_MESSAGING, pour la Connexion PC ?
Justification de type : NFC HSM + passerelle locale
Le service de premier plan transforme-t-il l’application en proxy, en VPN ou en relais réseau ?
Non : périmètre local-only, et contrôle utilisateur
Que change Android 15 pour les Foreground Services dans un workflow sécurité ?
Durée, cohérence action utilisateur, STOP immédiat
Si Android refuse ou coupe le service, comment diagnostiquer sans “bricoler” l’arrière-plan ?
Troubleshooting FGS : comprendre les refus et corriger proprement
Que doit montrer la vidéo Play Console pour valider un Foreground Service ?
Déclenchement utilisateur, notification, STOP, impact immédiat
Si l’utilisateur bloque les notifications, la session Connexion PC reste-t-elle conforme ?
Perceptible signifie aussi “pilotable”
Pourquoi Google insiste sur “user-initiated” pour un Foreground Service ?
La session démarre parce que l’utilisateur la veut
Si Android refuse le démarrage du service (Start not allowed), que faire sans contourner l’arrière-plan ?
Diagnostiquer proprement, puis corriger type, permission, scénario
Qu’est-ce qu’un service de premier plan sur Android ?
Définition officielle et rôle de sécurité
Un service de premier plan Android (Foreground Service) est un composant conçu pour exécuter une tâche que l’utilisateur doit voir, comprendre et pouvoir arrêter. Il s’accompagne obligatoirement d’une notification persistante indiquant l’activité en cours. Ce modèle vise à empêcher toute exécution sensible cachée en arrière-plan et constitue aujourd’hui un marqueur de transparence et de sécurité.
Référence officielle : https://developer.android.com/develop/background-work/services/foreground-services
Comment démarrer un service de premier plan sur Android ?
Démarrage user-initiated et notification immédiate
Un service de premier plan doit être démarré dans un scénario strictement user-initiated. L’utilisateur déclenche une fonctionnalité cœur (par exemple la Connexion PC), puis l’application démarre le service et affiche immédiatement la notification persistante. Depuis Android 14+, l’application doit également déclarer un type de service cohérent et, lorsque requis, la permission associée.
Référence officielle : https://developer.android.com/develop/background-work/services/fgs/declare
Pourquoi un service de premier plan doit-il afficher une notification ?
Perceptibilité, contrôle utilisateur et auditabilité
La notification n’est pas un détail d’interface : elle est le mécanisme central de contrôle utilisateur. Elle rend la tâche perceptible, permet un arrêt immédiat (ex. bouton STOP) et empêche toute activité invisible. Pour Google Play et Android, une tâche sensible sans notification est assimilée à une exécution cachée, donc non conforme.
Référence officielle : https://support.google.com/googleplay/android-developer/answer/13392821
Comment supprimer les notifications de service de premier plan sur Android ?
Arrêter le service plutôt que masquer l’état
Il n’est pas conforme de masquer durablement la notification d’un service de premier plan tant que celui-ci est actif. La seule manière correcte de faire disparaître la notification est d’arrêter le service. Si l’utilisateur bloque les notifications au niveau système (Android 13+), l’application doit éviter de maintenir une session non perceptible ou guider l’utilisateur pour rétablir l’affichage.
Référence officielle : https://developer.android.com/develop/background-work/services/foreground-services
À relier avec…
- Catégorie Tech Fixes & Security Solutions :
https://freemindtronic.com/tech-fixes-security-solutions/ - Catégorie Technical News :
https://freemindtronic.com/news/technical-news/ - Catégorie Digital Security :
https://freemindtronic.com/news/digital-security/ - Technologie EviDNS Zeroconf (serverless) :
https://freemindtronic.com/technology/evidns-zeroconf-serverless-technology/ - EviDNS : How it works (découverte IP/port) :
https://freemindtronic.com/technology/evidns-serverless-technology-how-it-works-find-connect-nfc-devices/ - FAQ guides techniques (EviDNS / IP + port) :
https://freemindtronic.com/support/faq-technical-guides/ - Téléchargements officiels (hash MD5/SHA256) :
https://freemindtronic.com/support/download/ - Historique des versions (traçabilité) :
https://freemindtronic.com/version-history-of-software-freemindtronic-andorra/ - Technologies Freemindtronic (vue d’ensemble) :
https://freemindtronic.com/technology/ - Freemindtronic (présentation) :
https://freemindtronic.com/freemindtronic/ - Transparence & traçabilité — https://freemindtronic.com/support/download/
- Historique des versions : https://freemindtronic.com/version-history-of-software-freemindtronic-andorra/
- Application concernée — Freemindtronic (EviPro) sur Google Play : https://play.google.com/store/apps/details?id=com.freemindtronic.EviPro












































