Android 7.0 Davranış Değişiklikleri

Android 7.0, yeni özellikler ve işlevlerin yanı sıra çeşitli sistem ve API davranışı değişiklikleri içerir. Bu belgede, uygulamalarınızda anlamanız ve hesaba katmanız gereken bazı önemli değişiklikler vurgulanmaktadır.

Daha önce Android için bir uygulama yayınladıysanız uygulamanızın platformdaki bu değişikliklerden etkilenebileceğini unutmayın.

Pil ve Bellek

Android 7.0, cihazların pil ömrünü uzatmayı ve RAM kullanımını azaltmayı amaçlayan sistem davranışı değişiklikleri içerir. Bu değişiklikler, uygulamanızın sistem kaynaklarına erişimini ve belirli örtük intent'leri kullanan diğer uygulamalarla etkileşimini etkileyebilir.

Doz

Android 6.0'da (API düzeyi 23) kullanıma sunulan Doze, kullanıcı cihazı fişe takılı değilken, sabitken ve ekran kapalıyken CPU ve ağ etkinliklerini erteleyerek pil ömrünü uzatır. Android 7.0, cihaz fişe takılı değilken ve ekran kapalıyken (ör. kullanıcı cihazı cebinde taşırken) CPU ve ağ kısıtlamalarının bir alt kümesini uygulayarak Doze'da daha fazla iyileştirme sunar.

Doze'un pil ömrünü uzatmak için sistem etkinliği kısıtlamalarının ilk seviyesini nasıl uyguladığını gösteren görsel

Şekil 1. Doze'un pil ömrünü uzatmak için sistem etkinliği kısıtlamalarının ilk seviyesini nasıl uyguladığını gösteren görsel.

Cihaz pille çalışırken ve ekran belirli bir süre kapalı kaldığında cihaz, Doze moduna girer ve ilk kısıtlama alt kümesini uygular: Uygulama ağı erişimini kapatır, işleri ve senkronizasyonları erteler. Cihaz, Doze moduna girdikten sonra belirli bir süre boyunca sabit kalırsa sistem, Doze kısıtlamalarının geri kalanını PowerManager.WakeLock, AlarmManager alarmları, GPS ve kablosuz ağ taramalarına uygular. Doze kısıtlamalarının bir kısmının mı yoksa tamamının mı uygulandığına bakılmaksızın sistem, cihazı kısa bakım pencereleri için uyandırır. Bu pencereler sırasında uygulamaların ağ erişimine izin verilir ve ertelenen işleri/senkronizasyonları yürütebilir.

Cihaz belirli bir süre hareketsiz kaldıktan sonra Doze'un ikinci düzey sistem etkinliği kısıtlamalarını nasıl uyguladığını gösteren görsel

Şekil 2. Cihaz belirli bir süre boyunca sabit kaldıktan sonra Doze'un ikinci düzey sistem etkinliği kısıtlamalarını nasıl uyguladığını gösteren görsel.

Ekranı etkinleştirmenin veya cihazı fişe takmanın Doze modundan çıkılmasına ve bu işleme kısıtlamalarının kaldırılmasına neden olacağını unutmayın. Ek davranış, Doze ve Uygulamayı Beklemeye Alma İçin Optimize Etme bölümünde açıklandığı gibi, uygulamanızı Android 6.0'da (API düzeyi 23) sunulan Doze'un önceki sürümüne uyarlama konusundaki önerileri ve en iyi uygulamaları etkilemez. Yine de mesaj gönderip almak için Firebase Cloud Messaging (FCM) kullanma gibi önerileri uygulamanız ve ek Doze davranışına uyum sağlamak için güncellemeler planlamaya başlamanız gerekir.

Project Svelte: Arka Plan Optimizasyonları

Android 7.0, hem bellek kullanımını hem de güç tüketimini optimize etmeye yardımcı olmak için üç dolaylı yayını kaldırır. Dolaylı yayınlar, arka planda kendilerini dinlemek üzere kaydolan uygulamaları sık sık başlattığı için bu değişiklik gereklidir. Bu yayınların kaldırılması, cihaz performansını ve kullanıcı deneyimini önemli ölçüde iyileştirebilir.

Mobil cihazlar, kablosuz ağ ve mobil veri arasında geçiş yaparken olduğu gibi sık sık bağlantı değişiklikleri yaşar. Şu anda uygulamalar, manifest dosyalarında dolaylı CONNECTIVITY_ACTION yayını için bir alıcı kaydederek bağlantıdaki değişiklikleri izleyebilir. Birçok uygulama bu yayını almak için kaydolduğundan tek bir ağ anahtarı, hepsinin uyanmasına ve yayını aynı anda işlemesine neden olabilir.

