Android Scoped Storage Mimarisi

Bölüm 1: Bu Nedir ve Neden Hayati Önem Taşır?

Android Scoped Storage (Kapsamlı Depolama), Android 10 (API 29) ile başlatılan ve Android 11 (API 30) ile zorunlu hale getirilen, dosya sistemi erişim paradigmasını kökten dönüştüren bir güvenlik mimarisidir. Geleneksel READ_EXTERNAL_STORAGE ve WRITE_EXTERNAL_STORAGE izinlerinin sunduğu “tüm dosya sistemine serbest erişim” modeli, veri sızıntısı, kötü amaçlı yazılımlar ve kullanıcı gizlilihi ihlalleri riski yaratıyordu. Scoped Storage, “en az ayrıcalık” (least privilege) ilkesini dosya sistemine uygulayarak, uygulamaların yalnızca kendi oluşturdukları dizinlere (getExternalFilesDir()) ve medya koleksiyonlarına (MediaStore) erişimini kısıtlar. Bu ontolojik değişim, dosya sistemini hiyerarşik bir ağaç yapısından, uygulama kimliği (UID) ve sahiplik (ownership) temelli izole edilmiş “kumhavuz” (sandbox) modellerine taşır. Metodolojik olarak, bu mimari dosya erişimini “Sahiplik” (Ownership), “Medya Koleksiyonu” (Media Collections) ve “Belge Sağlayıcı” (Document Provider/SAF) üç ana pilere oturtur. Temel parametreler; requestLegacyExternalStorage bayrağı (geçiş süreci için), MANAGE_EXTERNAL_STORAGE izni (özel durumlar için) ve MediaStore API sözleşmesidir. Bu yaklaşım, depolama birimini bir “paylaşılan havuz”dan, “sahiplik tabanlı güvenli veri konteynerlerine” evrilmesini sağlar.

Bölüm 2: Perde Arkası: Sistem Nasıl Çalışıyor?

Scoped Storage mekanizması, Linux çekirdeğinin çok kullanıcılı (multi-user) dosya sistemi izinleri (DAC – Discretionary Access Control) ve Android’in UID tabanlı uygulama yalıtımı (Application Sandbox) üzerine inşa edilmiştir. Her uygulama benzersiz bir UID atanır; bu UID, uygulamaya ait özel dizinler (/storage/emulated/0/Android/data/<package_name>/) üzerinde rwx (read/write/execute) sahiplik hakları verir. Paylaşılan alanlar (DCIM, Pictures, Downloads) ise MediaStore sağlayıcısı aracılığıyla soyutlanır. Uygulama bir medya dosyası eklediğinde, MediaStore veritabanına bir satır (row) ekler ve dosya sisteminde ilgili dizine yazma işlemini atomik bir işlem olarak gerçekleştirir. Okuma işlemlerinde ise uygulama, ContentResolver üzerinden MediaStore sorguları yapar; bu sorgular SQL benzeri bir sözdizimiyle (selection, sortOrder) çalışır ve Cursor nesnesi döner. Kritik mekanizma “Sahiplik Kontrolü”dür: Bir uygulama MediaStore üzerinden bir dosya silmek istediğinde, sistem dosyanın OWNER_PACKAGE_NAME sütununu isteyen uygulamanın paket adıyla eşleştirir. Eşleşme yoksa, kullanıcı onayı (System Picker) zorunlu hale gelir. Bu mekanizma, openFileDescriptor ile dosya tanıtıcısı (file descriptor) geçirerek, ham dosya yolu (/sdcard/...) bilgisinin uygulama kodundan tamamen soyutlanmasını sağlar.

Bölüm 3: Bilim Dünyası ve Uzmanlar Nasıl İnceliyor?

