Tag Archives: EvIDns ZeroConf

Android foreground service: why it has become a security marker

A foreground service is designed for operations that must remain active, visible to the user, and stoppable at any time.
In practice, it is often misused by applications that try to remain active silently, automate actions without explicit user intent, or extend background activity beyond what is strictly required.

For a security product, the correct posture is not to “work around the rule”, but to align with it.
The user must always know when a sensitive session is active, what it is doing, and how to stop it immediately.
This requirement becomes critical when the phone acts as a gateway between hardware modules (NFC HSM) and a desktop browser environment.

Android: background execution vs foreground service

Across recent Android versions, background execution has been progressively restricted.
The objective is clear: limit invisible activity, reduce abuse, and preserve battery life and system reliability.
In this context, any feature that must remain active without being in the foreground must be justified and made perceptible.

This is precisely the role of a foreground service.
It makes sensitive activity visible (notification), stoppable (STOP), and explicitly bounded in time.

This approach follows a foreground service Android security architecture, aligned with Android foreground service compliance and Google Play requirements.
Here, visibility, immediate shutdown, and a strictly local-only scope are central criteria.

• Manifest permission:
  
  https://developer.android.com/reference/android/Manifest.permission#FOREGROUND_SERVICE
  

Threat model: why the PC Connection must remain visible and bounded

Android foreground service: Google Play requirements (official sources)

Google Play strictly governs foreground services. They must be justified by a core, user-beneficial feature. In addition, they must remain perceptible at all times through an explicit notification. Finally, they must be stoppable on demand. Since Android 14, declaring an explicit foreground service type is mandatory.

In this dossier, these requirements are applied to a real, verifiable case (PC Connection + NFC HSM). As a result, the user-in-control model (notification, STOP, opt-out, granular controls) turns a compliance constraint into evidence of security maturity.

Field feedback: approval, then rejection, of the Foreground Service Connected Device declaration

This situation is not isolated. Moreover, multiple developers report similar cases. In those reports, a previously accepted foreground service declaration is later rejected during an update. The rejection message can be ambiguous. Specifically, it may suggest the issue is either the justification text or the video, without stating which part is insufficient.

An ambiguous rejection signal, documented by the community

• Reddit – r/androiddev: developers describe repeated foreground-service-related rejections, with clarification requests that do not identify what to fix (text or video). Link: https://www.reddit.com/r/androiddev/comments/1fsuii4/has_anyone_had_repeat_issues_with_app_submission/
• Zoom developer forum: Play Store update rejection tied to foreground service permissions, with a demo video deemed insufficiently explicit and limited operational guidance. Link: https://devforum.zoom.us/t/app-update-rejected-due-to-foreground-service-permissions/103026
• Google Play Console support thread: developers report rejections for “insufficient information” about foreground service usage, without clarity on the missing criterion. Link: https://support.google.com/googleplay/android-developer/thread/299748806

Why this type of rejection is difficult to diagnose

• Lack of granularity: the rejection message does not state whether the issue is the Play Console justification, the video, or their consistency.
• Implicit reviewer expectation changes: what is “sufficient” at time T can be evaluated differently during a later update.
• Implicit criteria: Play often expects an even more explicit demonstration of the trio user-initiated → perceptible → stoppable, as well as immediate functional dependency.

Resolution strategy: making the justification unambiguous

When a rejection is generic, the only robust approach is to remove all room for interpretation.

• Play Console text: phrase the justification as a verifiable test: “if the user presses STOP, the session ends immediately and the extension loses NFC HSM access within the same second.”
• Video: show, without cuts, the full sequence: user action → visible notification → STOP → immediate session loss on the extension side.
• Semantic alignment: explicitly reuse Google Play terms: core feature, user benefit, perceptible, stoppable, cannot be deferred.
• Remove misunderstandings: explicitly restate “not a VPN, not a proxy, no routing, strictly local scope.”

This field feedback explains why this dossier includes an implementation checklist, an evidence ↔ Google Play requirements mapping, and a reproducible evidence pack. In short, when a rejection is generic, the only effective response is a demonstration that no longer depends on interpretation.

Android 14+ — foreground service (FGS): declared type and verifiable justification

