Android 7.0 Davranış Değişiklikleri

Android 7.0, yeni özellikler ve özelliklerle birlikte çeşitli sistem ve API davranışı değişiklikleri içerir. Bu dokümanda, uygulamalarınızda anlamanız ve dikkate almanı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ü iyileştirmeyi 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 gizli intent'ler aracılığıyla diğer uygulamalarla etkileşim şeklini etkileyebilir.

Doz

Android 6.0'ta (API düzeyi 23) kullanıma sunulan Doze, kullanıcı cihazı fişten çıkardığında, sabit durumdayken ve ekran kapalıyken CPU ve ağ etkinliklerini erteleyerek pil ömrünü iyileştirir. Android 7.0, cihaz fişten çıkarılmış ve ekran kapalıyken (ancak sabit durumda olmayabilir, örneğin cep telefonu kullanıcının cebindeyken) CPU ve ağ kısıtlamalarının bir alt kümesini uygulayarak Doze'de daha da fazla iyileştirme sunar.

Doz'un, pil ömrünü uzatmak için ilk düzey sistem etkinliği kısıtlamalarını nasıl uyguladığını gösteren resim

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

Bir cihaz pil ile çalışıyorsa ve ekran belirli bir süre kapalıysa cihaz Uyku moduna girer ve ilk kısıtlama alt kümesini uygular: Uygulamanın ağ erişimini kapatır, görevleri ve senkronizasyonları erteler. Cihaz, Uyku moduna girdikten sonra belirli bir süre hareketsiz kalırsa sistem, Uyku modu kısıtlamalarının geri kalanını PowerManager.WakeLock, AlarmManager alarmları, GPS ve kablosuz taramalara uygular. Doz kısıtlamalarının bir kısmının veya tümünün uygulanmasından bağımsız olarak sistem, kısa bakım aralıkları için cihazı uyandırır. Bu sırada uygulamaların ağ erişimine izin verilir ve ertelenmiş işleri/senkronizasyonları yürütebilir.

Doz'un, cihaz belirli bir süre boyunca hareketsiz kaldıktan sonra ikinci bir sistem etkinliği kısıtlamalarını nasıl uyguladığını gösteren resim

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

Ekranı etkinleştirmenin veya cihazı takmanın Doz'dan çıkmasına neden olacağını ve bu işleme kısıtlamalarını kaldıracağını unutmayın. Bu ek davranış, Doze ve Uygulama Bekleme için Optimizasyon bölümünde ele alındığı gibi, uygulamanızı Android 6.0'da (API düzeyi 23) kullanıma sunulan Doze'in önceki sürümüne uyarlamayla ilgili önerileri ve en iyi uygulamaları etkilemez. Mesaj göndermek ve almak için Firebase Cloud Messaging (FCM) kullanmak gibi bu önerileri uygulamaya devam etmeniz ve ek Doze davranışına uyum sağlamak için güncelleme 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 üç örtülü yayını kaldırır. Bu değişiklik, gizli yayınlar genellikle arka planda dinlemek üzere kayıtlı olan uygulamaları başlattığı için gereklidir. Bu yayınların kaldırılması, cihaz performansı ve kullanıcı deneyimi açısından önemli avantajlar sağlayabilir.

Mobil cihazlarda, kablosuz ağ ve mobil veri arasında geçiş yaparken olduğu gibi sık sık bağlantı değişiklikleri yaşanır. Şu anda uygulamalar, manifest dosyalarında örtülü 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ı uyanmalarına ve yayını aynı anda işlemelerine neden olabilir.

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

Android 7.0, bu sorunları azaltmak 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, sınırsız ağa bağlantı gibi belirli koşullar karşılandığında ağ işlemlerini planlamak için güçlü bir mekanizma sağlar. İçerik sağlayıcılardaki değişikliklere tepki vermek için bile JobScheduler'ü kullanabilirsiniz.

Android 7.0'da (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ı bölümüne bakın.

İzin Değişiklikleri

Android 7.0, uygulamanızı etkileyebilecek izinlerde değişiklikler içerir.

Dosya sistemi izin değişiklikleri