Scoped Storage uygulamasını yöneten standartlar; Android Compatibility Definition Document (CDD), Android Compatibility Test Suite (CTS) ve Google Play Developer Policy üçgenini oluşturur. CDD, cihaz üreticilerinin (OEM) MediaStore davranışını, DocumentsProvider arayüzünü ve MANAGE_EXTERNAL_STORAGE izin davranışını standartlaştırmasını zorunlu kılar. CTS testleri (CtsMediaHostTestCases, CtsProviderTestCases), ContentProvider işlemlerinin atomikliğini, izin denetimlerinin doğruluğunu ve ACTION_OPEN_DOCUMENT_TREE niyetinin (Intent) sistem dosya seçiciyle (System Picker) entegrasyonunu doğrular. Protokol seviyesinde, ContentProvider istemci-sunucu IPC (Binder) mekanizması üzerinden çalışır; veri taşıma ParcelFileDescriptor veya AssetFileDescriptor nesneleriyle gerçekleşir. Güvenlik modeli SELinux politikalarıyla (örneğin app_data_file etiketi) pekiştirilmiştir. Geliştiriciler için metodoloji; “Kendi Dizinler -> MediaStore -> SAF (Storage Access Framework)” hiyerarşik erişim stratejisini takip etmeyi önerir. requestLegacyExternalStorage="true" manifest bayrağı, Android 10 için geçici bir “opt-out” mekanizmasıydı ancak Android 11+ için CTS ve Play Policy tarafından tamamen devre dışı bırakılmıştır. Bu standartlar, ekosistem genelinde deterministik ve güvenli dosya erişimini garanti altına alır.

Bölüm 4: Önemli Parametreler ve Karşılaştırma Rehberi

Bölüm 5: Günlük Hayatta ve Doğada Nerede Karşımıza Çıkar?

Scoped Storage, tüketici elektroniği ekosisteminde kritik kullanım senaryolarını yeniden şekillendirmiştir. Fotoğraf Düzenleme Uygulamaları: Kullanıcı bir fotoğraf seçtiğinde ACTION_OPEN_DOCUMENT ile Uri alınır; ContentResolver.takePersistableUriPermission ile kalıcı izin alınır. Düzenleme sonucu yeni dosya MediaStore ile “Insert” edilir, orijinal dosya kullanıcı onayıyla silinir. Müzik Çalarlar: MediaStore.Audio sorgulanarak playlistler oluşturulur; dosya yolları asla saklanmaz, MediaStore.Audio.Media._ID veya content:// URI’leri kalıcı referans olarak tutulur. Kurumsal MDM (Mobile Device Management) Çözümleri: MANAGE_EXTERNAL_STORAGE izni ile cihaz genelinde dosya tarama, şifreleme veya uzaktan silme operasyonları gerçekleştirilir; bu süreç Google Play “Core Functionality” kriterlerine tabi tutulur. Yedekleme Uygulamaları: BackupAgent ve FileBackupHelper kullanılarak uygulama özel dizinleri (Android/data/...) yedeklenir; paylaşılan depolama için kullanıcı onaylı ACTION_OPEN_DOCUMENT_TREE ile kök dizin erişimi istenir. IoT Ağ Geçidi Uygulamaları: Cihaz log dosyaları (CSV, JSON) getExternalFilesDir(Environment.DIRECTORY_DOCUMENTS) altına yazılarak, kullanıcı dosya yöneticisiyle görebilir ama diğer uygulamalar erişemez. Bu senaryolar, “İzin Minimumu, İşlevsellik Maksimumu” prensibinin pratik kanıtlarıdır.

Bölüm 6: Karşılaşılan Zorluklar ve Pratik Çözümler

Ana operasyonel darboğaz Performans ve Karmaşıklık dengesidir. ContentResolver üzerindeki Binder IPC maliyeti, büyük dosya kopyalama/dönüştürme işlemlerinde (örn. 4K video edit) ana iş parçacığını (main thread) bloke edebilir. Çözüm: ExecutorService + ParcelFileDescriptor + FileChannel kullanılarak asenkron, akış tabanlı (streaming) I/O uygulanmalıdır. İkinci risk URI Kalıcılığı Kaybıdır; cihaz yeniden başlatıldığında takePersistableUriPermission alınmamışsa erişim kaybolur. Çözüm: onActivityResult içinde FLAG_GRANT_PERSISTABLE_URI_PERMISSION kontrolü ve ContentResolver.takePersistableUriPermission zorunlu kılınmalıdır. Üçüncü zorluk Medya Dosyası Güncelleme Atomikliğidir; MediaStore güncellemesi sırasında uygulama çökerse “Ghost” (hayalet) kayıtlar kalır. Çözüm: IS_PENDING=1 ile kayıt oluşturulur, dosya yazılır, sonra IS_PENDING=0 yapılır; OnFailureListener ile temizlik yapılır. Dördüncü risk MANAGE_EXTERNAL_STORAGE Reddidir; Play Store incelemesi “Dosya Yöneticisi” işlevi olmayan uygulamalarda reddeder. Çözüm: SAF (Storage Access Framework) ile kullanıcı merkezli erişim tasarlanmalı, “Tüm Dosyalara Erişim” hikayesi bırakılmalıdır. Beşinci zorluk Scoped Storage Geçiş Kod Karmaşıklığıdır (API 29/30/33+ farkları). Çözüm: androidx.core.content.FileProvider ve MediaStore sarmalayıcı (wrapper) kütüphaneleri (örn. ScopedStorageLibrary) ile soyutlama katmanı oluşturulmalıdır.

