Right now the developer community seems fascinated (if not outright obsessed) with agentic coding. That wave is real, and it will heavily impact how we build software. But let’s not forget there are other topics worth attention. Here, the focus is something less fashionable: sensitive permissions on Android. After shipping TKWeek updates outside Google Play and answering the inevitable Why isn’t this on the Play Store? with a blunt Sensitive permissions, it is fair to ask whether that topic still matters in 2026.
I can answer that from shipping one app for a long time. I started working on TKWeek back in 2010. Some time later I added a module called My day that shows important information for a particular day, including missed phone calls. READ_CALL_LOG is a dangerous permission since API level 23, so users who do not want to allow the app to read those details have a secure, reliable safety hatch. Still, after a late-2018 announcement, by 2019 Google Play was enforcing READ_CALL_LOG under its high-risk / sensitive rules. Now, what does that store layer mean anyway?
Dangerous on the device, sensitive in the store
On the platform side, Android already classifies quite a few permissions as dangerous: they guard private user data, and starting with API 23 the user must grant them at runtime. READ_CALL_LOG is in that bucket (Manifest.permission.READ_CALL_LOG).
Google Play’s extra layer sits on top of that. In Play docs the umbrella is high-risk or sensitive permissions; Call Log and SMS are restricted permission groups. Either way, it is store policy, not just OS protection. For Call Log and SMS, only narrow use cases are allowed (typically default Phone, SMS, or Assistant handlers, plus a short list of exceptions), and you must declare them in Play Console or remove them from the manifest. See Google’s Permissions and APIs that Access Sensitive Information and Use of SMS or Call Log permission groups.
Back in 2021 that policy stopped being theoretical. Showing missed calls in My day needs READ_CALL_LOG. On the device that is fine: the user can grant or deny it. On Google Play it is not fine unless your app is something TKWeek is not: a default Phone, SMS, or Assistant handler, or one of a few narrow exceptions. A date and calendaring tool that surfaces what happened on this day does not qualify. So the choice was blunt. Keep the feature and leave the store, or keep Play and remove a piece of core usefulness. I removed call log access from the Play builds. Years later, with TKWeek shipping through F-Droid and Obtainium, missed calls are back for people who choose to grant the permission. Why? It’s about choice. Should a single storefront really be allowed to decide that a legitimate feature is fine on the device, but not if you want to ship through them?
Granted, an awful lot of bad actors try to abuse this freedom and harm developers and users alike. So, it is not only valid but truly important that vendors strive to protect us: runtime grants alone do not stop social engineering or store-scale abuse, which is why Play added a second policy layer. That still should not erase legitimate features for people who choose another channel and can simply say no at runtime.
Call Log is of course not the end of that story. In April 2026 Google announced a dedicated Contacts Permission policy. For apps that target Android 17 (API level 37) or higher, broad READ_CONTACTS is only allowed if the Android Contact Picker is not enough for core functionality. Otherwise you have to declare in Play Console why you need the whole address book, or drop the permission if you want to stay on Play. Sounds familiar? Console prompts started in September 2026; the policy takes effect October 28, 2026, and enforcement for those targets is lined up for January 2027. Same pattern as photo and video: prefer a minimum-scope system UI, justify broad access, or leave. That hits calendaring and reminder tools hard. Showing birthdays and anniversaries from Contacts needs the list, not a one-shot pick of a single person.
And there’s more. While READ_CALENDAR is still a dangerous permission, it shows up in the general sensitive permissions guidance: request it only for critical features, explain at runtime, respect a denial. So far, there is no parallel Calendar Picker plus Play declaration for READ_CALENDAR policy next to Contacts and Photo/Video. Calendar sits under the broad sensitive-data rules today, without the 2026 contacts-style clamp. But Call Log was only the precedent. Contacts is the sequel. For Calendar, the honest label is still watch this space.
From permissions to who may ship at all
Storefront power does not stop at which permissions you may declare. Google is also tightening who may put software on a certified Android device at all. Android developer verification requires developers to register their identity with Google if users should be able to install their apps on certified devices. That includes distribution outside Play. Enforcement begins in selected countries in September 2026, with a wider rollout planned afterward (timeline). Whatever you think about fighting malware, the effect is clear: the gatekeeper of the biggest storefront also becomes an identity checkpoint for installs outside Play.
As a European developer, I do not take that lightly. Digital sovereignty is not a slogan for conference slides. It is whether we can still build, ship, and improve useful open-source software without asking a single US platform for permission at every step. The EU Digital Markets Act already pushed gatekeepers toward alternative app stores and sideloading. Developer verification sits uneasily next to that promise of real distribution choices beyond one store. Communities and legislators are arguing the point. They must keep arguing it.
That is also why places like dev.to matter. I feel that an open publishing commons for developers only stays meaningful in the long run if we can also choose how our software reaches users. My recipe right now: Play when it fits, F-Droid, IzzyOnDroid, and Obtainium when features and honesty demand it, and direct distribution when we must. Agentic tooling only raises the stakes: when software can request contacts, calendar, or call-log access on our behalf, honest justification and user consent matter more, not less. Sensitive permissions were never only a form in Play Console. They are a stress test for whether Android remains a platform we use, or one we merely rent.
What are your thoughts on freedom to distribute and digital sovereignty? Please share them in the comments.