Declared type and immediate functional dependency

• Declared type: FOREGROUND_SERVICE_CONNECTED_DEVICE
• Dependent core feature: PC Connection (phone ↔ Chromium extension)
• Justification: the phone acts as an active gateway to an NFC HSM device used from a computer, initiated explicitly by the user.

If the foreground service is stopped (via the STOP action in the notification or by disabling auto-login), the PC Connection session is immediately terminated, and the browser extension loses NFC HSM access. Therefore, the task cannot be deferred by the system without breaking the expected feature. Android reference — Foreground Service types: https://developer.android.com/develop/background-work/services/fgs/service-types

Android 15: continuity of the doctrine

It further tightens discipline around foreground services (startup, usage, behavioral expectations) and the consistency between user action, runtime duration, and purpose. Consequently, the trajectory confirms the “visible, stoppable, bounded” principle. It also favors demonstrable implementations (explicit notification + STOP + immediate functional dependency). Reference: https://developer.android.com/about/versions/15/changes/foreground-services

Android 16 (API level 36): quotas, diagnostics, operational limits

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

Android 16 cap: Android 16 introduces a stricter framework of quotas, execution limits, and diagnostics. As a result, it favors short, local-only, explicitly user-controlled workflows over implicit or prolonged sessions. Diagnostic reference: https://developer.android.com/develop/background-work/services/fgs/troubleshooting

Android continues to improve diagnostics and reduce allowed scenarios. Therefore, a local-only workflow that is visible and stoppable remains the most robust strategy across successive hardening waves.

Operational detail — Freemindtronic Android NFC app

Operational detail: the foreground service is strictly event-driven. Launching the app is not enough to activate it. Instead, it starts only when an NFC tag is presented. Then, it remains inactive in the absence of NFC events, with no local server and no always-on service.

Product impact and mitigation (Android 15/16, NFC, BAL, OEM specifics)

Symptom

• Symptom: the NFC tag is correctly detected by the system, yet the attempt to relaunch or bring the UI to the foreground via PendingIntent is blocked by BAL (Background Activity Launch). Consequently, the user perceives no reaction, or degraded behavior, even though the NFC event is received.

Cause

• Cause: Android 15, and even more Android 16, formally harden the rules for starting activities from the background. In particular, PendingIntent objects created by the app no longer implicitly carry the right to start or resume an activity in the foreground. This change directly impacts legacy NFC flows that relied on UI relaunch via PendingIntent, including when the target activity is already RESUMED. Official Android reference: https://developer.android.com/guide/components/activities/background-starts

This behavior is observable even on Google Pixel (AOSP). Therefore, it confirms a structural platform change rather than an OEM-specific behavior.

Background activity launch blocked: pkg=com.freemindtronic.EviPro reason=background_activity_launch_not_allowed intent=Intent { act=android.nfc.action.TAG_DISCOVERED ... } callerApp=ProcessRecord{...}

• Additional NFC risk (platform): alongside BAL restrictions, NFC stack instabilities and behavior changes are observed on Android 15 and Android 16. They include NFC service crashes (DeadObjectException), intermittent tag read failures, and version-dependent differences. These items are documented in Google Issue Tracker, including Android 16: https://issuetracker.google.com/issues/456078994

Additional NFC risk (OEM)

• Additional NFC risk (OEM): the issue is amplified on some devices due to manufacturer overlays and aggressive power optimizations. Public feedback and tickets report degraded or inconsistent NFC behavior on:
  • Samsung Galaxy (One UI 7/8 – Android 15/16): aggressive activity suspension, intermittent NFC disablement after updates, and behavioral differences between screen-on and screen-off states.
  • Xiaomi / Redmi / Poco (MIUI / HyperOS – Android 15/16): strong background restrictions, interactions between NFC, Bluetooth, and power saving, causing NFC scan failures or missing UI resumes.
  • OnePlus / Oppo (OxygenOS / ColorOS – Android 15/16): restrictive background task handling and NFC service variability across builds.
  • Fairphone 5 (Android 15): regressions reported after updates, with incomplete or delayed recognition of certain NFC tags.
  • Google Pixel (Android 15/16 AOSP): AOSP reference showing BAL is structural even without an OEM overlay, confirming it is not only a manufacturer issue.