Bölüm 7: Gelecek Perspektifi ve Yeni Gelişmeler

Android 14 (API 34) ve 15 (VanillaIceCream) ile Scoped Storage, “Bölünmüş Depolama” (Partitioned Storage) ve “Sanal Dosya Sistemleri” (Virtual File Systems) kavramlarıyla bir sonraki evrimine geçmektedir. Granüler Medya İzinleri (Android 13+): READ_EXTERNAL_STORAGE yerini READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO almıştır; bu sayede bir uygulama sadece ses dosyalarına erişmek istiyorsa fotoğraf kütüphanesini okuyamaz. Photo Picker (Android 13+ Sistem Seçici): Uygulama hiçbir depolama izni istemeden (android.permission yok), sistem sağlayıcısı PhotoPicker activity’si üzerinden kullanıcı seçim yapar ve geçici content:// URI’si (grant flags ile) uygulamaya döner. Bu, “Sıfır İzin” (Zero Permission) hedefinin somutlaşmasıdır. Document-Centric Model: ACTION_OPEN_DOCUMENT_TREE ile verilen dizin erişimi, Android 14’te DocumentFile API’si üzerinden özyinelemeli (recursive) silme/taşıma işlemlerine izin vererek dosya yöneticisi deneyimini SAF içine taşımıştır. Gelecek 5-10 Yıllık Projeksiyon: Dosya sistemi tamamen “Capability-Based Security” (Yetenek Tabanlı Güvenlik) modeline evrilecektir. Ham dosya yolları (/storage/...) SDK seviyesinde tamamen gizlenecek, java.io.File API’leri ContentResolver/DocumentFile arayüzleriyle sarmalanacak veya deprecated edilecektir. Bulut tabanlı (Cloud-first) dosya sistemleri (CloudProvider API) yerel depolama ile birleşik ad alanı (unified namespace) oluşturacak, kullanıcı “nerede” değil “ne” (içerik/tür) sorgulayacaktır.

Bölüm 8: Merak Edilen Sorular ve Cevaplar

Soru 1: Android 11+ (API 30+) cihazlarda Environment.getExternalStorageDirectory() yöntemi neden null veya boş dizin döndürüyor?

Cevap: Android 11 ile getExternalStorageDirectory() ve getExternalStoragePublicDirectory() API’leri kullanımdan kaldırıldı (deprecated) ve işlevselliği kısıtlandı. Bu yöntemler artık uygulama özel dizini (Android/data/<package>/files) dışındaki paylaşılan alana (DCIM, Download vb.) ham dosya yolu (raw path) erişimi sağlamaz. Sistem, bu yöntemleri çağıran uygulamalara sadece kendi sandbox’ına işaret eden bir yol döndürür. Doğru yaklaşım: Medya için MediaStore, belgeler için ACTION_OPEN_DOCUMENT_TREE, kendi veriler için context.getExternalFilesDir(null) kullanılmalıdır.

Soru 2: MANAGE_EXTERNAL_STORAGE iznini almak için Google Play Store’dan onay almak zor mu?

Cevap: Evet, son derece zordur ve çoğu uygulama için reddedilir. Google Play Developer Policy (“Device and Network Abuse” ve “Core Functionality” maddeleri), bu izni sadece dosya yöneticileri, yedekleme/geri yükleme araçları, virüs tarayıcılar ve kurumsal MDM çözümleri gibi “temel işlevi cihaz genelinde dosya yönetimi olan” uygulamalara verir. Bir fotoğraf düzenleyici, müzik çalar veya e-ticaret uygulaması bu izni asla alamaz. Başvuru formunda “Core Functionality” videolu kanıt ve kullanıcı faydası analizi zorunludur; reddedilirse uygulama mağazadan kaldırılır.

