How does the Android app permission system decide which data a new app can access?

17 Eki 01:20

When I first built a location‑based reminder app a couple of years back, I ran straight into the permission flow Android enforces. During the initial install the manifest only declares the permissions; Android doesn’t decide anything yet. The real evaluation happens the first time the app actually tries to use a protected API, like `FusedLocationProviderClient`. At that point the system checks three things: the permission’s protection level (normal, dangerous, special), the target SDK of the app, and the current user’s consent state. For “dangerous” permissions (e.g., ACCESS_FINE_LOCATION, READ_CONTACTS) Android automatically grants them on install for apps targeting API 30‑ and lower, but shows a runtime dialog for newer targets. The dialog is generated by the framework, not the app, and it reflects the context: if the request comes from a foreground activity, the prompt appears immediately; if it originates from a background service, the system will either defer the request until the app comes to the foreground or outright reject it with a “background location access not allowed” error, unless the app has the special “Allow all the time” flag that the user explicitly set in Settings. In my case, the first time the app tried to fetch the user’s location while a background sync was running, Android threw a `SecurityException` because the request came from a `JobScheduler` worker without an active UI. I had to add a small foreground service with a persistent notification, request the permission while the user was actively interacting with the app, and then hand off the background work. Once the user granted the permission, Android cached the consent and any subsequent calls from either foreground or properly‑qualified background components were allowed automatically. So the decision tree is basically: check protection level → see if the permission is already granted → if not, see whether the request originates from a foreground component (prompt the user) or an illegal background context (deny or defer). Background services can only use permissions that the user has already approved and that the OS explicitly permits for background use; otherwise you’ll hit the same runtime denial I experienced.

17 Eki 01:49

Android’da permission kontrolü aslında üç katmanlı bir akışla çalışıyor: manifest deklarasyonu, paket yöneticisi (Package Manager) ve runtime izin denetimi. Öncelikle bir geliştirici, `AndroidManifest.xml` içinde istediği izinleri (örnek: `READ_CONTACTS`, `ACCESS_FINE_LOCATION`) listeler. Bu aşama paket yöneticisine “Bu uygulama bu tip verilere ihtiyaç duyuyor” sinyalini verir. Uygulama yüklendiğinde, paket yöneticisi manifestteki izinleri tarar ve iki gruba ayırır: **normal** ve **dangerous**. Normal izinler (örnek: `INTERNET`) sistem tarafından otomatik olarak onaylanır; kullanıcıdan hiçbir onay istemez. Dangerous izinler ise kullanıcı iznine tabi tutulur. Uygulama çalıştırıldığında, runtime’da bir dangerous izin gerektiren bir API (mesela konum al) çağrılırsa, `ActivityManager` ve `PermissionManager` devreye girer. İlk kez bu iznin kullanılmaya çalışıldığı anda, sistem “grant state = denied” olarak işaretler ve kullanıcıya bir dialog gösterir. Kullanıcı “İzin ver” dediğinde, `PackageManager` o izin için “granted” bayrağını ayarlar ve ilgili süreç (process) içinde `checkSelfPermission` artık `PERMISSION_GRANTED` döner. Eğer kullanıcı reddederse, aynı oturumda o izni tekrar istemek zorunda kalmaz; sistem `PERMISSION_DENIED` döner ve uygulama bu özelliği devre dışı bırakmak zorunda kalır. Android 11+’de “one‑time” ve “while‑in‑use” gibi ek kısıtlamalar da var; bu durumda izin sadece aktif bir foreground aktiviteyken geçerli olur, arka planda çalışırken otomatik olarak geçersiz kılınır. Arka plan servisleri (background services) burada kilit bir rol oynar. Android 10’dan itibaren **Background Location** izni ayrı bir permission (`ACCESS_BACKGROUND_LOCATION`) olarak tanımlandı. Bir servis konum verisi çekmek istediğinde, sistem önce foreground izin durumunu kontrol eder; eğer sadece “while‑in‑use” izin varsa, servis bu isteği reddeder ve bir `SecurityException` fırlatır. Kullanıcı “always allow” (her zaman izin ver) seçmişse, servis arka planda da veri alabilir. Benzer şekilde, arka plan veri erişimi (`READ_PHONE_STATE`, `READ_SMS`) gibi izinler de “restricted” kategorisine girer ve Google Play politikaları gereği, bu izinleri isteyen bir uygulama Play Store’da ek bir açıklama ve gizlilik beyanı sunmak zorunda. Kısacası, arka plan servisleri sadece ilgili “background” izni alındıysa ve kullanıcı bu izni onayladıysa veri çekebilir; aksi takdirde sistem otomatik olarak reddeder. Sonuçta, Android’in izin mekanizması **manifest → paket yöneticisi → runtime onay → context‑aware kontrol** şeklinde bir zincir izler. Normal izinler otomatik, tehlikeli izinler kullanıcı onayı ve arka plan izinleri ekstra onay gerektirir. Bu katmanlı yapı sayesinde, uygulamanın ne zaman ve hangi koşullarda veri çekebileceği net bir şekilde kontrol altında tutulur, kanka. Valla bu model, veri sızıntılarını önlemede çok etkili, ama geliştiricilerin de doğru izin stratejisini planlaması şart.