Robust mitigation

• Robust mitigation: remove any dependency on implicit UI relaunch via PendingIntent. Instead, NFC processing must run inside the existing activity instance when it is already active (appropriate launchMode, handle events through onNewIntent()). Alternatively, continue the flow through an explicit user-initiated action (notification action), in line with the Android “user-initiated” model recommended for Android 15+.

Evidence and audit

• Evidence and audit: Android system logs explicitly reveal BAL blocks (“Background activity launch blocked” or equivalent messages) during NFC events. These logs are objective technical evidence. As a result, they should be archived in the internal compliance evidence pack and produced during Google Play review or security audits when needed.

This demonstrable functional dependency is a key element of Android foreground service Google Play compliance, as expected by reviewers since Android 14+.

Compatibility burden and update cycle impact

This section explains why these changes are not a minor code tweak, but a structural transformation of legacy Android workflows.

Since Android 6, the platform has stacked successive restrictions. Consequently, a “simple targetSdk upgrade” can become a structural refactor. The stack includes: background execution hardening, BAL restrictions on activity starts, stricter FGS governance with justification requirements, and NFC variability across versions and OEM implementations.
Starting with Android 15, apps that create PendingIntent objects no longer implicitly inherit BAL privileges. Therefore, explicit opt-in becomes required, which breaks many legacy workflows (notification → UI resume, “system event → bring activity to front”, NFC scenarios, etc.).

At the same time, Android 15/16 introduce documented behavior changes (targetSdk and compat framework changes). In addition, public tickets also show platform-level NFC instabilities. As a result, multi-device testing becomes more complex, degraded modes multiply, and release cycles slow down mechanically.

Core feature: PC Connection for NFC HSM (Chromium extension)

This section ties the foreground service to a core workflow. It also clarifies what breaks when the service stops.

Local phone ↔ desktop session: purpose and bounded scope

In practice, the Android app opens a local phone ↔ desktop session. Through this session, the Chromium-based extension sends explicitly authorized requests to the phone. Consequently, operations stay limited to NFC HSM actions defined by the user.

Local encrypted channel: segmented-key protocol and per-session unique key

Next, the session uses a local encrypted channel. It applies a segmented-key protocol and generates a unique key per session. As a result, the design avoids secret reuse and improves resilience against local interception.

Local HTTP endpoint: configurable port and anti-ambiguity (10001)

To support desktop calls, the service exposes a local HTTP endpoint on a configurable port (default: 10001). Therefore, the endpoint serves one purpose only: PC Connection. It does not act as a proxy, a tunnel, or a generic network relay.

Moreover, the endpoint remains session-bounded (unique per-session key, limited duration, immediate STOP). Accordingly, it provides no routing capability (no proxy, no tunnel, no routing).

User-initiated trigger: visible, stoppable, bounded

Importantly, the app does not run an “always-on” background daemon. Instead, the user triggers a perceptible session that stays time-bounded and stoppable at any moment.

Reviewer point: the user starts the PC Connection session explicitly. Without an explicit user action (PC Connection activation / expected usage), the app does not keep a foreground service running.

Finally, the workflow enables NFC HSM usage from a desktop browser without cloud dependency and without external infrastructure.

Local discovery: EviDNS Zeroconf (serverless)

On the desktop side, PC Connection relies on EviDNS Zeroconf. As a result, Freemindtronic extensions discover the phone automatically on the local network. They also retrieve its IP address and pairing port. Meanwhile, the process stays fully local: it requires no dedicated DNS/DHCP server and exposes nothing beyond the local perimeter.

EviDNS Zeroconf: serverless local pairing for desktop extensions

EviDNS Zeroconf (serverless) simplifies and secures local setup. Specifically, it supports service discovery and pairing between a desktop computer and an NFC terminal (phone) on the same network.

In practical terms, EviDNS lets desktop extensions locate the phone and retrieve the parameters required for PC Connection (IP + port). Therefore, it improves multi-OS robustness. Additionally, it removes any dependency on external infrastructure.