Gizli dosyaların güvenliğini artırmak için, Android 7.0 veya sonraki sürümleri hedefleyen uygulamaların gizli dizini (0700) erişimi kısıtladı. Bu ayar, gizli dosyaların boyutu veya varlığı gibi meta verilerin 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'lerinin uygulamanızın dışında gösterilmesini yasaklayan StrictMode API politikasını uygular. Dosya URI'si 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 göndermeniz ve URI'de 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şımı 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ı deneyimindeki olası etkileri değerlendirmek için bu özellikleri inceleyip 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 Ekran boyutu ayarını yapmalarına olanak tanır. Bu sayede, az gören kullanıcılar için cihaz erişilebilirliği artırılır. Kullanıcılar ekranı, yaygın bir orta boy telefon olan Nexus 4'ün genişliği olan sw320dp minimum ekran genişliğinin ötesine yakınlaştıramaz.

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

Şekil 3. Sağdaki ekranda, Android 7.0 sistem resmi çalıştıran bir cihazın ekran boyutunun artırılmasının etkisi gösterilmektedir.

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

  • API düzeyi 23 veya altını hedefleyen bir uygulamanın tüm arka plan işlemleri sistem tarafından otomatik olarak sonlandırılır. Yani kullanıcı bu tür bir uygulamadan ayrılıp Ayarlar ekranını açarak Ekran boyutu ayarını değiştirirse sistem, uygulamayı hafıza düşük olduğunda yaptığı gibi kapatır. Uygulamanın ön planda çalışan işlemleri varsa sistem, Çalışma zamanı değişikliklerini işleme bölümünde açıklandığı gibi, bu işlemleri yapılandırma değişikliği konusunda bilgilendirir. Bu işlem, cihazın yönü değişmiş gibi yapılır.
  • Bir uygulama Android 7.0'ı hedefliyorsa (ön plan ve arka plan) Çalışma Zamanı Değişikliklerini İşleme bölümünde açıklandığı gibi, bu uygulamanın tüm işlemlerine (ön plan ve arka plan) bildirim gönderilir.

Android en iyi uygulamalarına uygun olduğu sürece çoğu uygulamanın bu özelliği desteklemek için değişiklik yapmasına gerek yoktur. Kontrol etmeniz 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, ağdan yüklenen kaynaklar veya önbelleğe alınmış bitmap'ler gibi yoğunluğa bağlı önbelleğe alınmış bilgileri 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ıyorsanız bu verilere uygun ekran boyutu veya piksel yoğunluğu gibi alakalı meta veriler eklemeniz önerilir. Bu meta verileri kaydetmek, yapılandırma değişikliğinden sonra önbelleğe alınan verileri yenilemeniz gerekip gerekmediğine karar vermenize olanak tanır.

  • Boyutları ekran yoğunluğuyla ölçeklendirilmediği için px birimleriyle belirtmekten kaçının. Bunun yerine, boyutları yoğunluktan bağımsız piksel (dp) birimleriyle belirtin.

Kurulum Sihirbazı'nda Görme Ayarları

Android 7.0'da, kullanıcıların yeni bir cihazda aşağıdaki erişilebilirlik ayarlarını yapabilecekleri Hoş Geldiniz ekranında Görme Ayarları bulunur: 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 ayarlarla etkinleştirerek test etmeniz gerekir. Ayarları Ayarlar > Erişilebilirlik bölümünde bulabilirsiniz.

Platform kitaplıklarına bağlanan NDK uygulamaları

Sistem, Android 7.0'dan itibaren uygulamaların NDK olmayan kitaplıklara dinamik olarak bağlantı vermesini önler. Bu durum, uygulamanızın kilitlenmesine neden olabilir. Bu davranış değişikliği, platform güncellemeleri ve farklı cihazlar arasında tutarlı bir uygulama deneyimi sunmayı amaçlamaktadır. Kodunuz özel kitaplıklara bağlanmıyor olsa da uygulamanızdaki bir üçüncü taraf statik kitaplık 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 doğrudan özel kitaplıklara erişmediğinden emin olsanız bile uygulamanızı bu senaryoya göre test etmeniz gerekir.
  • Uygulamanız, APK'sına dahil edilmeyen bir kitaplığa referans veriyor. Örneğin, kendi OpenSSL kopyanızı kullanmaya çalıştıysanız ancak uygulamanızın APK'sıyla birlikte paketlemeyi unuttuysanız bu durumla karşılaşabilirsiniz. Uygulama, Android platformunun libcrypto.so içeren sürümlerinde normal şekilde çalışabilir. Ancak uygulama, Android'in bu kitaplığı içermeyen sonraki 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 birlikte paketlediğinizden emin olun.

