An Android app built by outsourcing several years ago continues to run without notable issues today. Maintenance is handled at a minimum level for a small monthly fee. Quite a few companies find themselves in this exact situation.
An additional line item will be added there next term. This is because Google Play has revised its app quality requirements, gradually enforcing memory usage standards from February 2027 and requirements regarding login persistence during device upgrades from April 2027. Announced on August 26, 2026, there is over a year of grace period before enforcement.
While that grace period remains, what you want to clarify ahead of technical solutions is who bears this cost and by when it must be completed.
What happens when thresholds are exceeded
First, regarding memory. Under the new standards, an app's memory consumption is evaluated across multiple criteria, such as the volume of memory the app occupies and whether image data is held continuously in the background.
The critical point is that this standard is not merely a matter of being rejected during store review. Apps exceeding threshold values suffer degraded performance on user devices and become more prone to being terminated by Android. In other words, even without publishing updates to the store, it is a change that causes the app in users' hands to become one that "crashes often."
This is where it differs in nature from past target API level bumps. API level requirements were a matter of "support this if you submit an update," whereas the memory side carries the characteristic where even if left alone without updates, the user experience continues to deteriorate.
The other requirement, Zero-Tap Sign-In, addresses support for mechanisms that automatically transfer an app's logged-in state when a user switches devices. This will apply starting in April 2027.
What clients should verify first
Technical implementation is the development side's job, but if the client does not control the order of verification, they cannot evaluate the validity of estimates. At a minimum, it is worth grasping the following three items in-house:
1. Is that app still being updated today? For apps that have not been resubmitted to the store for several years, estimating the workload becomes difficult. This is because library versions are outdated, requiring the foundational base to be upgraded first.
2. Is it an app that handles numerous images? Image-heavy apps such as catalogs, real estate listings, menus, and construction case studies fall into the category susceptible to memory threshold impacts. Conversely, apps focused primarily on form input and table listings have relatively more headroom.
3. What is included in your current maintenance contract? Does the agreement cover only "incident response," or does it extend to "tracking store requirements"? If you enter 2027 with this left ambiguous, the moment work is needed will mark the start of negotiations over additional estimates.
The third point is where friction most frequently occurs in practice. If an agreement contains no mention of "responding to store policy changes," standard interpretation holds that it is not included, meaning the scope of "maintenance" assumed by the client diverges from the scope assumed by the vendor.
Defining the scope of maintenance in words now
Having time before requirements take effect also means having time to organize contract terms and estimate assumptions.
| Verification items | When left ambiguous | When decided in advance |
|---|---|---|
| Tracking store requirements | Turns into additional estimate negotiations right before enforcement | Can be planned within the annual maintenance budget |
| Criteria for judging completion | Whether it has been addressed becomes subjective | Can be verified by measuring against criteria |
| Post-implementation verification | Requires resubmission and monitoring to see how it fares | Before-and-after numerical comparisons can be retained |
The second row, "criteria for judging completion," is meaningful precisely because requirements like memory can be measured numerically. If you measure and record memory usage before and after implementation, you can explain later what the additional cost paid for. Conversely, if you accept deliverables based solely on assurances like "we made it lighter" without measurements, you can only discover whether the criteria were truly met through bug reports from users.
This line of thinking shares common ground with responding when external factors alter an app's underlying premises. Store rule changes arrive regardless of your company's schedule, making this about securing a framework in advance so you do not scramble when they arrive.
When rebuilding comes into view
For companies holding legacy apps, there are cases where replacing them with an alternative format works out cheaper overall than layering on patches.
The dividing line in this decision is whether that app fundamentally needs to be a native app. If it makes deep use of push notifications, camera hardware, or location services, replacement is unrealistic. On the other hand, if it essentially serves as "internal listings and input forms," shifting to a web-based architecture offers a path out of store requirements altogether. If you don't release to an app store, you don't need to continually track store requirement changes.
This is an area where the answer changes depending on what your current app does. Before deciding to "address the update," it is worth stepping back to review why the app was built in the first place.
What to do next
Send a single question to your maintenance vendor: "Are the Google Play memory requirements taking effect in February 2027 and Zero-Tap Sign-In in April covered under our current maintenance contract?"
If the answer is that it is included, you do not need to do anything for next term's budget. If the response is that it is not included, negotiations begin from there, and you can start while you still have time. If you receive no reply, or if they are unaware of the requirements themselves, that in itself serves as a deciding factor.
Assessing estimate validity for Android app requirements, structuring maintenance contract scopes, and evaluating transitions from native apps to web-based platforms are available through GleamHub's Development, AI, and Automation consulting services. Because available options depend on your current app architecture, please reach out individually via our contact form.
Sources
- Google overhauls app quality requirements: Details and countermeasures for mandatory memory reductions — gihyo.jp
- Google warns Android app developers to reduce memory usage, sets new thresholds starting February 2027 — GIGAZINE
- Google Play to mandate Android app memory reductions and automatic login during device switches in 2027 — HelenTech
- Ensure app quality — Play Console Help