Soru 3: Kullanıcı uygulamayı silip yeniden kurduğunda ACTION_OPEN_DOCUMENT_TREE ile alınan dizin erişimi kalıcı mıdır?

Cevap: Hayır, kalıcı değildir. Uygulama silindiğinde (uninstall), sistem o UID’ye ait tüm UriPermission kayıtlarını (grant flags) PackageManagerService veritabanından temizler. Yeniden kurulumda (re-install) yeni bir UID atanmaz (genelde aynı kalır) ancak izin veritabanı temizlendiği için takePersistableUriPermission ile alınan kalıcı izinler geçersiz olur. Uygulama başlangıcında ContentResolver.getPersistedUriPermissions() kontrolü yapıp, liste boşsa kullanıcıyı tekrar ACTION_OPEN_DOCUMENT_TREE akışına yönlendirmelidir.

Soru 4: MediaStore üzerinden bir video dosyası eklerken IS_PENDING=1 kullanmak neden kritiktir?

Cevap: IS_PENDING=1 (veya MediaStore.EXTRA_IS_PENDING), dosya yazma işlemi sırasında medya tarayıcılarının (Galeri, Google Photos) bu dosyayı görmesini ve işlemesini engeller. Büyük video dosyaları yazılırken (dakikalar sürebilir), IS_PENDING=0 (varsayılan) iken sistem MediaScanner bu kısmi dosyayı indeksler, bozuk thumbnail üretir veya kullanıcı yarım kalmış dosyayı görür. IS_PENDING=1 ile kayıt “gizli” tutulur, FileDescriptor kapatıldıktan sonra ContentValues ile IS_PENDING=0 güncellemesi yapılır; bu atomik geçiş dosya bütünlüğünü ve kullanıcı deneyimini garanti altına alır.

Soru 5: Scoped Storage ortamında FileProvider hala gerekli midir?

Cevap: Evet, hatta daha da kritiktir. FileProvider, uygulamanın özel dizinindeki (getExternalFilesDir(), getCacheDir()) dosyaları diğer uygulamalarla (Intent ACTION_VIEW, ACTION_SEND, ACTION_INSTALL_PACKAGE) paylaşmak için tek güvenli yoldur. Scoped Storage ham yolları yasakladığı için file:// URI’leri FileUriExposedException fırlatır. FileProvider content:// URI’si üretir, FLAG_GRANT_READ_URI_PERMISSION ile geçici, hedef uygulamaya özel erişim izni verir. Paylaşılan depolama (MediaStore) zaten content:// URI’si sunduğu için orada FileProvider gerekmez, ancak uygulama içi dosyalar için zorunludur.

Soru 6: Android 14 (API 34) PhotoPicker kullanırken uygulama manifest’e herhangi bir izin eklemek gerekir mi?

Cevap: Hayır, hiçbir izin (uses-permission) gerekmez. PhotoPicker (veya MediaStore.createPickRequest), sistem işlemi (com.google.android.providers.media.module / DocumentsUI) içinde çalışır. Kullanıcı seçim yaptığında, sistem geçici bir URI izni (temporary URI permission) Intent sonucunda (setDataAndType) hedef uygulamaya FLAG_GRANT_READ_URI_PERMISSION ile verir. Bu izin, uygulama süreci yaşadığı sürece (veya takePersistableUriPermission alınmazsa) geçerlidir. Bu, “Sıfır İzinli (Zero-Permission)” medya erişim modelinin tam bir uygulamasıdır.

Bölüm 9: Bilmeniz Gereken Temel Terimler