Android'in farklı sürümleri arasında değişebileceği veya kaldırılabileceği için uygulamalar NDK'ya dahil edilmeyen yerel kitaplıklar kullanmamalıdır. OpenSSL'den BoringSSL'ye geçiş bu tür bir değişikliğe örnek olarak verilebilir. Ayrıca, NDK'ya dahil edilmeyen platform kitaplıkları için uyumluluk koşulları olmadığından farklı cihazlar farklı uyumluluk düzeyleri sunabilir.

Bu kısıtlamanın şu anda yayınlanmış olan uygulamalar üzerindeki etkisini azaltmak amacıyla, API düzeyi 23 veya altını hedefleyen uygulamaların Android 7.0 (API düzeyi 24) sürümünde önemli ölçüde kullanım alanı olan kitaplık grubuna (ör. libandroid_runtime.so, libcutils.so, libcrypto.so ve libssl.so) geçici olarak erişilebilir. Uygulamanız bu kitaplıklardan birini yüklerse logcat bir uyarı oluşturur ve hedef cihazda sizi bilgilendirmek için bir pop-up gösterilir. Bu uyarıları görürseniz uygulamanızı bu kitaplıkların kendi kopyasını içerecek şekilde güncellemeniz veya yalnızca herkese açık NDK API'lerini kullanmanız 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.

Ne herkese açık ne de geçici olarak erişilebilir olan bir API'yi çağıran tüm uygulamalar çalışma zamanında hata oluşturur. Sonuç olarak, hem System.loadLibrary hem de dlopen(3) NULL döndürür ve uygulamanızın çökmesine neden olabilir. Özel platform API'lerinin kullanımını kaldırmak 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 etmek için uygulama kodunuzu gözden geçirmeniz gerekir. Uygulamanızın özel kitaplıklar kullanıp kullanmadığından emin değilseniz çalışma zamanı hatasını tespit etmek için logcat'i kontrol edebilirsiniz.

Aşağıdaki tabloda, özel yerel kitaplıkların kullanımına ve hedef API düzeyine (android:targetSdkVersion) bağlı olarak bir uygulamadan görmeyi beklemeniz gereken davranış açıklanmaktadır.

Kütüphaneler Hedef API düzeyi Dinamik bağlayıcı üzerinden çalışma zamanı erişimi Android 7.0 (API düzeyi 24) davranışı Gelecekteki Android platform davranışı
NDK Herkese Açık Tümü Erişilebilir Beklenen şekilde çalışıyor Beklenen şekilde çalışıyor
Özel (geçici olarak erişilebilen özel kitaplıklar) 23 veya daha düşük Geçici olarak erişilebilir Beklenen şekilde ç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 üzeri 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

Logcat, özel kitaplıkların yüklenmesi sırasındaki sorunları belirlemenize yardımcı olmak için uyarı veya çalışma zamanında hata oluşturabilir. Örneğin, uygulamanız API düzeyi 23 veya daha düşük bir sürümü hedefliyorsa ve Android 7.0 çalıştıran bir cihazdaki ö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ı gösterir ancak uygulamanızın kilitlenmesine neden olmaz. Ancak uygulama API düzeyi 24 veya üstünü hedefliyorsa logcat aşağıdaki çalışma zamanında hata 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, gizli platform API'lerine dinamik olarak bağlanan üçüncü taraf kitaplıkları kullanıyorsa bu logcat çıkışlarını da görebilirsiniz. Android 7.0DK'daki readelf aracı, aşağıdaki komutu çalıştırarak belirli bir .so dosyasının dinamik olarak bağlanmış tüm ortak 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ı burada bulabilirsiniz:

  • 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ık yazarıyla iletişime geçin.
  • NDK dışındaki tüm kitaplıklarınızı APK'nızla birlikte paketlediğinizden emin olun.
  • libandroid_runtime.so öğesindeki 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 tarafından sağlanan özel property_get sembolü yerine __system_property_get kullanın. Bunun için aşağıdaki dahil et ile __system_property_get kullanın: 
    #include <sys/system_properties.h>

    Not: Sistem özelliklerinin kullanılabilirliği ve içeriği, CTS aracılığıyla test edilmez. Bu özellikleri tamamen kullanmamak daha iyi bir çözümdür.

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