• Serverless: the local pairing does not rely on a dedicated DNS/DHCP server.
• Automatic discovery: the extension identifies the NFC terminal on the local network and collects IP/port for the session.
• Sovereign alignment: pairing stays within the user’s local perimeter, so the workflow does not need cloud to “keep” the connection.

• Reference: https://freemindtronic.com/technology/evidns-zeroconf-serverless-technology/
• “How it works” details: https://freemindtronic.com/technology/evidns-serverless-technology-how-it-works-find-connect-nfc-devices/
• Technical guides: https://freemindtronic.com/support/faq-technical-guides/

Android foreground service: user controls (notification, STOP, settings)

A foreground service remains defensible only when user control is explicit, continuous, and verifiable.
This applies not only to the end user, but also to auditors and Google Play reviewers.

In practice, auto-connection may be enabled by default to preserve a smooth experience.
However, the user always retains full control.
At any time, the session can be stopped immediately through the STOP action in the notification.
In addition, the user can disable auto-login using a dedicated switch (Wi-Fi icon) in the “Freemindtronic Extension” settings.

PC Connection relies on four concrete controls that an auditor can validate within seconds:

Important note: when the user presses STOP, both the foreground service notification and the associated session terminate immediately.
By design, the system retains no residual UI state.
As a result, capturing an “after STOP” screen is impossible.
This immediate disappearance is precisely the proof that the service is stoppable and non-persistent.

Key proof: full and granular user control (data, alerts, port, shutdown)

One decisive point stands out: the user does not endure the foreground service.
Instead, the user controls it entirely.
This control remains observable through a persistent notification, an immediate STOP action, explicit deactivation options, and fine-grained authorization by data category.

Enabled by default, but never enforced

At installation, the auto-connection service may be enabled by default to ensure immediate availability of PC Connection.
However, this usability choice remains strictly bounded.
At any moment, the user can stop the session or disable automatic startup with a single action.
As a result, the principle remains clear: “enabled by default ≠ permanent ≠ uncontrollable.”

Least privilege enforced at the data level

One of the rare differentiators lies in the ability to restrict PC Connection to what is strictly required.
Each request category between the browser extension and the phone remains individually controlled.
Consequently, a persistent session becomes a user-bounded session rather than an open channel.

Alert control: notifications, vibration, ringtone

In addition, the user can configure how the session signals activity.
This flexibility improves perceptibility while avoiding intrusive behavior.

Local network scope: no proxy, no VPN, no routing

A “local session” is not a marketing claim.
Rather, it represents a measurable and verifiable architectural commitment.

The illustration below highlights a critical transparency point:
the communication port used between the Android phone and the Freemindtronic browser extension is explicitly configurable by the user (default: 10001).

This deliberate choice allows users, auditors, and Google Play reviewers to verify immediately that PC Connection operates within a bounded and unambiguous local network scope.
Accordingly, the foreground service does not conceal any tunneling behavior, generic relay, or implicit traffic redirection.

PC Connection deliberately reduces its operational perimeter:

• No proxy: the application does not function as a generic HTTP or SOCKS proxy and does not relay third-party traffic.
• No VPN: it creates no network tunnel, does not intercept browsing activity, and does not implement VpnService.
• No routing: the feature does not redirect remote traffic or act as a network gateway.
• Explicit, configurable port: the exchange port (default 10001) remains visible, modifiable, and limited to PC Connection.
• No cloud dependency: no external server is required to maintain the session.

This explicit network bounding aligns with the Freemindtronic sovereign model:
no account, no user identification, and no central database.
All exchanges remain confined to the user’s local network, while secrets stay under user control and protected by NFC HSM devices.

Key point: port configurability is not an implementation detail.
Instead, it proves that PC Connection operates neither as a proxy nor as a VPN, but as a visible, auditable, local session enabled by a strictly bounded Android foreground service.

What the PC Connection does not do

• It does not collect user data for analytics or profiling purposes.
• It does not transfer secrets to any remote server; the session is designed to remain local-only.
• It does not operate as a proxy or a VPN and performs no generic traffic interception.
• It does not run silently in the background; the notification and STOP action make the state observable at all times.

Turning compliance into a competitive advantage

