---
title: "Google Play's January 27 Permission Deadline: Audit Your App"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-10-12"
category: "How to Build"
tags:
  - Google Play permissions policy
  - Android contact picker
  - Android geofencing
  - READ_CALL_LOG policy
  - Android location permission
excerpt: "Four Google Play permission rules tighten on January 27. Here is how to find out which ones your Android app touches, what to replace them with, and what it costs in engineering time."
reading_time: "9 min read"
canonical_url: "https://kanopylabs.com/blog/google-play-january-27-permission-changes-android-app-audit"
---

# Google Play's January 27 Permission Deadline: Audit Your App

## The Four Rules That Change on January 27

Google's Play policy page lists a cluster of permission changes that take effect on January 27. They were announced months ago, and they are easy to miss because they sit three months out and arrive as four separate policy updates. Here is what each one says, based on Google's published policy page.

- **Geofencing as a foreground service use case.** It is removed from the approved list. Google tells developers to use the Geofence API instead.

- **Contacts permissions.** Apps that do not have a real need for broad contacts access must use the Android Contact Picker.

- **Location permissions.** The policy is updated, and the location button is the recommended minimum scope for precise location.

- **SMS and call log permissions.** Phone call verification is no longer a permitted use of READ_CALL_LOG. Google names the Digital Credentials API and the SMS Retriever API as alternatives.

If your app does none of these things, you can stop reading and go ship something. If you are not sure, keep going, because the answer lives in your manifest and in code written by people who may have left. A permission added two years ago to make a demo work is still there, and Google's review process does not care why.