Android for Work

Android 7.0, sertifika yükleme, şifre sıfırlama, ikincil kullanıcı yönetimi ve cihaz tanımlayıcılarına erişim gibi Android for Work'u hedefleyen uygulamalarda yapılan değişiklikleri 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 ayarlamadan ö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ı denetleyicisi (DPC) DevicePolicyManager.setCertInstallerPackage() çağrısı yapmadan önce atanmış sertifika yükleyiciyi yüklemeniz gerekir. Yükleyici yüklü değilse sistem bir IllegalArgumentException oluşturur.
  • Cihaz yöneticileri için şifre sıfırlama kısıtlamaları artık profil sahipleri için de uygulanıyor. Cihaz yöneticileri artık şifreleri temizlemek veya önceden ayarlanmış şifreleri değiştirmek için DevicePolicyManager.resetPassword()'ü kullanamaz. Cihaz yöneticileri, şifre, PIN veya desen ayarlanmamış cihazlarda şifre ayarlamaya devam edebilir.
  • Cihaz ve profil sahipleri, kısıtlamalar belirlenmiş olsa bile hesapları yönetebilir. Cihaz sahipleri ve profil sahipleri, DISALLOW_MODIFY_ACCOUNTS kullanıcı kısıtlamaları uygulansa bile hesap yönetimi API'lerini çağırabilir.
  • Cihaz sahipleri, ikincil kullanıcıları daha kolay yönetebilir. Bir 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ı. Bunların yerine yeni DevicePolicyManager.createAndManageUser() yöntemi kullanılacak.
  • Cihaz sahipleri cihaz tanımlayıcılarına erişebilir. Cihaz sahibi, DevicePolicyManager.getWifiMacAddress()'ü kullanarak bir cihazın kablosuz MAC adresine erişebilir. Cihazda kablosuz bağlantı hiç etkinleştirilmediyse bu yöntem null değerini döndürür.
  • İş modu ayarı, iş uygulamalarına erişimi kontrol eder. Çalışma modu kapalıyken sistem başlatıcı, iş uygulamalarını devre dışı bırakarak kullanılamadığını belirtir. Çalışma modunu tekrar etkinleştirmek normal davranışı geri yükler.
  • Ayarlar kullanıcı arayüzünden bir istemci sertifikası zinciri ve ilgili özel anahtarı içeren bir PKCS #12 dosyası yüklenirken zincirdeki CA sertifikası artık güvenilir kimlik bilgileri depolama alanına yüklenmez. Bu durum, uygulamaların daha sonra istemci sertifika zincirini almaya çalıştığında KeyChain.getCertificateChain() sonucunu etkilemez. Gerekirse CA sertifikası, Ayarlar Kullanıcı Arayüzü aracılığıyla güvenilir kimlik bilgileri deposuna ayrıca, .crt veya .cer dosya uzantısı altında DER kodlamalı bir biçimde yüklenmelidir.
  • Android 7.0'dan itibaren, parmak izi kaydı ve depolama alanı kullanıcı başına yönetilmektedir. Profil sahibinin Device Policy İstemcisi (DPC) Android 7.0 (API düzeyi 24) çalıştıran bir cihazda API düzeyi 23'ü (veya altını) hedefliyorsa kullanıcı cihazda parmak izi ayarlamaya devam edebilir ancak iş uygulamaları cihaz parmak izine erişemez. DPC, API düzeyi 24 ve üzerini hedeflediğinde kullanıcı, Ayarlar > Güvenlik > İş profili güvenliği'ne giderek parmak izini yalnızca iş profili için ayarlayabilir.
  • DevicePolicyManager.getStorageEncryptionStatus() tarafından, şifrelemenin etkin olduğunu ve şifreleme anahtarının kullanıcıya bağlandığını belirtmek için yeni bir şifreleme durumu ENCRYPTION_STATUS_ACTIVE_PER_USER döndürülür. Yeni durum yalnızca DPC API düzeyi 24 ve üstünü 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, genellikle cihazın tamamını etkileyecek olan çeşitli yöntemler, cihazda ayrı bir iş isteği içeren bir iş profili yüklüyse farklı davranır. Bu yöntemler, cihazın tamamını etkilemek yerine yalnızca iş profili için geçerlidir. (Bu tür yöntemlerin tam listesini DevicePolicyManager.getParentProfileInstance() dokümanlarında bulabilirsiniz.) Örneğin, DevicePolicyManager.lockNow() tüm cihazı kilitlemek yerine yalnızca iş profilini kilitler. Bu yöntemlerin her biri için DevicePolicyManager üst örneğinde yöntemi çağırarak eski davranışı alabilirsiniz. DevicePolicyManager.getParentProfileInstance() çağrısı yaparak bu üst öğeyi alabilirsiniz. Örneğin, üst öğe örneğinin lockNow() metodunu çağırırsanız cihazın tamamı kilitlenir.