Scoped Storage (Kapsamlı Depolama): Android 10+ ile gelen, uygulamaların harici depolama alanına erişimini kendi dizinleri ve Medya Koleksiyonları (MediaStore) ile kısıtlayan, ham dosya yolu erişimini engelleyen güvenlik mimarisi.
MediaStore (Medya Sağlayıcısı): Ses, video, görüntü dosyalarını meta verileriyle (title, date, location, mime type) indeksleyen, ContentProvider arayüzüyle (content://media/external/…) uygulamalara SQL benzeri sorgu ve yazma erişimi sağlayan sistem veritabanı servisi.
Storage Access Framework (SAF / Depolama Erişim Çerçevesi): ACTION_OPEN_DOCUMENT, ACTION_CREATE_DOCUMENT, ACTION_OPEN_DOCUMENT_TREE niyetleri (Intents) aracılığıyla, kullanıcı onayıyla (System Picker) dosya/dizin erişimi sağlayan, DocumentsProvider alt yapısını kullanan çerçeve.
MANAGE_EXTERNAL_STORAGE (Tüm Dosyalara Erişim Yönetimi): Android 11+ ile gelen, uygulamaya tüm harici depolama alanına (diğer uygulamaların verileri hariç) ham yol ve listeleme erişimi veren, Google Play onayı ve kullanıcı “Ayarlar” onayı gerektiren yüksek riskli özel izin.
ContentResolver / ContentProvider (İçerik Çözücü/Sağlayıcı): Uygulama bileşenleri arası (IPC/Binder) veri paylaşımını soyutlayan, content:// URI şemasıyla adreslenebilen, güvenlik denetimleri (permission flags, grant flags) içeren standart veri erişim protokolü.
URI Permission (URI İzni): Bir content:// URI’sine erişim hakkını, Intent bayrakları (FLAG_GRANT_READ_URI_PERMISSION, FLAG_GRANT_PERSISTABLE_URI_PERMISSION) ile hedef uygulamaya geçici veya kalıcı olarak verme mekanizması.
IS_PENDING (Beklemede Bayrağı): MediaStore yazma işlemlerinde, dosya içeriği tamamen yazılana kadar medya tarayıcılarından ve diğer uygulamalardan gizli tutan, atomiklik sağlayan meta veri bayrağı (1: Gizli/Yazılıyor, 0: Yayında/Tamamlandı).

Bölüm 10: Özet ve Çıkarılması Gereken Dersler

Android Scoped Storage, mobil ekosistemdeki “gizlilik ilk” (privacy-first) paradigmasının dosya sistemine yansımasıdır; bu, bir teknik kısıtlama değil, veri egemenliği ve kullanıcı güveninin mimari taahhüdüdür. Analizlerimiz; ham dosya yollarının (java.io.File) yok edilmesi, MediaStore ve SAF üzerinden soyutlanmış, yetki tabanlı (capability-based) erişimin; veri sızıntısı yüzeyini (attack surface) minimize ettiğini, ancak geliştirme karmaşıklığını (IPC gecikmesi, URI yaşam döngüsü, izin matrisi) artırdığını ortaya koymaktadır. Kurumsal karar vericiler için stratejik yol haritası şöyledir: 1. Geçişi Tamamlayın: requestLegacyExternalStorage kodlarını tamamen temizleyin; API 33+ hedefleme zorunluluğu bu yolu kapatmıştır. 2. Sıfır İzin Hedefleyin: Yeni özelliklerde PhotoPicker (Android 13+) ve ActivityResultContracts kullanarak manifest’e READ_MEDIA_* izinleri eklemeyin. 3. Soyutlama Katmanı Yaratın: MediaStore, DocumentFile, FileProvider işlemlerini saran tek bir StorageRepository arayüzü uygulayın; bu, API seviyesi parçalanmasını (fragmentation) izole eder. 4. MANAGE_EXTERNAL_STORAGE‘dan Kaçının: Play Store politikası bu izni “son çare” olarak tanımlar; SAF dizin erişimi (ACTION_OPEN_DOCUMENT_TREE) ile kullanıcı kontrolünde kalın. 5. Test Stratejisini Güncelleyin: Cihaz çiftliği (Device Farm) testlerinde Android 10/11/13/14/15 özelinde izin akışları, URI kalıcılığı ve IS_PENDING atomikliği için otomasyon senaryoları yazın. Scoped Storage, Android’in “Linux dosya sistemi” mirasından “İçerik Odaklı İşletim Sistemi”ne evriminin kilit taşıdır; bu mimariyi benimseyen ekipler, gelecekte gelecek “Sanal Dosya Sistemleri” ve “Bulut Birleşimli Depolama” geçişinde sıfır maliyetle uyum sağlayacaktır.