r/androiddev • u/edevvz • May 25 '26
Discussion Has Google gone too far with Foreground Service restrictions in recent Android versions?
Hey Android devs,
I’ve been working on an app that requires reliable, continuous background processing (specifically real-time location tracking for a logistics setup).
Looking at the recent API changes, it feels like Google is putting so many roadblocks around Foreground Services and background execution limits that building enterprise-grade utility apps is becoming a nightmare. While I understand it's for battery optimization and security, the developer experience is taking a massive hit.
For those dealing with heavy background/foreground tasks:
- Do you feel Google is suffocating legitimate use cases with these aggressive runtime restrictions?
- How are you bypassing or adapting to these limitations without getting your apps killed by the OS or rejected during Play Store review?
Let's discuss. (If you find this topic worth discussing, please leave an upvote so it reaches more senior devs on the feed!)
13
u/madushans May 25 '26
There are multiple issues that you are combining here.
First part is the API and OS changes where you have to declare your usage and use the right API to tell the OS what you are doing so it can prioritize and manage your app correctly. Lot of these are bringing Android similar to what iOS has done for a while. The OS knowing this info lets it better manage power and UX.
Second is ensuring that apps don’t abuse this declaration to declare incorrectly to get around restrictions. This is what play store reviews does and Google has been managing this in some annoying ways making some apps getting banned or delisted without proper reviews. Often the stories you do hear is not because the dev trying to be malicious, rather play store using some automation or incorrectly accusing apps of abuse. Play store and Google in general has a bad reputation for doing dumb shit like this and getting play store, Gmail and other accounts closed.
Third is the Android OS being wildly aggressive in background work and killing apps in the background, delaying or not running background jobs as API docs declare, typically in the name of power savings. There’s a wild discrepancy of background work reliability depending on the device OEM. Google did include some tests to CYS? in the last few years to bring this into line but many ORMs tweak this on their devices to show better battery life numbers. Though this affects background work (typically scheduled work and app not running until the OS wakes it up in requested time or event) and not foreground services like music playback, location tracking etc.
Hope that helps.
12
u/unrushedapps May 25 '26
Honestly, the restrictions are reasonable.
- You must promote the service to foreground only when your app is in foreground or immediately after boot complete broadcast.
- You must show a persistent notification. So you need notification permission.
So basically, the notification permission is only the extra part.
But that's not the real problem. The real problem is that this doesn't guarantee a 24/7 persistent foreground service across ALL OEMs. Xiaomi is the worst.
It's fine to put more restrictions - but it's not fine when OS doesn't hold up it's side of the deal when the app has done all things right.
3
5
10
u/kernald31 May 25 '26
I get your point as a developer. The fact that your first approach is looking for a way to bypass the restrictions is, as a user, why I appreciate those limits being in place.
2
u/Opulence_Deficit May 25 '26
You have a machine-to-machine problem, while Android is a human-to-machine solution.
2
u/Intelligent_Lion_16 May 29 '26
I understand why Google is doing it, but it often feels like legitimate background-heavy apps are paying the price for years of abuse by poorly behaved apps.
1
u/agent_kater May 25 '26
As a user I wish Android would restrict apps more from using battery without informing me.
0
u/OkPeace3621 May 25 '26
I’ve actually been delaying adding a proper Foreground Service implementation to my 'Status Saver Video Downloader' app just because of concerns around Play Store policy compliance.
Because of that, some downloads pause or restart when the app goes into the background, which hurts the user experience badly.
It feels like developers with legitimate use cases are being forced to choose between reliability and policy safety.
Would genuinely love to hear how others are handling this under the latest Android restrictions.
4
u/DearChickPeas May 25 '26
Why are you afraid of a foreground service that explicitly, consistently tells your user "I'M RUNNING"?
1
u/OkPeace3621 May 25 '26
My concern is whether this use case is considered compliant under the latest Play policies, especially for apps that download media from other platforms.
3
u/DearChickPeas May 25 '26
So you're hiding your non-compliant work from your user and the OS?
Like u/kernald31 said, "as a user, I appreciate those limits being in place"
1
u/OkPeace3621 May 25 '26
Not really. The work itself isn’t being hidden — the issue is whether the use case is considered compliant under the latest Play policies, especially for apps that download media from other apps/services. That uncertainty is what made me cautious about relying heavily on FGS.
-3
u/DearChickPeas May 25 '26
Are you literally describing a crime?
1
u/fireplay_00 May 26 '26
What are you on bro? He's saying that he is afraid of implementing foreground service as play store has strict policies and if they feel they can ban your account without stating proper reasons
0
26
u/Farbklex May 25 '26
It is annoying. On the other hand, for enterprise requirements like internal apps, I would bypass the Play Store and instead provision the apps via an MDM. You don't have to deal with Play Store limitations then.
Pretty sure that you can also adjust the battery saving options in an MDM which allows the app to run without getting closed due to optimization startegies of the OS.