Ek Açıklamaların Saklanması

Android 7.0, ek açıklamaların görünürlüğünün göz ardı edildiği bir hatayı düzeltir. Bu sorun, çalışma zamanının erişememesi gereken ek açıklamalara erişmesini sağladı. Bu ek açıklamalar şunları içeriyordu:

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

Uygulamanız bu davranışı temel aldıysa lütfen çalışma zamanında sunulması gereken ek açıklamalara bir saklama politikası ekleyin. Bunu @Retention(RetentionPolicy.RUNTIME) kullanarak yapabilirsiniz.

TLS/SSL Varsayılan Yapılandırmasında Değişiklik

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

  • RC4 şifre paketleri artık devre dışı.
  • CHACHA20-POLY1305 şifre paketleri artık etkin.

RC4'ün varsayılan olarak devre dışı bırakılması, sunucu modern şifre paketleriyle pazarlık yapmadığında HTTPS veya TLS/SSL bağlantısında kesintilere neden olabilir. Tercih edilen çözüm, daha güçlü ve daha modern şifre paketleri ile protokolleri etkinleştirmek için sunucunun yapılandırmasını iyileştirmektir. İdeal olarak TLSv1.2 ve AES-GCM etkinleştirilmeli, İletim Gizliliği şifre 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 şifre paketlerine ek olarak sunucunun gerektirdiği şifre paketlerinin bazılarının etkin olduğu SSLSocket örneklerinin oluşturulması için tasarlanmalıdır.

Not: Bu değişiklikler WebView ile ilgili 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 için derlenen veya targetSdkVersion değerini Android 7.0 veya daha yeni bir sürüme ayarlayan uygulamalar, uygulama için geçerli olduğunda bu davranışları düzgün şekilde desteklemek üzere uygulamalarını değiştirmelidir.

Serileştirme Değişiklikleri

Android 7.0 (API düzeyi 24) sürümünde, varsayılan serialVersionUID değerinin hesaplanmasında spesifikasyonla eşleşmeyen bir hata düzeltildi.

Serializable sınıfını uygulayan ve açık bir serialVersionUID alanı belirtmeyen sınıfların varsayılan serialVersionUID değerinde bir değişiklik görülebilir. Bu değişiklik, sınıfın daha önceki bir sürümde serileştirilmiş veya daha önceki bir sürümü hedefleyen bir uygulama tarafından serileştirilmiş örneklerini seri dışı hale getirmeye çalışırken bir istisna atılmasına neden olur. Hata mesajı aşağıdaki gibi görünür: 

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

Bu sorunların düzeltilmesi, etkilenen tüm sınıflara hata mesajındaki stream classdesc serialVersionUID değeriyle bir serialVersionUID alanının eklenmesini gerektirir (ör. bu durumda 1234). Bu değişiklik, serileştirme kodu yazmaya yönelik 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 başlatıcı yönteminin bulunması veya bulunmaması, söz konusu sınıf için hesaplanan varsayılan serialVersionUID değerini etkiler. Hata düzeltmesinden önce, hesaplamada ayrıca statik başlatıcı için süper sınıf yoksa sınıf kontrol ediliyordu.