Beyond baseline requirements, PC Connection applies least privilege at the data level through per-category granular permissions.
Few competing solutions implement this level of control.
Meanwhile, store policies now require security applications to document and demonstrate their behavior.
This obligation is not a formality; instead, it acts as a maturity filter.

Over time, solutions that cannot explain a persistent activity in a verifiable way expose themselves to:

• publication rejections and prolonged review cycles,
• operating system–level restrictions,
• loss of trust caused by opaque behavior,
• increased regulatory pressure on sensitive use cases.

By contrast, the Freemindtronic implementation makes the foreground service measurable.
The session remains visible, stoppable immediately, configurable through auto-login settings, and strictly bounded to a local scope.
As a result, this operational clarity aligns with high-assurance environments.
It also becomes a differentiator when other solutions rely on ambiguous background behavior.

Verifiable transparency: downloads, signatures, version history

A trust marker does not rely on statements alone.
Instead, it must allow independent verification.
For this reason, Freemindtronic publishes resources that support auditability and long-term software traceability.

This documented transparency reinforces the credibility of a “local-only” architecture.
It also strengthens the ability to meet compliance requirements without relying on an opaque cloud layer.

Implementation checklist for auditors

• Visible: a persistent notification clearly indicates an active session.
• Stoppable: a STOP action is directly accessible from the notification.
• Configurable: auto-connection can be disabled in user settings (extension: Auto-login).
• Minimal duration: the service runs only during the PC Connection session.
• Bounded scope: communication remains local; no proxy, VPN, or routing behavior.
• Least privilege: granular permissions are enforced per data category.
• Operational transparency: the port is configurable and behavior remains deterministic.

Evidence pack (Google Play review / internal audit)

To reduce back-and-forth, provide the following minimum evidence set during review:

• Capture 1: persistent notification showing “Auto-connection service active”.
• Capture 2: the STOP action visible inside the notification.
• Capture 3: “Freemindtronic Extension” settings page with the Auto-login switch and the Wi-Fi icon.
• Capture 4: port screen (default 10001) plus the phone name (pairing).
• Capture 5: an example of granular controls (at least 5 categories ON/OFF).

This evidence pack is designed for a Google Play reviewer evaluating a foreground service.
It provides observable, reproducible artifacts aligned with official requirements.

Android foreground service: evidence ↔ Google Play requirements mapping (reviewer view)

• Google Play policy (FGS requirements): https://support.google.com/googleplay/android-developer/answer/13392821

Quick audit: verify an Android foreground service and the local-only scope (2 minutes)

This procedure allows an auditor or a reviewer to verify, within minutes, three core properties: visibility, immediate stoppability, and a strict local-only scope.

1. Verify perceptibility: enable PC Connection, then open the Android notification shade and confirm the presence of a persistent notification.
2. Verify stoppability: press STOP in the notification and confirm that the session terminates immediately.
3. Verify deactivation: in the “Freemindtronic Extension” settings, disable auto-login (switch + Wi-Fi icon), then confirm that no automatic restart occurs.
4. Verify functional dependency: observe that the browser extension loses the session as soon as the service stops.
5. Verify local scope: confirm that the port (default 10001) is a local parameter and that no cloud service is required for the session to operate.

Sovereign use case: transparency and operational continuity

In sovereign or high-constraint environments, the worst scenario is not only an incident.
More critically, it is an operational dead end caused by an opaque tool.
A feature that silently depends on background execution may be restricted by the OS and fail precisely when it matters most.

By designing PC Connection around a foreground service that is visible, stoppable, configurable, and strictly local, the user can prove—at runtime—what is executing and why.
As a result, this transparency increases resilience against policy hardening.
It also reduces the risk of last-minute incompatibilities during sensitive deployments.

Finally, when comparable scenarios involve attempted exfiltration, a hardware-rooted sovereign approach limits the impact.
If secrets remain confined to NFC HSM devices and operations stay explicitly mediated by the user, any data recovered out of context remains unusable in clear form.

Note: PC Connection does not rely on the Play Integrity API or on SafetyNet to operate.
Compliance rests on observable mechanisms (notification, STOP, local scope), not on remote or opaque attestations.

Glossary

FAQ — Android foreground service

Related links