If your Android app uses location, Android 17 changes what your users see and what Google Play expects. GoodBarber's Android engine now includes the new location button and the permission changes that come with it.
Android 17 puts location controls in users' hands
Android 17 was released on June 16, 2026 for supported Pixel devices, with other manufacturers following over the subsequent months.
Android 17 makes location access more visible. A persistent indicator appears when a non-system app accesses a user's position. Tapping it shows which apps have recently used location and lets the user manage their permissions immediately.
Approximate location is also more protective. Android previously used a fixed 2 km grid. It now adapts the area to population density, providing more consistent privacy in both urban and rural areas. The permission dialog makes the distinction between "Precise" and "Approximate" clearer too.
Keeping the engine current is our work, not yours
For us, the work began well before the public release: reading the developer documentation, identifying the changes that apply to GoodBarber apps, updating the Kotlin engine, and testing the resulting builds. We did the same for Android 15 and its edge-to-edge display, then for Android 16 and predictive back navigation.
A GoodBarber Android app is compiled natively, rather than wrapped in a WebView. The operating-system work therefore happens in the engine, not in each customer's back-office. You keep configuring and running your app; we update the engine that generates it.
One-time precise location now starts with a button
Many location features need an exact position only when the user asks for it: centering a map, finding the nearest venue, or validating a loyalty action on site. Android 17 introduces a system-rendered location button for these transactional uses.
The user taps the button and grants precise location for the current session. The app does not need to keep a permanent precise-location permission for that action. Android provides the icon and a predefined set of labels, so users encounter a recognizable control across different apps.
For apps targeting Android 17 or later, Google Play requires this button when precise location is needed only for a one-time, user-initiated action. The app declares that scope in its manifest with the onlyForLocationButton flag.
What Google Play expects
Google Play now asks apps to use the minimum location scope their features need: approximate rather than precise when possible, and the location button for one-time precise access.
Google describes two paths. For one-time precise access, the generated app identifies the location button's limited scope in its manifest. If an app keeps precise location outside that button flow, Play Console asks why approximate location or a one-time request would not be sufficient for a core feature.
The timeline is short. From October 27, 2026, pre-review checks in Play Console will flag potential location-policy issues before submission. The declaration itself becomes available in November 2026. Compliance is mandatory for all apps on January 27, 2027, with a 30-day self-service extension available.
What changed in GoodBarber
The Android engine migration went beyond changing the target SDK.
In the back-office, location permission is now divided into approximate and precise access instead of a single all-or-nothing choice. When an app needs precise location only for a one-time action, the generated build uses the flag that identifies this limited scope to Google Play.
In the app, the location button appears on the screens that use the user's position, including map sections, events, user directories, and geolocated loyalty-card validation. Because the system renders the control, its icon and behavior remain familiar while its label can match the action.
If a user grants only approximate location, the app continues to work without presenting false precision. Distances are rounded and displayed accordingly, for example as "more than 1 km."
Where geofencing and beacons fit
Two GoodBarber features keep precise location outside the one-time button flow: geofencing and beacons. A notification that appears when a customer enters a defined area, or when their phone detects a beacon, depends on location being available without a new tap at that moment. The location button cannot replace that behavior.
These features give the app owner a concrete, product-based justification in Play Console: describe the feature users rely on, and explain why an approximate or one-time position would not deliver it. Google still reviews the declaration, but the reason for retaining precise location is specific and directly tied to visible functionality.
Maintenance is part of the product
Prompt-to-app tools are genuinely fast at producing a first build. What happens after that depends on the tool and the development workflow: when an operating system changes, someone still has to update the SDKs, test the app, and submit a new version.
GoodBarber is designed around the full app lifecycle. Engine maintenance sits alongside the generated native apps, hosting, database, back-office, and publication workflows included in the platform, each of which is a separate service and a separate bill almost everywhere else. An Android release becomes work for our engineering team rather than a separate migration project for every app owner.
GoodBarber has maintained its app engines since 2011 for customers in 152 countries. That experience is what keeps existing apps ready to generate new builds as mobile platforms evolve.
What to do now
Open your back-office, generate a new version of your Android app, and submit it to Google Play. The engine changes are already included in the build.
If your app uses geofencing or beacons, review the new location declaration when it appears in Play Console. Describe the feature your users rely on and explain why an approximate or one-time position would not deliver it.