Bu değişikliğin, API düzeyi 23 veya daha düşük sürümleri hedefleyen uygulamaları, serialVersionUID alanı veya statik başlatıcı yöntemi olan sınıfları etkilemediğini belirtmek isteriz.

Diğer Önemli Noktalar

  • Android 7.0'da çalışan ancak daha düşük bir API düzeyini hedefleyen bir uygulamada kullanıcı ekran boyutunu değiştirdiğinde uygulama işlemi sonlandırılır. Uygulama bu senaryoyu sorunsuz bir şekilde yönetebilmelidir. Aksi takdirde kullanıcı, dosyayı 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. Uygulamayı DCM ile manuel olarak sonlandırırken aynı kilitlenmeye neden olarak bunu yapabilirsiniz.

    Android 7.0 (API düzeyi 24) ve sonraki sürümleri hedefleyen uygulamalar, yoğunluk değişikliklerinde otomatik olarak kapatı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 yönetebilmelidir ve sonraki başlatmalarda kilitlenmemelidir. Yazı tipi boyutunu değiştirerek (Ayarlar > Ekran > Yazı tipi boyutu) ve ardından 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ığında bir TCP soketine yazma işlemini katı mod ihlali olarak işaretlememiştir. Android 7.0 bu hatayı düzeltir. Bu davranışı sergileyen uygulamalar artık android.os.NetworkOnMainThreadException hatası veriyor. Ana iş parçacığında ağ işlemleri gerçekleştirmek genellikle kötü bir fikirdir çünkü bu işlemler genellikle ANR'lere ve gecikmelere neden olan yüksek bir gecikmeye neden olur.
  • Debug.startMethodTracing() yöntem ailesi artık varsayılan olarak çıkışı SD kartın üst düzeyinde değil, paylaşılan depolama alanındaki paketinize özel dizininizde depolar. Bu, uygulamaların artık bu API'leri kullanmak için WRITE_EXTERNAL_STORAGE izni istemesinin gerekmediği anlamına gelir.
  • Birçok platform API'si artık Binder işlemlerinde gönderilen büyük yükleri kontrol etmeye başladı ve sistem artık TransactionTooLargeExceptions öğelerini sessizce günlüğe kaydetmek veya bastırmak yerine RuntimeExceptions olarak yeniden gönderiyor. Sık karşılaşılan bir örnek, Activity.onSaveInstanceState() içinde çok fazla veri depolamaktır. Bu, uygulamanız Android 7.0'ı hedeflediğinde ActivityThread.StopInfo'un RuntimeException hatası vermesine neden olur.
  • Bir uygulama, Runnable görevlerini bir View'e gönderirse ve View bir pencereye bağlı değilse sistem, Runnable görevini View ile birlikte sıraya ekler. Runnable görevi, View bir pencereye bağlanana kadar yürütülmez. Bu davranışla aşağıdaki hatalar düzeltilir:
    • Bir uygulama, istenen pencerenin kullanıcı arayüzü iş parçacığı dışındaki bir iş parçacığından View'e yayınlanırsa Runnable yanlış iş parçacığında çalışabilir.
    • Runnable görevi, döngü oluşturucu ileti dizisi dışında bir iş parçacığından yayınlanmışsa uygulama, Runnable görevini kullanıma sunabilir.
  • Android 7.0'da DELETE_PACKAGES izini olan 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() işlevini çağırdığında STATUS_PENDING_USER_ACTION değerini döndürmeyi beklemelidir.
  • Tek algoritması SHA1PRNG olduğundan Crypto adlı JCA sağlayıcının desteği sonlandırıldı. Bu sağlayıcı artık kullanılamadığı için uygulamalar artık anahtar türetmek amacıyla (güvenli olmayan bir şekilde) SHA1PRNG kullanamaz. Daha fazla bilgi için Android N'de "Crypto" güvenlik sağlayıcısının desteği sonlandırıldı başlıklı blog yayınını inceleyin.