# 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:

```xml
<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:

```xml
<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):

```xml
<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.