Background Location Declarations

Enabling the background presence tier means your app declares background location, and both stores treat that declaration as a review event. The SDK deliberately never adds these entries for you, because the declaration changes your app's review posture and the decision belongs to you. This page is the paperwork, ready to paste.

You only need any of this if you call enableBackgroundPresence() (React Native) or MyazaBackgroundPresence.enable() (Flutter). The foreground tier needs no store declaration at all: it uses ordinary while-in-use location, and that is the default for a reason.

What your app actually does (the honest summary)

Reviewers approve declarations that are specific and verifiable. This is the truthful description of the SDK's behaviour, and every text below is built from it:

• The app registers one operating-system geofence around an address the user confirmed on a map, with their consent, during identity verification.
• The OS wakes the app on entry and exit. The SDK computes, on the device, which calendar days the user was at the address and whether the night hours were touched.
• Only those per-day summaries (a date, minutes of dwell, a night yes/no) are transmitted. Raw coordinates never leave the device after capture, and no continuous tracking or location history exists anywhere.
• Monitoring stops when the user is verified, when they revoke it, or when your organisation stops the check.

Google Play: the location permissions declaration

Play Console asks every app declaring ACCESS_BACKGROUND_LOCATION to complete the App content → Sensitive app permissions → Location permissions declaration, including a feature description and a short demo video.

Feature title (pick the one matching your product):

Address verification for account opening

Declaration text (paste into "Describe the feature that uses background location"):

This app verifies a customer's residential address as part of regulated financial-services onboarding (know-your-customer compliance). With the customer's explicit in-app consent, the app registers a single geofence around the address the customer confirmed on a map and receives operating-system entry and exit events for that one location. Location is evaluated on the device: the app transmits only daily summaries (date, minutes present, whether night hours were touched) to confirm the customer lives at the address they declared. No continuous tracking takes place, no location history is collected, raw coordinates are never transmitted after the initial address capture, and monitoring ends when verification completes or the customer withdraws consent. Background access is required because residency can only be demonstrated across several days, including times the app is not open.

The demo video must show, in order: your in-app disclosure screen, the system permission prompt, and the feature working. Record the SDK's address step: the presence explainer and consent accordion, then the two-step permission request, then the success screen's monitoring card.

Prominent disclosure requirement. Play policy requires an in-app disclosure before the runtime permission prompt, stating the data, the purpose, and that collection happens in the background. The SDK's presence intro screen and consent accordion are that disclosure; do not suppress them in a custom flow. If a reviewer asks where the disclosure is, it is the screen titled "How address confirmation works" shown before any permission prompt.

The Android foreground service

If you also enable the foreground-service tier (enableForegroundService() on React Native, MyazaPresenceService.enable() on Flutter), your app runs a location-typed foreground service with a persistent notification. Two more things follow.

Manifest. React Native hosts on { "location": "always" } get the permissions from the config plugin, and expo-location declares its own service. Flutter hosts declare both themselves:

<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE_LOCATION" />

<application>
  <service
      android:name="co.myazahq.kyc.PresenceForegroundService"
      android:exported="false"
      android:foregroundServiceType="location" />
</application>

The plugin refuses to start an undeclared service (notDeclared), so a missing block is a clean refusal, never a crash.

Play Console. From API 34, an app that declares FOREGROUND_SERVICE_LOCATION completes the foreground service permissions declaration (App content, Foreground service permissions), which asks for the service type, a description and a demo video. The type is Location. Use this description:

The app runs a location foreground service, with a visible persistent notification, only while an address verification the customer explicitly consented to is in progress. It takes a low-power location fix every few minutes, evaluates on the device whether the phone is at the single address the customer confirmed, and transmits daily summaries only (date, minutes present, whether night hours were touched). The service exists because the check must keep running when the app is closed, including on devices whose power management stops background work; it stops when verification completes, when the customer withdraws consent, or when the organisation ends the check.

The notification. Word it for the person, not the reviewer, and remember it is on screen for days: "Address verification in progress" with "Open the app to see your progress" is the SDK's default and a fair model. Give it its own channel (the SDK does) so your other notifications are unaffected.

Apple App Store: purpose strings and review notes

iOS has no separate declaration form; the review runs on your purpose strings and the App Review notes. Use purpose strings that state the purpose, not the mechanism:

<key>NSLocationWhenInUseUsageDescription</key>
<string>Used to confirm your address during identity verification.</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Lets your address stay confirmed automatically, so you do not have to
prove it again. Only daily summaries are used, never your movements.</string>

App Review notes (paste into the version's Review Notes):

This app performs regulated identity verification (KYC) for financial services. The "Always" location authorisation powers address verification: with the user's explicit consent, one geofence is registered around the address the user confirmed on a map, and the app receives region entry and exit events for that single location. Evaluation happens on the device; only per-day summaries (date, minutes present, night yes or no) are transmitted. There is no continuous tracking and no location history. To test: [describe your demo account path to the verification flow]. The consent screen appears in the flow's address step before any permission prompt.

The checklist

Android (host app manifest):

<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_BACKGROUND_LOCATION" />

iOS (host app Info.plist): the two purpose strings above. React Native hosts using the config plugin get all of these from { "location": "always" }.

Before submitting: the workflow's address step has presence enabled, the in-app disclosure screens are not customised away, the demo video shows disclosure then prompt then feature, and your data-safety form (Play) or privacy nutrition label (Apple) declares location collected for app functionality, not advertising.