Benzer şekilde, Android'in önceki sürümlerinde uygulamalar, diğer uygulamalardan (ör. Kamera) dolaylı ACTION_NEW_PICTURE ve ACTION_NEW_VIDEO yayınları almak için kaydolabiliyordu. Kullanıcı, Kamera uygulamasıyla fotoğraf çektiğinde bu uygulamalar yayını işlemek için uyanır.

Android 7.0, bu sorunları hafifletmek için aşağıdaki optimizasyonları uygular:

Uygulamanız bu intent'lerden herhangi birini kullanıyorsa Android 7.0 cihazları düzgün bir şekilde hedefleyebilmek için bu intent'lere olan bağımlılıkları en kısa sürede kaldırmanız gerekir. Android çerçevesi, bu dolaylı yayınlara olan ihtiyacı azaltmak için çeşitli çözümler sunar. Örneğin, JobScheduler API'si, ölçüsüz bir ağa bağlantı gibi belirli koşullar karşılandığında ağ işlemlerini planlamak için güçlü bir mekanizma sağlar. Hatta içerik sağlayıcılardaki değişikliklere tepki vermek için JobScheduler kullanabilirsiniz.

Android 7.0'daki (API düzeyi 24) arka plan optimizasyonları ve uygulamanızı nasıl uyarlayacağınız hakkında daha fazla bilgi için Arka Plan Optimizasyonları başlıklı makaleyi inceleyin.

İzin Değişiklikleri

Android 7.0, uygulamanızı etkileyebilecek izin değişiklikleri içerir.

Dosya sistemi izin değişiklikleri

Özel dosyaların güvenliğini artırmak için Android 7.0 veya sonraki sürümleri hedefleyen uygulamaların özel dizinine erişim kısıtlanmıştır (0700). Bu ayar, özel dosyaların boyutu veya varlığı gibi meta verilerinin sızdırılmasını önler. Bu izin değişikliğinin birden fazla yan etkisi vardır:

Uygulamalar Arasında Dosya Paylaşma

Android 7.0'ı hedefleyen uygulamalarda Android çerçevesi, file:// URI'larının uygulamanızın dışında gösterilmesini yasaklayan StrictMode API politikasını zorunlu kılar. Dosya URI'sı içeren bir intent uygulamanızdan ayrılırsa uygulama FileUriExposedException istisnasıyla başarısız olur.

Uygulamalar arasında dosya paylaşmak için bir content:// URI'si göndermeniz ve URI'ye geçici erişim izni vermeniz gerekir. Bu izni vermenin en kolay yolu FileProvider sınıfını kullanmaktır. İzinler ve dosya paylaşımı hakkında daha fazla bilgi için Dosya Paylaşma başlıklı makaleyi inceleyin.

Yeni Erişilebilirlik Özellikleri

Android 7.0, az gören veya görme engelli kullanıcılar için platformun kullanılabilirliğini iyileştirmeyi amaçlayan değişiklikler içerir. Bu değişiklikler genellikle uygulamanızda kod değişikliği gerektirmez ancak kullanıcı deneyimi üzerindeki olası etkileri değerlendirmek için bu özellikleri incelemeniz ve uygulamanızla test etmeniz gerekir.

Ekran Yakınlaştırma

Android 7.0, kullanıcıların ekrandaki tüm öğeleri büyüten veya küçülten Görüntü boyutu'nu ayarlamasına olanak tanır. Böylece, az gören kullanıcılar için cihaz erişilebilirliği iyileştirilir. Kullanıcılar, ekranı sw320dp olan minimum ekran genişliğinin ötesine yakınlaştıramaz. Bu, yaygın olarak kullanılan orta boy bir telefon olan Nexus 4'ün genişliğidir.

Android 7.0 sistem görüntüsü çalıştıran cihazın yakınlaştırılmamış görüntü boyutunu gösteren ekran
Android 7.0 sistem görüntüsü çalıştıran bir cihazın görüntü boyutunu artırmanın etkisini gösteren ekran

Şekil 3. Sağdaki ekran, Android 7.0 sistem görüntüsü çalıştıran bir cihazın görüntü boyutunu artırmanın etkisini gösterir.