![Laptop open to a code editor showing an Android project manifest file](https://images.unsplash.com/photo-1517694712202-14dd9538aa97?w=800&q=80)

A caution on sources. The summary above comes from the policy page itself. Before you scope work, open the linked policy text for each rule and read the exact wording, since details such as which apps qualify for an exception sit in the full policy and not in the headline.

## Step One: Find Out What Your App Actually Asks For

Before anyone writes code, get an honest inventory. This takes an engineer about two hours on a normal app and often finds surprises.

1. Open the merged manifest for your release build, not the source manifest. Libraries add permissions that you never typed.

2. Search for the permissions behind each rule: contacts, fine and coarse location, background location, call log, SMS.

3. For each one, write down the feature that needs it and the screen where the user sees the prompt.

4. Check your Play Console declarations. What you told Google about each permission should match what the code does.

5. Check third-party SDKs. An analytics or ads library that reads location can put your app out of compliance without a single line of your own code.

The merged manifest step is the one teams skip. We see apps where the team believes they request location in one place, and the merged manifest shows four libraries each adding their own entry. You are responsible for all of them, since the policy applies to the app and not to the author of each dependency.

When the inventory is done, sort every finding into one of three buckets: keep as is, replace with a narrower API, or remove. Most apps end up with a few of each. The replace bucket is where the engineering cost sits, and we will cover it feature by feature below.

## Contacts: Use the Picker Unless You Have a Reason Not To

The contacts rule is the one most likely to affect consumer apps. Invite-a-friend screens, referral flows, split-the-bill features, "find people you know" and sharing shortcuts have all historically asked for the full address book. Under the new policy, an app that does not need broad contacts access must use the Android Contact Picker.

The picker changes the design. Instead of reading every contact in the background and building a list, you launch a system screen, the user taps the people they want, and your app receives only those. The user sees less scary permission language, and you receive less data. For a lot of products that is a better outcome, since a refusal on a contacts prompt tends to end the feature entirely.

Where this hurts is anything that depends on matching the whole address book against your user base. If your growth loop is "tell me who among my contacts already uses the app," you have a legitimate reason to ask for broad access, and you should read the policy carefully to see how Google expects you to justify it. Expect to explain the feature in the Play Console and expect a reviewer to read your explanation.

Our advice is blunt. If your feature works with a picker, switch to it, even before the deadline. You reduce your privacy exposure, you shorten the permission flow, and you remove a thing that can get your update rejected. This also lines up with what regulators ask of you. Our guide to [GDPR compliance for apps](/blog/gdpr-compliance-for-apps) explains why collecting less data is the cheapest compliance strategy there is.

A realistic effort estimate for swapping a contacts flow to the picker is a few days of engineering plus QA across a handful of device makers. The design work is the larger part, since you are changing a screen the user sees.

## Location: Ask for Less, and Know Why You Ask

Google's updated location policy names the location button as the recommended minimum scope for precise location. In plain terms, the direction of travel is toward asking for location at the moment the user taps something, and not holding it permanently in case you need it later.

Check each location use against a simple question: does the feature need location continuously, or only when the user does something? Most do not need it continuously.

- **Store finders, delivery address fill, nearby search.** One-time location when the user taps. These are the easy wins.

- **Check-ins and ride or job start.** Location at the tap, and sometimes during an active session. Still no reason for all-day access.

- **Fleet, family and safety tracking.** Continuous background location is the product here, so the review risk is real. Make sure your declaration, your in-app disclosure and your privacy policy say the same thing. Our guide to building a [family safety location sharing app](/blog/how-to-build-a-family-safety-location-sharing-app) goes through the disclosure design these products need.

- **Analytics and ad SDKs.** These often collect location without a product reason. Turn it off in the SDK configuration, or remove the SDK.

Be careful with precise versus approximate location. A weather widget or a regional content feed does not need precise location, and an approximate fix is a smaller ask and a smaller liability. Where the product can work with the coarser option, request only that.

![Phone in hand showing a map screen used for a location based feature](https://images.unsplash.com/photo-1512941937669-90a1b58e7e9c?w=800&q=80)

One practical habit helps here. Write a one-sentence reason for every location request in your code review notes. If an engineer cannot write that sentence, the request probably should not exist.

## Geofencing: Replace the Foreground Service Pattern

Starting January 27, geofencing is removed as an approved foreground services use case, and Google points developers to the Geofence API. If your app keeps a foreground service alive with a persistent notification just so it can watch for the user entering or leaving a place, that approach is the one being retired.

Apps that tend to do this include retail and loyalty apps that trigger offers near a store, field service apps that log arrival at a job site, and home or smart building apps that react when someone gets close. A lot of these were built quickly, with a foreground service chosen because it kept the process alive and the notification was an acceptable cost.

The replacement moves the monitoring to the platform. You register the regions you care about with the Geofence API, and the system tells your app when the user crosses one, without your own service running all day. The tradeoffs to plan for:

- **Limits on how many regions you can register.** If your product watches hundreds of locations, you need logic that registers only the nearest ones and refreshes the set as the user moves.

- **Timing is looser.** The system batches and delays to save battery. A feature that promised a notification within seconds of arriving needs its promise rewritten.

- **Permissions still apply.** Geofencing needs location access, and background use needs the right declarations. Do not assume the new API lets you skip the disclosure work.

- **Testing is harder.** You can mock locations on a bench, but real-world behavior varies by device and battery settings. Budget real field testing.

This is the single largest line item in most audits. Replacing a foreground service with the Geofence API is several days of engineering for a simple case and a couple of weeks for a product where geofencing is the core feature. Price it before the holidays, not during them.

## Call Log and SMS: Rethink Phone Verification

The call log change is narrow but sharp. Phone call verification is no longer a permitted use of READ_CALL_LOG. Some apps verify a phone number by placing or receiving a call and then reading the call log to confirm it happened. That pattern is going away.

Google names two alternatives. The SMS Retriever API lets your app receive a one-time code by text without asking for broad SMS permission, which is the standard replacement for apps that already send codes by SMS. The Digital Credentials API is the newer route for proving something about the user, and it is worth reading about if your verification goes beyond confirming a phone number.

Before you rebuild, ask whether you should be verifying by phone at all. Costs add up: SMS delivery fees vary by country and carrier, fraud rings abuse SMS verification to run up your bill, and some markets deliver codes badly. Depending on your product, email links, passkeys or a hosted sign-in service may be cheaper and safer than rebuilding a phone flow.

If you must keep phone verification, build it on the SMS Retriever API, add rate limits per number and per device, and set a spending alarm with your SMS vendor. A fraud spike on an unprotected verification endpoint is one of the more reliable ways to receive a surprise bill.

![Analytics dashboard on a laptop screen tracking sign-in and verification activity](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

For the security side of sign-in design, our [mobile app security best practices](/blog/mobile-app-security-best-practices-2026) guide covers verification, token storage and the common mistakes in each.

## What the Work Costs and How to Schedule It

Here is a sensible way to size the work. These are ranges based on typical agency rates for mobile engineering in the US, which run from roughly 100 to 200 dollars an hour depending on seniority and region. Your own team's numbers will differ.

- **Inventory and declaration review:** one to two days, including SDK checks.

- **Contacts to picker:** two to five days with design and QA.

- **Location scope reduction:** one to four days, depending on how many entry points ask for it.

- **Geofencing rewrite:** one to three weeks.

- **Phone verification replacement:** three days to two weeks, depending on whether you also change vendors.

Most apps touch one or two of these, not all five. A typical consumer app with a contacts invite and a store locator is a week of work. A logistics or loyalty app with geofencing at its center is a project.

The calendar matters more than the hours. January 27 is a few weeks after the holidays, review times lengthen in December, and your team will be thin around the end of the year. Work backward:

1. **October:** inventory the permissions and decide what to keep, replace or remove.

2. **November:** build the replacements on a branch and test on real devices.

3. **Early December:** release to a small percentage of users with staged rollout and watch crash and permission-denial rates.

4. **Mid-December:** finish rollout and update Play Console declarations.

5. **January:** hold a buffer for review problems and do not plan a large feature release the same week.

If you only have budget for part of it, do the work that carries the most review risk first: broad contacts access without a clear need, and anything that reads the call log.

## Make Permissions Part of Your Release Habit

This deadline is one of several that will arrive this year, and next year will bring more. A team that treats each one as a fire drill pays for it every time. A team with a small standing process pays almost nothing.

Three habits are enough:

- **A permissions list in the repository.** One file that says which permission the app requests, which feature needs it, and who approved it. A pull request that adds a permission has to update the file.

- **A manifest check in CI.** A script that fails the build when the merged manifest gains a permission nobody listed. This catches the library that quietly adds location.

- **A yearly policy review.** Put a date on the calendar in each autumn and read Google's and Apple's policy pages together. Our [security guide](/blog/mobile-app-security-best-practices-2026) and the maintenance budget advice in our post on app upkeep both assume this kind of recurring review exists.

Founders sometimes ask whether all this is worth it for an app with a few thousand users. It is, because the downside is not a fine. It is a rejected update on the day you need a bug fix, or a listing suspended on the day of a campaign. Both are far more expensive than two hours of inventory.

If you want an outside review of your Android permissions, declarations and SDKs before the deadline, we do this for founders regularly and can usually tell you what will fail review in a single call. [Book a free strategy call](/get-started) and send us your merged manifest.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/google-play-january-27-permission-changes-android-app-audit)*