# Background Location Declarations

Turning on the background presence tier means your app declares background location, and both app stores review that declaration. This page is the kit: the framing, the text to paste, the video to record and what to do if a reviewer pushes back.

You only need any of it if you call `enableBackgroundPresence()` (React Native) or `MyazaBackgroundPresence.enable()` (Flutter). The SDK never adds background location to your app on its own. Without it, presence verification still runs on app-open readings (see [Address Intelligence](https://trust.myaza.co/documentation/address-intelligence/markdown#presence-verification)), and nothing on this page applies.

## Frame it around your feature, not around verification

Reviewers approve background location when it powers something the **user** gets from **your app**, and when the app would not work properly without it. "We use a verification SDK" is not a reason. "You cannot open a full account with us until your home address is confirmed, and confirming it takes several days" is.

So before you write anything, fill in three blanks. Every text below uses them:

| Placeholder | What to write | Example (a digital bank) |
|---|---|---|
| `{{App}}` | Your app's name as it appears in the store | Acme Money |
| `{{Feature}}` | The feature the user unlocks or keeps by confirming their address | Full account (higher limits) |
| `{{Why}}` | Why your business must confirm the address before giving them that feature | Our banking licence requires a verified residential address before we can lift account limits |

Pick the row closest to your business:

| Your business | `{{Feature}}` | `{{Why}}` |
|---|---|---|
| Bank, wallet or neobank | Full account, higher transaction limits, without an agent visiting your home | A verified residential address is a condition of our licence for full accounts (in Nigeria, the CBN's Tier 3) |
| Savings, investment or crypto exchange | Withdrawals above the basic limit | Our regulator requires a verified address before higher withdrawals |
| Insurance | Policy issue | The insured address must be confirmed before cover starts |
| Merchant or agent onboarding | Merchant account activation | We confirm a merchant's premises before they can take payments |

**Personal-loan apps cannot use this on Google Play.** Play's Financial Services policy forbids personal-loan, earned-wage-access and loan lead-generation apps from requesting precise location (`ACCESS_FINE_LOCATION`), and geofencing needs it. If your Play listing is a personal-loan app, use [Proof of Address](https://trust.myaza.co/documentation/workflows/markdown#capture-add-ons) instead. The same limit affects the address step's own location fix, so talk to us before enabling address capture in such an app.

Say what is actually true for your business. If a verified address is a regulatory requirement for you, name it: reviewers treat a legal obligation that the user benefits from (a working account) very differently from a nice-to-have.

### The questions the reviewer is answering

Google tells its reviewers to ask these. Your texts and video should answer each one without the reviewer having to guess:

1. **Is background location important to the app's core functionality?** Yes: without it the customer cannot get {{Feature}} in the app.
2. **Does it deliver clear value to the user?** They get {{Feature}}, confirmed from their phone instead of by a field agent or a paper bill.
3. **Would users expect it?** They started the address confirmation themselves, after a screen explaining it.
4. **Could the app do the same in the foreground?** No. Living somewhere can only be shown over several nights, when the app is closed; a single check while the app is open proves only that the person visited once.

## What the SDK actually does

Everything you declare must match this. Reviewers test apps, and a declaration that under-describes what the app does is the fastest way to have it removed.

- With the user's consent, the app registers **one geofence** around the address the user placed on a map.
- The operating system wakes the app when the phone enters or leaves that area.
- From time to time (no more often than about every 40 minutes), and whenever the user opens the app, the SDK takes **one low-power location reading** to confirm whether the phone is still at the address. It is used only for that check.
- On the device, the SDK works out which days the user was at the address and whether they were there at night. Only those daily summaries are sent (a date, minutes present, night yes or no). Coordinates are never sent after the address is captured, and no location history is kept anywhere.
- Checking stops when the address is confirmed (or, for ongoing monitoring, when your organisation stops it), when the user withdraws consent, or when they turn location off.

Fill every form truthfully. A declaration that does not match what the app does can get the app removed, and repeated violations can get a developer account banned.

## Give people a switch

Both stores look for a way to stop background location from inside your app, and saying you have one makes the declaration stronger. Put a switch where the user manages their account (for example "Address confirmation: On") and call `disableBackgroundPresence()` (React Native) or `MyazaBackgroundPresence.disable()` (Flutter) when they turn it off. Turning it back on calls the matching enable function. The texts below mention the switch; remove that sentence if you do not add one.

## Google Play

### 1. The in-app disclosure (required before the permission prompt)

Play requires a disclosure inside your app, shown **before** the system asks for "Allow all the time", in normal use (not only in your privacy policy). It must say that the app collects location, that this happens in the background, and what for.

The SDK's address screens already carry a disclosure ("How it works": *your phone confirms it is at this address over the coming days, even when the app is closed. Only day-level summaries ever leave your phone, never your movements*). Keep those screens. Because the disclosure must be **your app's** statement, also show this sentence, in your app, on the screen where the user chooses to confirm their address:

> {{App}} collects location data to confirm your home address for {{Feature}}, even when the app is closed or not in use. Only daily summaries are used, never your movements, and checking stops once your address is confirmed.

Give it one button that continues ("Continue") and one that does not ("Not now"). "Not now" must leave the user in a working app, ideally with another way to confirm their address. Google's rules for this screen: it must be in the app itself (not the store listing or your website), it must not look like a system dialog, it must be readable by a teenager, and the accept button should not be a vague "Got it" or "OK".

### 2. Location permissions declaration

Play Console: **App content → Sensitive app permissions → Location permissions**. The form asks for three things.

**App purpose** (one or two sentences about your app as a whole):

> {{App}} is [what your app is, for example "a digital bank for everyday payments and savings"]. Customers confirm their home address in the app to get {{Feature}}.

**One feature that needs location in the background** (describe one feature only):

> Address confirmation for {{Feature}}. {{Why}}. With the customer's explicit in-app consent, the app registers a single geofence around the address the customer placed on a map. Based on when the phone enters and leaves that area over several days, and an occasional low-power location reading (no more often than about every 40 minutes, and when the app is opened) that only checks whether the phone is still at that one address, the app confirms that the customer lives there. Location is evaluated on the device: the app sends only daily summaries (date, minutes present, whether night hours were included). No location history is collected, coordinates are not transmitted after the address is captured, and checking stops when the address is confirmed. Customers can turn address confirmation off at any time with a switch in the app. Background access is required because living at an address can only be shown over several days and nights, most of which the app is not open for.

**Video:** the link from step 3.

If the form asks whether this is core functionality, answer yes: without it the customer cannot get {{Feature}} through the app.

### 3. The video (30 seconds)

Record on a real Android phone, portrait, with no editing beyond trimming. Keep it to 30 seconds or less. Upload it where the reviewer can open it without signing in (an unlisted YouTube link is preferred; a shared Google Drive MP4 is also accepted) and paste the link into the form.

| Time | What the screen shows | What to do |
|---|---|---|
| 0 to 4 s | Your app's home screen, then the {{Feature}} entry point | Tap into {{Feature}} ("Upgrade account", "Apply for a loan") |
| 4 to 9 s | Your disclosure sentence from step 1 | Pause so it can be read, then tap Continue |
| 9 to 13 s | The SDK's "Let's confirm your address" screen and its "How it works" panel | Open "How it works" so the text is visible |
| 13 to 18 s | The map with the pin | Place the pin, confirm the address |
| 18 to 23 s | The system prompt, then "Allow all the time" in the permission screen | Choose "Allow all the time" |
| 23 to 27 s | The success screen: the address check is running | Hold on it |
| 27 to 30 s | Your "Address confirmation" switch | Show that it can be turned off |

The three things the reviewer is looking for, in this order: the disclosure, the permission prompt, and the feature that uses it.

### 4. Data safety form

- **Location, precise:** collected; not shared (Myaza processes it only on your behalf, which Google Play does not count as sharing).
- **Purposes:** App functionality; Fraud prevention, security and compliance.
- **Optional:** Yes, if a user who declines can still use the rest of your app.
- **Encrypted in transit:** Yes.

### 5. The Android foreground service (only if you turned it on)

If you also call `enableForegroundService()` (React Native) or `MyazaPresenceService.enable()` (Flutter), your app runs a location foreground service with a persistent notification, and from Android 14 Play asks for a second declaration (**App content → Foreground service permissions**, type Location).

When the form asks for the use case, choose user-initiated location sharing: the customer started the address confirmation themselves.

Most apps should not turn this on. It exists for phones whose battery managers stop background work, and the periodic check-in above now covers much of that without it. Google has also announced that **geofencing stops being an accepted use of a location foreground service from 27 January 2027**, so expect this tier to be retired before then. If you do use it:

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

> {{App}} runs a location foreground service, with a visible notification, only while an address confirmation the customer consented to is in progress for {{Feature}}. It takes a low-power location reading every few minutes, checks on the device whether the phone is at the one address the customer confirmed, and sends daily summaries only (date, minutes present, whether night hours were included). It stops when the address is confirmed, when the customer withdraws consent, or when the check ends.

## Apple App Store

Apple has no declaration form. Review reads your purpose strings, your App Review notes and your privacy label.

**Purpose strings** (state the purpose, not the mechanism):

```xml
<key>NSLocationWhenInUseUsageDescription</key>
<string>Used to confirm your home address for {{Feature}}.</string>
<key>NSLocationAlwaysAndWhenInUseUsageDescription</key>
<string>Lets {{App}} confirm your home address over the next few days, even when the app is closed. Only daily summaries are used, never your movements.</string>
```

If you opt into the periodic iOS check-in, also add `co.myazahq.kyc.presence.checkin` under `BGTaskSchedulerPermittedIdentifiers` and `fetch` under `UIBackgroundModes`. Do not add the `location` background mode: region monitoring does not need it, and it invites questions.

Apple asks for no capability beyond these for region monitoring. Some vendors' guides ask for the "Location updates" background mode as well; this SDK does not use continuous location updates, so leave it off.

**App Store description** (optional, one line near the end of your description):

> {{App}} asks for location access "Always" only to confirm your home address for {{Feature}}: it checks whether your phone is at that one address over a few days, and you can turn it off at any time.

**App Review notes:**

> {{App}} confirms a customer's residential address before giving them {{Feature}}. {{Why}}. The "Always" location permission is used for one purpose: with the customer's consent, one region is monitored around the address they placed on a map, and the app occasionally confirms whether the phone is inside it. Only daily summaries (date, minutes present, night yes or no) leave the device. There is no location history and no tracking of where the customer goes, and the customer can turn it off with a switch in the app. To test: sign in with [demo account], open [path to {{Feature}}], and the consent screen appears before any permission prompt.

Apple also asks apps to offer an alternative to people who decline. Keep another route open for them: [Proof of Address](https://trust.myaza.co/documentation/workflows/markdown#capture-add-ons) in the same workflow, or the app-open check-ins, which need only while-in-use location.

**Privacy label:** Location, Precise; used for App Functionality (and Fraud Prevention if you list it); linked to the user; not used for tracking.

## If you are rejected

| What the reviewer says | What it usually means | What to do |
|---|---|---|
| "Not core functionality" | The declaration reads as a vendor feature, not yours | Rewrite around `{{Feature}}` and `{{Why}}`; show in the video that the user cannot get {{Feature}} without it |
| "Prominent disclosure missing" | Your disclosure appears after the prompt, or only in the privacy policy | Show your disclosure sentence before the prompt, in the video, with Continue and Not now |
| "Video does not show the feature" | The video stops at the permission prompt | End on the success screen showing the check running |
| "Declaration does not match app behaviour" | Something runs that you did not mention (often the foreground service) | Declare it, or turn it off |
| "Foreground location would be enough" | The texts do not explain why several days matter | Add question 4's answer above to the feature text and say it in the video |
| Rejected although you removed the feature | An older build on another track (internal, closed, open testing) still has the permission | Remove the permission from every track, or declare it for all of them |

Reply to the rejection with the corrected text and a new video link rather than resubmitting silently. If background location is still refused, you lose nothing essential: presence verification carries on from app-open readings, it just takes more opens to finish, and [Proof of Address](https://trust.myaza.co/documentation/workflows/markdown#capture-add-ons) remains available.

## Checklist

- [ ] `{{App}}`, `{{Feature}}` and `{{Why}}` filled in and true for your business
- [ ] Your disclosure sentence shows before the permission prompt, with a working "Not now"
- [ ] An in-app switch turns address confirmation off (and the texts mention it)
- [ ] Android manifest has `ACCESS_FINE_LOCATION`, `ACCESS_COARSE_LOCATION` and `ACCESS_BACKGROUND_LOCATION` (React Native: `{ "location": "always" }` in the config plugin adds them)
- [ ] Play: location declaration text, 30-second video link, data safety form
- [ ] Your privacy policy is linked both in Play Console and inside the app, and mentions location for address confirmation
- [ ] Your Play listing is not a personal-loan app (see the note under the business table)
- [ ] Foreground service: off, or declared with its own form
- [ ] iOS: both purpose strings, App Review notes with a demo path, privacy label