Cihaz yoğunluğu değiştiğinde sistem, çalışan uygulamaları aşağıdaki şekillerde bilgilendirir:

  • Bir uygulama hedef API düzeyi 23 veya daha altını hedefliyorsa sistem, uygulamanın tüm arka plan işlemlerini otomatik olarak sonlandırır. Bu, bir kullanıcı Ayarlar ekranını açmak için bu tür bir uygulamadan ayrılır ve Görüntü boyutu ayarını değiştirirse sistemin, uygulamayı düşük bellek durumunda olduğu gibi sonlandıracağı anlamına gelir. Uygulamanın ön plan işlemleri varsa sistem, Çalışma Zamanı Değişikliklerini İşleme bölümünde açıklandığı gibi, cihazın yönü değişmiş gibi bu işlemleri yapılandırma değişikliği hakkında bilgilendirir.
  • Bir uygulama Android 7.0'ı hedefliyorsa tüm işlemleri (ön plan ve arka plan), Çalışma Zamanı Değişikliklerini İşleme bölümünde açıklandığı gibi yapılandırma değişikliği hakkında bilgilendirilir.

Android'in en iyi uygulamalarına uyan çoğu uygulamanın bu özelliği desteklemek için herhangi bir değişiklik yapması gerekmez. Kontrol edilmesi gereken noktalar:

  • Uygulamanızı ekran genişliği sw320dp olan bir cihazda test edin ve yeterli performans gösterdiğinden emin olun.
  • Cihaz yapılandırması değiştiğinde, yoğunluğa bağlı önbelleğe alınmış bilgileri (ör. önbelleğe alınmış bitmap'ler veya ağdan yüklenen kaynaklar) güncelleyin. Uygulama duraklatılmış durumdan devam ettiğinde yapılandırma değişikliklerini kontrol edin.

    Not: Yapılandırmaya bağlı verileri önbelleğe alırsanız bu veriler için uygun ekran boyutu veya piksel yoğunluğu gibi alakalı meta verileri eklemeniz önerilir. Bu meta verileri kaydetmek, yapılandırma değişikliğinden sonra önbelleğe alınmış verileri yenilemeniz gerekip gerekmediğine karar vermenize olanak tanır.

  • Ekran yoğunluğuna göre ölçeklenmediğinden boyutları px birimleriyle belirtmekten kaçının. Bunun yerine, boyutları yoğunluktan bağımsız piksel (dp) birimleriyle belirtin.

Kurulum Sihirbazı'ndaki Görüş Ayarları

Android 7.0, kullanıcıların yeni bir cihazda şu erişilebilirlik ayarlarını yapabileceği Karşılama ekranında Görüş Ayarları'nı içerir: Büyütme hareketi, Yazı tipi boyutu, Görüntü boyutu ve TalkBack. Bu değişiklik, farklı ekran ayarlarıyla ilgili hataların görünürlüğünü artırır. Bu özelliğin etkisini değerlendirmek için uygulamalarınızı bu ayarlar etkinleştirilmiş olarak test etmeniz gerekir. Ayarları Ayarlar > Erişilebilirlik bölümünde bulabilirsiniz.

Platform Kitaplıklarına Bağlanan NDK Uygulamaları

Android 7.0'dan itibaren sistem, uygulamaların NDK olmayan kitaplıklara dinamik olarak bağlanmasını engeller. Bu durum, uygulamanızın kilitlenmesine neden olabilir. Davranıştaki bu değişiklik, platform güncellemeleri ve farklı cihazlar arasında tutarlı bir uygulama deneyimi oluşturmayı amaçlar. Kodunuz özel kitaplıklara bağlanmıyor olsa bile uygulamanızdaki üçüncü taraf statik kitaplıklar bunu yapıyor olabilir. Bu nedenle, tüm geliştiriciler uygulamalarının Android 7.0 çalıştıran cihazlarda kilitlenmediğinden emin olmalıdır. Uygulamanız yerel kod kullanıyorsa yalnızca herkese açık NDK API'lerini kullanmanız gerekir.

Uygulamanızın özel platform API'lerine erişmeye çalışmasının üç yolu vardır:

  • Uygulamanız doğrudan özel platform kitaplıklarına erişiyor. Uygulamanızı, bu kitaplıkların kendi kopyasını içerecek şekilde güncellemeniz veya herkese açık NDK API'lerini kullanmanız gerekir.
  • Uygulamanız, özel platform kitaplıklarına erişen bir üçüncü taraf kitaplığı kullanıyor. Uygulamanızın özel kitaplıklara doğrudan erişmediğinden emin olsanız bile uygulamanızı bu senaryo için test etmeniz gerekir.
  • Uygulamanız, APK'sında bulunmayan bir kitaplığa referans veriyor. Örneğin, OpenSSL'in kendi kopyanızı kullanmaya çalışıp uygulamanızın APK'sıyla paketlemeyi unuttuysanız bu durumla karşılaşabilirsiniz. Uygulama, libcrypto.so içeren Android platformu sürümlerinde normal şekilde çalışabilir. Ancak uygulama, bu kitaplığı içermeyen sonraki Android sürümlerinde (ör. Android 6.0 ve sonraki sürümler) kilitlenebilir. Bu sorunu düzeltmek için NDK dışındaki tüm kitaplıklarınızı APK'nızla paketlediğinizden emin olun.

Uygulamalar, NDK'ya dahil olmayan yerel kitaplıkları kullanmamalıdır. Bu kitaplıklar, Android'in farklı sürümleri arasında değişebilir veya kaldırılabilir. OpenSSL'den BoringSSL'ye geçiş bu tür bir değişikliğe örnektir. Ayrıca NDK'ya dahil olmayan platform kitaplıkları için uyumluluk şartları olmadığından farklı cihazlar farklı uyumluluk düzeyleri sunabilir.

Bu kısıtlamanın şu anda yayınlanmış uygulamalar üzerindeki etkisini azaltmak için, libandroid_runtime.so, libcutils.so, libcrypto.so ve libssl.so gibi önemli ölçüde kullanılan bir dizi kitaplığa, hedef API düzeyi 23 veya daha düşük sürümleri hedefleyen uygulamalar için Android 7.0'da (API düzeyi 24) geçici olarak erişilebilir. Uygulamanız bu kitaplıklardan birini yüklerse logcat bir uyarı oluşturur ve hedef cihazda sizi bilgilendiren bir pop-up mesaj gösterilir. Bu uyarıları görürseniz uygulamanızı, bu kitaplıkların kendi kopyasını içerecek veya yalnızca herkese açık NDK API'lerini kullanacak şekilde güncellemeniz gerekir. Android platformunun gelecekteki sürümleri, özel kitaplıkların kullanımını tamamen kısıtlayabilir ve uygulamanızın kilitlenmesine neden olabilir.

Tüm uygulamalar, herkese açık olmayan veya geçici olarak erişilemeyen bir API'yi çağırdığında çalışma zamanı hatası oluşturur. Sonuç olarak System.loadLibrary ve dlopen(3), NULL değerini döndürür ve uygulamanızın kilitlenmesine neden olabilir. Özel platform API'lerinin kullanımını kaldırmak için uygulama kodunuzu incelemeniz ve Android 7.0 (API düzeyi 24) çalıştıran bir cihaz veya emülatör kullanarak uygulamalarınızı kapsamlı bir şekilde test etmeniz gerekir. Uygulamanızın özel kitaplıklar kullanıp kullanmadığından emin değilseniz çalışma zamanı hatasını belirlemek için logcat'i kontrol edebilirsiniz.

Aşağıdaki tabloda, özel yerel kitaplıkları kullanmasına ve hedef API düzeyine (android:targetSdkVersion) bağlı olarak bir uygulamadan bekleyebileceğiniz davranışlar açıklanmaktadır.

Kütüphaneler Hedef API düzeyi Dinamik bağlayıcı kullanarak çalışma zamanı erişimi Android 7.0 (API düzeyi 24) davranışı Android platformunun gelecekteki işleyişi
NDK Public Tümü Erişilebilir Beklendiği gibi çalışıyor Beklendiği gibi çalışıyor
Özel (geçici olarak erişilebilen özel kitaplıklar) 23 veya daha az Geçici olarak erişilebilir Beklendiği gibi çalışır ancak bir logcat uyarısı alırsınız. Çalışma zamanı hatası
Özel (geçici olarak erişilebilen özel kitaplıklar) 24 veya daha yüksek Kısıtlanmış Çalışma zamanı hatası Çalışma zamanı hatası
Özel (diğer) Tümü Kısıtlanmış Çalışma zamanı hatası Çalışma zamanı hatası

Uygulamanızın özel kitaplıklar kullanıp kullanmadığını kontrol etme

Özel kitaplıkları yüklemeyle ilgili sorunları belirlemenize yardımcı olmak için logcat bir uyarı veya çalışma zamanı hatası oluşturabilir. Örneğin, uygulamanız hedef API düzeyi 23 veya daha düşük bir sürümü hedefliyorsa ve Android 7.0 çalıştıran bir cihazda özel bir kitaplığa erişmeye çalışıyorsa aşağıdakine benzer bir uyarı görebilirsiniz: 

03-21 17:07:51.502 31234 31234 W linker  : library "libandroid_runtime.so"
("/system/lib/libandroid_runtime.so") needed or dlopened by
"/data/app/com.popular-app.android-2/lib/arm/libapplib.so" is not accessible
for the namespace "classloader-namespace" - the access is temporarily granted
as a workaround for http://b/26394120

Bu logcat uyarıları, hangi kitaplığın özel bir platform API'sine erişmeye çalıştığını bildirir ancak uygulamanızın kilitlenmesine neden olmaz. Ancak uygulama hedef API düzeyi 24 veya daha yüksek bir sürümü hedefliyorsa Logcat aşağıdaki çalışma zamanı hatasını oluşturur ve uygulamanız kilitlenebilir: 

java.lang.UnsatisfiedLinkError: dlopen failed: library "libcutils.so"
("/system/lib/libcutils.so") needed or dlopened by
"/system/lib/libnativeloader.so" is not accessible for the namespace
"classloader-namespace"
  at java.lang.Runtime.loadLibrary0(Runtime.java:977)
  at java.lang.System.loadLibrary(System.java:1602)

Uygulamanız özel platform API'lerine dinamik olarak bağlanan üçüncü taraf kitaplıkları kullanıyorsa da bu logcat çıkışlarını görebilirsiniz. Android 7.0 NDK'daki readelf aracı, aşağıdaki komutu çalıştırarak belirli bir .so dosyasının dinamik olarak bağlanmış tüm paylaşılan kitaplıklarının listesini oluşturmanıza olanak tanır: 

aarch64-linux-android-readelf -dW libMyLibrary.so

Uygulamanızı güncelleme

Bu tür hataları düzeltmek ve uygulamanızın gelecekteki platform güncellemelerinde kilitlenmemesini sağlamak için uygulayabileceğiniz bazı adımlar şunlardır:

  • Uygulamanız özel platform kitaplıkları kullanıyorsa bu kitaplıkların kendi kopyasını içerecek şekilde güncellemeniz veya herkese açık NDK API'lerini kullanmanız gerekir.
  • Uygulamanız özel simgelere erişen bir üçüncü taraf kitaplığı kullanıyorsa kitaplığı güncellemek için kitaplığın yazarıyla iletişime geçin.
  • NDK dışındaki tüm kitaplıklarınızı APK'nızla paketlediğinizden emin olun.
  • libandroid_runtime.so içindeki getJavaVM ve getJNIEnv yerine standart JNI işlevlerini kullanın: 
    AndroidRuntime::getJavaVM -> GetJavaVM from <jni.h>
AndroidRuntime::getJNIEnv -> JavaVM::GetEnv or
JavaVM::AttachCurrentThread from <jni.h>.
  • libcutils.so içindeki özel property_get simgesi yerine __system_property_get kullanın. Bunun için aşağıdaki include ile __system_property_get kullanın: 
    #include <sys/system_properties.h>

    Note: Sistem özelliklerinin kullanılabilirliği ve içeriği CTS aracılığıyla test edilmez. Daha iyi bir çözüm, bu özellikleri kullanmaktan tamamen kaçınmak olacaktır.

  • libcrypto.so bölgesindeki SSL_ctrl simgesinin yerel sürümünü kullanın. Örneğin, .so dosyanızda libcyrpto.a öğesini statik olarak bağlamanız veya BoringSSL/OpenSSL'den libcrypto.so öğesinin dinamik olarak bağlanmış bir sürümünü ekleyip APK'nızda paketlemeniz gerekir.

Android for Work

Android 7.0, Android for Work'ü hedefleyen uygulamalar için sertifika yükleme, şifre sıfırlama, ikincil kullanıcı yönetimi ve cihaz tanımlayıcılarına erişimle ilgili değişiklikler içerir. Android for Work ortamları için uygulama geliştiriyorsanız bu değişiklikleri incelemeniz ve uygulamanızı buna göre değiştirmeniz gerekir.

  • DPC'nin ayarlayabilmesi için önce yetki verilmiş bir sertifika yükleyici yüklemeniz gerekir. Android 7.0'ı (API düzeyi 24) hedefleyen hem profil hem de cihaz sahibi uygulamaları için cihaz politikası denetleyici (DPC) DevicePolicyManager.setCertInstallerPackage() yöntemini çağırmadan önce yetkilendirilmiş sertifika yükleyiciyi yüklemeniz gerekir. Yükleyici henüz yüklenmemişse sistem IllegalArgumentException hatası verir.
  • Cihaz yöneticileri için şifre sıfırlama kısıtlamaları artık profil sahipleri için de geçerlidir. Cihaz yöneticileri artık şifreleri temizlemek veya önceden ayarlanmış şifreleri değiştirmek için DevicePolicyManager.resetPassword() kullanamaz. Cihaz yöneticileri şifre belirlemeye devam edebilir ancak bu yalnızca cihazda şifre, PIN veya desen olmadığında mümkündür.
  • Cihaz ve profil sahipleri, kısıtlamalar ayarlanmış olsa bile hesapları yönetebilir. Cihaz sahipleri ve profil sahipleri, DISALLOW_MODIFY_ACCOUNTS kullanıcı kısıtlamaları geçerli olsa bile Hesap Yönetimi API'lerini çağırabilir.
  • Cihaz sahipleri ikincil kullanıcıları yönetebilir. Cihaz, cihaz sahibi modunda çalışırken DISALLOW_ADD_USER kısıtlaması otomatik olarak ayarlanır. Bu, kullanıcıların yönetilmeyen ikincil kullanıcılar oluşturmasını engeller. Ayrıca CreateUser() ve createAndInitializeUser() yöntemlerinin desteği sonlandırıldı. Bu yöntemlerin yerini yeni DevicePolicyManager.createAndManageUser() yöntemi aldı.
  • Cihaz sahipleri, cihaz tanımlayıcılarına erişebilir. Cihaz sahibi, DevicePolicyManager.getWifiMacAddress() kullanarak cihazın kablosuz MAC adresine erişebilir. Cihazda kablosuz bağlantı hiç etkinleştirilmemişse bu yöntem null değerini döndürür.
  • İş modu ayarı, iş uygulamalarına erişimi kontrol eder. İş modu kapalıyken sistem başlatıcı, iş uygulamalarını devre dışı bırakarak kullanılamadıklarını gösterir. İş modunu tekrar etkinleştirdiğinizde normal davranış geri yüklenir.
  • İstemci sertifikası zinciri ve ilgili özel anahtarı içeren bir PKCS #12 dosyası Ayarlar kullanıcı arayüzünden yüklenirken zincirdeki CA sertifikası artık güvenilir kimlik bilgileri deposuna yüklenmez. Bu durum, uygulamalar daha sonra istemci sertifika zincirini almaya çalıştığında KeyChain.getCertificateChain() sonucunu etkilemez. Gerekirse CA sertifikası, Ayarlar kullanıcı arayüzü kullanılarak ayrı bir şekilde, .crt veya .cer dosya uzantısı altında DER kodlu bir biçimle güvenilir kimlik bilgileri deposuna yüklenmelidir.
  • Android 7.0'dan itibaren parmak izi kaydı ve depolama alanı kullanıcı başına yönetilir. Profil sahibinin Cihaz Politikası İstemcisi (DPC), Android 7.0 (API düzeyi 24) çalıştıran bir cihazda API düzeyi 23'ü (veya daha düşük bir düzeyi) hedefliyorsa kullanıcı cihazda parmak izi ayarlayabilir ancak iş uygulamaları cihazın parmak izine erişemez. DPC, API düzeyi 24 ve üstünü hedeflediğinde kullanıcı, Ayarlar > Güvenlik > İş profili güvenliği'ne giderek iş profiline özel parmak izi ayarlayabilir.
  • DevicePolicyManager.getStorageEncryptionStatus(), şifrelemenin etkin olduğunu ve şifreleme anahtarının kullanıcıya bağlı olduğunu belirtmek için yeni bir şifreleme durumu (ENCRYPTION_STATUS_ACTIVE_PER_USER) döndürür. Yeni durum yalnızca DPC, API düzeyi 24 ve sonraki sürümleri hedefliyorsa döndürülür. Daha önceki API düzeylerini hedefleyen uygulamalarda, şifreleme anahtarı kullanıcıya veya profile özel olsa bile ENCRYPTION_STATUS_ACTIVE döndürülür.
  • Android 7.0'da, normalde tüm cihazı etkileyen çeşitli yöntemler, cihazda ayrı bir iş sorgulamasıyla yüklenmiş bir iş profili varsa farklı şekilde davranır. Bu yöntemler, cihazın tamamını etkilemek yerine yalnızca iş profilinde geçerli olur. (Bu tür yöntemlerin tam listesi DevicePolicyManager.getParentProfileInstance() dokümanlarında yer alır.) Örneğin, DevicePolicyManager.lockNow() cihazın tamamını kilitlemek yerine yalnızca iş profilini kilitler. Bu yöntemlerin her biri için DevicePolicyManager öğesinin üst örneğinde yöntemi çağırarak eski davranışı elde edebilirsiniz. Bu üst öğeyi DevicePolicyManager.getParentProfileInstance() yöntemini çağırarak alabilirsiniz. Örneğin, üst örneğin lockNow() yöntemini çağırırsanız cihazın tamamı kilitlenir.

Notları Saklama

Android 7.0, notların görünürlüğünün yoksayılmasına neden olan bir hatayı düzeltir. Bu sorun, çalışma zamanının erişmemesi gereken ek açıklamalara erişmesine olanak tanıyordu. Bu ek açıklamalar şunları içeriyordu:

  • VISIBILITY_BUILD: Yalnızca derleme zamanında görünür olması amaçlanmıştır.
  • VISIBILITY_SYSTEM: Çalışma zamanında görünür olması amaçlanır ancak yalnızca temel sistem tarafından görülebilir.

Uygulamanız bu davranışa dayanıyorsa çalışma zamanında kullanılabilir olması gereken ek açıklamalara bir saklama politikası ekleyin. Bunu yapmak için @Retention(RetentionPolicy.RUNTIME) kullanırsınız.

TLS/SSL Varsayılan Yapılandırma Değişiklikleri

Android 7.0, uygulamaların HTTPS ve diğer TLS/SSL trafiği için kullandığı varsayılan TLS/SSL yapılandırmasında aşağıdaki değişiklikleri yapar:

  • RC4 şifre paketleri artık devre dışı bırakıldı.
  • CHACHA20-POLY1305 şifreleme paketleri artık etkin.

RC4'ün varsayılan olarak devre dışı bırakılması, sunucu modern şifre paketlerini kabul etmediğinde HTTPS veya TLS/SSL bağlantısında kesintilere neden olabilir. Tercih edilen çözüm, sunucunun yapılandırmasını daha güçlü ve daha modern şifreleme paketlerini ve protokollerini etkinleştirecek şekilde iyileştirmektir. İdeal olarak TLSv1.2 ve AES-GCM etkinleştirilmeli, İleri Gizlilik şifreleme paketleri (ECDHE) etkinleştirilmeli ve tercih edilmelidir.

Alternatif olarak, uygulamayı sunucuyla iletişim kurmak için özel bir SSLSocketFactory kullanacak şekilde değiştirebilirsiniz. Fabrika, varsayılan şifreleme paketlerine ek olarak sunucunun gerektirdiği şifreleme paketlerinden bazılarının etkinleştirildiği SSLSocket örnekleri oluşturacak şekilde tasarlanmalıdır.

Not: Bu değişiklikler WebView için geçerli değildir.

Android 7.0'ı hedefleyen uygulamalar

Bu davranış değişiklikleri yalnızca Android 7.0 (API düzeyi 24) veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir. Android 7.0'a göre derlenen veya targetSdkVersion değerini Android 7.0 ya da sonraki bir sürüme ayarlayan uygulamalar, bu davranışları düzgün şekilde desteklemek için uygulamalarını değiştirmelidir (uygulama için geçerliyse).

Serileştirme Değişiklikleri

Android 7.0 (API düzeyi 24), varsayılan serialVersionUID hesaplamasında spesifikasyonla eşleşmeyen bir hatayı düzeltti.

Serializable uygulayan ve açık bir serialVersionUID alanı belirtmeyen sınıfların varsayılan serialVersionUID değerinde değişiklik görülebilir. Bu durum, sınıfın önceki bir sürümde veya önceki bir sürümü hedefleyen bir uygulama tarafından serileştirilmiş örneklerinin serileştirilmesi kaldırılmaya çalışıldığında istisna oluşturulmasına neden olur. Hata mesajı şuna benzer: 

local class incompatible: stream classdesc serialVersionUID = 1234, local class serialVersionUID = 4567

Bu sorunları düzeltmek için etkilenen tüm sınıflara, hata mesajındaki stream classdesc serialVersionUID değerini içeren bir serialVersionUID alanı eklemeniz gerekir (ör. bu durumda 1234). Bu değişiklik, serileştirme kodu yazmayla ilgili tüm iyi uygulama önerilerine uygundur ve Android'in tüm sürümlerinde çalışır.

Düzeltilen hata, statik başlatıcı yöntemlerinin (ör. <clinit>) varlığıyla ilgiliydi. Spesifikasyona göre, sınıfta statik bir başlatıcı yönteminin bulunup bulunmaması, o sınıf için hesaplanan varsayılan serialVersionUID'yi etkiler. Hata düzeltilmeden önce, bir sınıfın statik başlatıcısı yoksa hesaplama sırasında üst sınıfta statik başlatıcı olup olmadığı da kontrol ediliyordu.

Açıklamak gerekirse bu değişiklik, API düzeyi 23 veya daha düşük olan uygulamaları, serialVersionUID alanı olan sınıfları ya da statik başlatıcı yöntemi olan sınıfları etkilemez.

Diğer Önemli Noktalar

  • Bir uygulama Android 7.0'da çalışıyor ancak daha düşük bir API düzeyini hedefliyorsa ve kullanıcı görüntü boyutunu değiştirirse uygulama işlemi sonlandırılır. Uygulama bu senaryoyu sorunsuz bir şekilde yönetebilmelidir. Aksi takdirde, kullanıcı uygulamayı Son Kullanılanlar'dan geri yüklediğinde kilitlenir.

    Bu davranışın gerçekleşmediğinden emin olmak için uygulamanızı test etmeniz gerekir. Bunu, DDMS kullanarak uygulamayı manuel olarak sonlandırırken aynı kilitlenmeye neden olarak yapabilirsiniz.

    Android 7.0 (API düzeyi 24) ve sonraki sürümleri hedefleyen uygulamalar, yoğunluk değişikliklerinde otomatik olarak sonlandırılmaz ancak yapılandırma değişikliklerine yine de kötü yanıt verebilir.

  • Android 7.0'daki uygulamalar, yapılandırma değişikliklerini sorunsuz bir şekilde işleyebilmeli ve sonraki başlatmalarda kilitlenmemelidir. Yazı tipi boyutunu değiştirip (Ayarlar > Ekran > Yazı tipi boyutu) uygulamayı Son Kullanılanlar'dan geri yükleyerek uygulama davranışını doğrulayabilirsiniz.
  • Android'in önceki sürümlerindeki bir hata nedeniyle sistem, ana iş parçacığındaki bir TCP soketine yazma işlemini yüksek düzey modu ihlali olarak işaretlemiyordu. Android 7.0 bu hatayı düzeltir. Bu davranışı sergileyen uygulamalar artık android.os.NetworkOnMainThreadException hatası veriyor. Ağ işlemlerini ana iş parçacığında gerçekleştirmek genellikle iyi bir fikir değildir. Bu işlemler genellikle yüksek gecikme süresine sahip olduğundan ANR'lere ve takılmalara neden olur.
  • Debug.startMethodTracing() yöntem ailesi artık çıkışı SD kartın üst düzey dizini yerine paylaşılan depolama alanındaki paketinize özel dizinde depolar. Bu, uygulamaların bu API'leri kullanmak için artık WRITE_EXTERNAL_STORAGE izni istemesine gerek olmadığı anlamına gelir.
  • Birçok platform API'si artık Binder işlemleri arasında gönderilen büyük yükleri kontrol etmeye başladı. Sistem artık TransactionTooLargeExceptions öğesini sessizce günlüğe kaydetmek veya gizlemek yerine RuntimeExceptions olarak yeniden oluşturuyor. Sık karşılaşılan örneklerden biri, Activity.onSaveInstanceState() içinde çok fazla veri depolanmasıdır. Bu durum, uygulamanız Android 7.0'ı hedeflediğinde ActivityThread.StopInfo'nin RuntimeException hatası vermesine neden olur.
  • Bir uygulama Runnable görevlerini bir View öğesine gönderirse ve View bir pencereye eklenmezse sistem, Runnable görevini View ile sıraya alır. Runnable görevi, View bir pencereye eklenene kadar yürütülmez. Bu davranış aşağıdaki hataları düzeltir:
    • Bir uygulama, amaçlanan pencerenin kullanıcı arayüzü iş parçacığı dışında bir iş parçacığından View öğesine gönderim yaptıysa Runnable, sonuç olarak yanlış iş parçacığında çalışabilir.
    • Runnable görevi, döngüleyici iş parçacığı dışında bir iş parçacığından yayınlandıysa uygulama, Runnable görevini açığa çıkarabilir.
  • Android 7.0'da DELETE_PACKAGES iznine sahip bir uygulama bir paketi silmeye çalışırsa ancak bu paketi farklı bir uygulama yüklediyse sistem, kullanıcı onayı ister. Bu senaryoda uygulamalar, PackageInstaller.uninstall() yöntemini çağırdıklarında dönüş durumu olarak STATUS_PENDING_USER_ACTION değerini beklemelidir.
  • Crypto adlı JCA sağlayıcısının tek algoritması olan SHA1PRNG, şifreleme açısından zayıf olduğu için bu sağlayıcının desteği sonlandırıldı. Bu sağlayıcı artık kullanılamadığından uygulamalar, anahtarları (güvenli olmayan bir şekilde) türetmek için SHA1PRNG'yi kullanamaz. Daha fazla bilgi için Android N'de güvenlik "kripto" sağlayıcısı desteğinin sonlandırılması başlıklı blog yayınına bakın.