Android 7.0 Davranış Değişiklikleri

Android 7.0, yeni özellikler ve özelliklerin yanı sıra çeşitli sistem ve API davranışı değişiklikleri içerir. Bu dokümanda, 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şiminin yanı sıra belirli örtülü amaçlar üzerinden diğer uygulamalarla etkileşim kurma biçimini de etkileyebilir.

Doz

Android 6.0'da (API düzeyi 23) kullanıma sunulan Doz, kullanıcı cihazı fişe takılı değilken, hareketsizken ve ekranı kapalıyken cihaz üzerinde bıraktığında CPU ve ağ etkinliklerini erteleyerek pil ömrünü iyileştirir. Android 7.0, cihazın fişi takılı değilken CPU ve ağ kısıtlamalarının bir alt kümesini uygulayarak Doz'a daha fazla geliştirme getirir ve cihaz örneğin ekran kapalıyken hareket eder.

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

Şekil 1. Doz'un, pil ömrünü iyileştirmek için ilk seviye sistem etkinliği kısıtlamalarını nasıl uyguladığını gösteren resim.

Bir cihaz pille çalışırken ve ekranı belirli bir süre kapalı kaldığında, cihaz Doz'a girer ve ilk kısıtlama alt kümesini uygular: Uygulama ağ erişimini kapatır, işleri erteler ve senkronizasyonlar ertelenir. Doz'a girdikten sonra cihaz belirli bir süre hareketsiz kalırsa sistem, geri kalan Doz kısıtlamalarını PowerManager.WakeLock, AlarmManager alarm, GPS ve kablosuz ağ taramalarına uygular. Sistem, Doz kısıtlamalarının bir kısmının veya tamamının uygulanmasına bakılmaksızın, kısa bakım dönemlerinde cihazı uyandırır. Bu bakım sırasında uygulamalara ağ erişimine izin verilir ve ertelenmiş tüm işleri/senkronizasyonları yürütebilirsiniz.

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

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

Ekranı etkinleştirdiğinizde veya cihaz fişe takıldığında Doz'dan çıkılacağını ve bu işleme kısıtlamalarının kaldırılacağını unutmayın. Ek davranış, Doz ve Uygulamayı Beklemeye Alma için Optimize Etme bölümünde açıklandığı gibi, uygulamanızı Android 6.0'da (API düzeyi 23) kullanıma sunulan önceki Doz sürümüne uyarlamayla ilgili önerileri ve en iyi uygulamaları etkilemez. Mesaj gönderip almak için Firebase Cloud Messaging (FCM) kullanmak ve ek Doz davranışına uyum sağlamak için güncellemeler planlamaya başlamak gibi bu önerileri uygulamaya devam etmeniz gerekir.

Svelte Projesi: 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. Örtülü yayınlar genellikle, arka planda kendilerini dinlemek üzere kaydolmuş uygulamaları başlattığından bu değişiklik gereklidir. Bu yayınların kaldırılması cihaz performansı ve kullanıcı deneyimini önemli ölçüde artırabilir.

Mobil cihazlarda kablosuz ağ ve mobil veri arasında geçiş yapma gibi sık sık bağlantı değişiklikleri meydana gelir. Şu anda uygulamalar, manifest dosyasındaki dolaylı CONNECTIVITY_ACTION yayını için bir alıcı kaydederek bağlantıdaki değişiklikleri izleyebiliyor. Birçok uygulama bu yayını almak için kaydolduğundan, tek bir ağ anahtarı tüm uygulamaların uyanmasına ve yayını aynı anda işlemesine neden olabilir.

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

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

Uygulamanız bu amaçlardan birini kullanıyorsa Android 7.0 cihazları düzgün bir şekilde hedefleyebilmek için bu amaçlara olan bağımlılıkları en kısa sürede kaldırmalısınız. Android çerçevesi, bu dolaylı yayınlara olan ihtiyacı azaltmak için çeşitli çözümler sunar. Örneğin JobScheduler API, belirtilen koşullar (ör. sınırsız bir ağa bağlanma) karşılandığında ağ işlemlerini planlamak için sağlam bir mekanizma sağlar. İçerik sağlayıcılarda yapılan değişikliklere tepki vermek için de JobScheduler kullanabilirsiniz.

Android 7.0'da arka plan optimizasyonları (API düzeyi 24) ve uygulamanızı nasıl uyarlayacağınız hakkında daha fazla bilgi edinmek için Arka Plan Optimizasyonları bölümüne bakın.

İzin Değişiklikleri

Android 7.0, uygulamanızı etkileyebilecek izin değişikliklerini 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 özel uygulama dizininin erişimi kısıtlıdır (0700). Bu ayar, gizli dosyaların boyutları veya varlıkları 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 uygulamalar için Android çerçevesi, file:// URI'larının uygulamanızın dışına gösterilmesini yasaklayan StrictMode API politikasını uygular. Dosya URI'si içeren bir niyet 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öndermeli ve URI'da geçici erişim izni vermelisiniz. Bu izni vermenin en kolay yolu FileProvider sınıfını kullanmaktır. İzinler ve dosya paylaşma hakkında daha fazla bilgi için Dosya Paylaşma sayfasını inceleyin.

Yeni Erişilebilirlik Özellikleri

Android 7.0, görme bozukluğu olan veya az gören kullanıcılar için platformun kullanılabilirliğini iyileştirmek amacıyla yapılan değişiklikler içerir. Bu değişiklikler genellikle uygulamanızda kod değişikliği gerektirmeyecektir ancak yine de bu özelliği inceleyip kullanıcı deneyimi üzerindeki olası etkileri değerlendirmek için 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 ayarlayarak az gören kullanıcılar için cihaz erişilebilirliğini iyileştirir. Kullanıcılar, ekranı yaygın olarak kullanılan orta büyüklükteki bir telefon olan Nexus 4'ün genişliği olan sw320dp'lik minimum ekran genişliğini geçecek şekilde ekranı yakınlaştıramazlar.

Android 7.0 sistem resmi ç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 büyütme etkisini gösteren ekran

3. Şekil. Sağdaki ekranda, Android 7.0 sistem görüntüsü çalıştıran bir cihazın görüntü boyutunu büyütmenin etkisi gösterilmektedir.

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

  • Bir uygulama, API düzeyi 23 veya altını hedeflerse sistem, uygulamanın tüm arka plan işlemlerini otomatik olarak sonlandırır. Diğer bir deyişle, kullanıcı bu tür bir uygulamadan ayrılarak Ayarlar ekranını açar ve Görüntü boyutu ayarını değiştirirse sistem, uygulamayı düşük bellekte olduğu gibi sonlandırır. Uygulamada herhangi bir ön plan işlemi varsa sistem, sanki cihazın yönü değişmiş gibi yapılandırma değişikliği ile ilgili bu süreçleri Çalışma Zamanı Değişikliklerini İşleme bölümünde açıklandığı gibi bilgilendirir.
  • Bir uygulama Android 7.0'ı hedefliyorsa Çalışma Zamanı Değişikliklerini İşleme bölümünde açıklandığı gibi, uygulamanın tüm süreçleri (ön plan ve arka plan) yapılandırma değişikliğiyle ilgili olarak bilgilendirilir.

Çoğu uygulamanın bu özelliği desteklemek için herhangi bir değişiklik yapması gerekmez (Android en iyi uygulamalarını takip etmesi şartıyla). Kontrol edilecek belirli 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, önbelleğe alınmış bit eşlemler veya ağdan yüklenen kaynaklar gibi yoğunluğa bağlı olarak ö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 veriler için uygun ekran boyutu veya piksel yoğunluğu gibi ilgili meta verileri eklemek iyi bir fikirdir. Bu meta verileri kaydetmek, yapılandırma değişikliğinden sonra önbelleğe alınan verileri yenilemeniz gerekip gerekmediğine karar vermenizi sağlar.

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

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

Android 7.0'ın Hoş Geldiniz ekranında, kullanıcıların yeni bir cihazda aşağıdaki erişilebilirlik ayarlarını yapılandırabilecekleri Görüş 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 bu ayarları etkinleştirerek uygulamalarınızı 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ğlanmasını engellemektedir. Bu da uygulamanızın kilitlenmesine neden olabilir. Davranıştaki bu değişikliğin amacı, platform güncellemeleri ve farklı cihazlar genelinde tutarlı bir uygulama deneyimi sunmaktır. Kodunuz özel kitaplıklara bağlantı vermiyor olsa da uygulamanızdaki üçüncü taraf bir 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 olmak için bunları kontrol etmelidir. Uygulamanız yerel kod kullanıyorsa yalnızca herkese açık NDK API'lerini kullanmanız gerekir.

Uygulamanız, gizli platform API'lerine erişmeye çalışıyor olabilir:

  • Uygulamanız özel platform kitaplıklarına doğrudan erişir. 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 bu senaryo için uygulamanızı yine de test etmeniz gerekir.
  • Uygulamanız, APK'sında bulunmayan bir kitaplığa referans veriyor. Örneğin, kendi OpenSSL kopyanızı kullanmaya çalıştıysanız ancak bunu uygulamanızın APK'sıyla birlikte paketlemeyi unuttuysanız bu durumla karşılaşabilirsiniz. Uygulama, Android platformun 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. Bunu düzeltmek için NDK olmayan tüm kitaplıklarınızı APK'nızla paketlediğinizden emin olun.

Uygulamalar, Android'in farklı sürümleri arasında değişebileceği veya kaldırılabileceği için NDK'ya dahil olmayan yerel kitaplıkları kullanmamalıdır. OpenSSL'den BoringSSL'ye geçiş, böyle bir değişikliğe örnek olarak gösterilebilir. Ayrıca NDK'ya dahil olmayan platform kitaplıkları için uyumluluk gereksinimleri olmadığından, farklı cihazlar farklı uyumluluk düzeyleri sunabilir.

Bu kısıtlamanın, halihazırda yayınlanmış uygulamalar üzerindeki etkisini azaltmak amacıyla, API düzeyi 23 veya altını hedefleyen uygulamalarda libandroid_runtime.so, libcutils.so, libcrypto.so ve libssl.so gibi ciddi kullanım görülen bir dizi kitaplık, Android 7.0 (API düzeyi 24) üzerinden geçici olarak erişilebilir durumdadır. Uygulamanız bu kitaplıklardan birini yüklerse logcat bir uyarı oluşturur ve hedef cihazda size bu durumu bildiren bir durum 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 veya geçici olarak erişilebilir olmayan bir API'yi çağırdıklarında çalışma zamanı hatası oluşturur. Sonuç olarak hem System.loadLibrary hem de dlopen(3), NULL değerini döndürerek uygulamanızın kilitlenmesine neden olabilir. Özel platform API'lerinin kullanımını kaldırmak için uygulama kodunuzu gözden geçirmeniz ve uygulamalarınızı Android 7.0 (API düzeyi 24) çalıştıran bir cihaz veya emülatör kullanarak kapsamlı bir şekilde test etmeniz gerekir. Uygulamanızın özel kitaplıkları kullanıp kullanmadığından emin değilseniz çalışma zamanı hatasını tanımlamak 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 beklediğiniz davranış açıklanmaktadır.

Kitaplıklar Hedef API düzeyi Dinamik bağlayıcı üzerinden çalışma zamanı erişimi Android 7.0 (API düzeyi 24) davranışı Gelecekteki Android platformu davranışı
NDK Herkese Açık 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 küçük Geçici olarak erişilebilir Beklendiği gibi çalışır ancak logcat uyarısı alırsınız. Çalışma zamanı hatası
Özel (geçici olarak erişilebilen özel kitaplıklar) 24 veya sonraki sürümler Kısıtlı Çalışma zamanı hatası Çalışma zamanı hatası
Gizli (diğer) Tümü Kısıtlı Ç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üklenmesiyle ilgili sorunları belirlemenize yardımcı olmak için uyarı veya çalışma zamanı hatası oluşturabilir. Örneğin, uygulamanız API düzeyi 23 veya altını 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'ye erişmeye çalıştığını size bildirir ancak uygulamanızın kilitlenmesine neden olmaz. Ancak uygulama, API düzeyi 24 veya üstünü 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)

Bu logcat çıkışlarını, uygulamanız özel platform API'lerine dinamik olarak bağlantı veren üçüncü taraf kitaplıklar kullanıyorsa da görebilirsiniz. Android 7.0DK'daki Readelf aracı, belirli bir .so dosyasının dinamik olarak bağlantılı tüm paylaşılan kitaplıklarının listesini aşağıdaki komutu çalıştırarak oluşturmanızı sağlar: 

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 kilitlenmesini önlemek için uygulayabileceğiniz adımlardan bazıları şunlardır:

  • Uygulamanız özel platform kitaplıkları kullanıyorsa uygulamanızı bu kitaplıkların kendi kopyasını içerecek şekilde güncellemeniz veya genel NDK API'lerini kullanmanız gerekir.
  • Uygulamanız özel sembollere erişen bir üçüncü taraf kitaplığı kullanıyorsa kitaplığı güncellemek için kitaplığın yazarıyla iletişime geçin.
  • NDK olmayan tüm kitaplıklarınızı APK'nızla paketlediğinizden emin olun.
  • getJavaVM ve libandroid_runtime.so değerlerinden 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 sembolü yerine __system_property_get kullanın. Bunun için __system_property_get özelliğini aşağıdakilerle birlikte kullanın: 
    #include <sys/system_properties.h>

    Not: Sistem özelliklerinin kullanılabilirliği ve içeriği CTS aracılığıyla test edilmez. Daha iyi bir çözüm, bu özellikleri hiç kullanmamaktır.

  • libcrypto.so alanındaki SSL_ctrl simgesinin yerel bir sürümünü kullanın. Örneğin, libcyrpto.a URL'sini .so dosyanıza statik olarak bağlamanız veya BoringSSL/OpenSSL'den dinamik olarak bağlantılı bir libcrypto.so sürümünü dahil edip APK'nızda 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 ile ilgili değişiklikler de dahil olmak üzere, Android for Work'ü hedefleyen uygulamalar için değişiklikler içerir. Android for Work ortamları için uygulama oluşturuyorsanız bu değişiklikleri inceleyip uygulamanızda gerekli değişiklikleri yapmanız gerekir.

  • DPC'nin ayarlayabilmesi için önce yetki verilmiş bir sertifika yükleyicisi yüklemeniz gerekir. Android 7.0 (API düzeyi 24) sürümünü hedefleyen hem profil hem de cihaz sahibi uygulamaları için, cihaz politikası denetleyici (DPC) DevicePolicyManager.setCertInstallerPackage() yöntemini çağırmadan önce yetki verilmiş sertifika yükleyiciyi yüklemelisiniz. Yükleyici önceden yüklenmemişse sistem bir IllegalArgumentException bildirir.
  • Cihaz yöneticileri için şifre sıfırlama kısıtlamaları artık profil sahipleri için de geçerli. Cihaz yöneticileri artık şifreleri temizlemek veya önceden ayarlanmış şifreleri değiştirmek için DevicePolicyManager.resetPassword() uygulamasını kullanamaz. Cihaz yöneticileri, yalnızca cihazda şifre, PIN veya desen olmadığı sürece şifre belirlemeye devam edebilir.
  • Kısıtlamalar ayarlanmış olsa bile cihaz ve profil sahipleri hesapları yönetebilir. Cihaz sahipleri ve profil sahipleri, DISALLOW_MODIFY_ACCOUNTS kullanıcı kısıtlaması uygulanmış olsa bile Account Management API'leri ç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öntemleri kullanımdan kaldırılmıştır; bunların yerini yeni DevicePolicyManager.createAndManageUser() yöntemi alır.
  • 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.
  • Çalışma Modu ayarı, iş uygulamalarına erişimi kontrol eder. İş modu kapalı olduğunda sistem başlatıcı, iş uygulamalarını devre dışı bırakarak kullanılamadığını belirtir. Çalışma modu tekrar etkinleştirildiğinde normal davranış geri yüklenir.
  • İstemci sertifikası zinciri ve Ayarlar kullanıcı arayüzündeki karşılık gelen ö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, uygulamalar daha sonra istemci sertifikası zincirini almaya çalıştığında KeyChain.getCertificateChain() işleminin sonucunu etkilemez. Gerekirse CA sertifikası, Ayarlar Kullanıcı Arayüzü aracılığıyla güvenilir kimlik bilgileri depolama alanına, .crt veya .cer dosya uzantısı altında DER kodlamalı bir biçimle ayrı olarak yüklenmelidir.
  • Android 7.0'dan itibaren parmak izi kaydı ve depolama alanı kullanıcı başına yönetilir. Bir 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 izini ayarlamaya devam edebilir ancak iş uygulamaları cihaz parmak izine erişemez. DPC, API düzeyi 24 ve üstünü hedeflediğinde kullanıcı, Ayarlar > Güvenlik > İş profili güvenliği bölümüne giderek özellikle iş profili için 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 ENCRYPTION_STATUS_ACTIVE_PER_USER şifreleme durumu döndürü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, cihaza ayrı bir iş sorgulamasıyla yüklenmiş bir iş profili varsa normalde cihazın tamamını etkileyen çeşitli yöntemler farklı şekilde davranır. Cihazın tamamını etkilemek yerine, bu yöntemler yalnızca iş profili için geçerlidir. (Bu 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ğindeki yöntemi çağırarak eski davranışı elde edebilirsiniz. Bu üst öğe için DevicePolicyManager.getParentProfileInstance() yöntemini çağırabilirsiniz. Dolayısıyla, örneğin üst örneğin lockNow() yöntemini çağırırsanız cihazın tamamı kilitlenir.

Ek Açıklamaları Saklama

Android 7.0, ek açıklamaların görünürlüğünün yoksayılmasına neden olan 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 görünür olması için yalnızca temel sisteme gösterilir.

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

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ışı.
  • CHACHA20-POLY1305 şifre paketleri artık etkin.

RC4'ün varsayılan olarak devre dışı bırakılması, sunucu modern şifre paketleriyle ilgili anlaşma yapmadığında HTTPS veya TLS/SSL bağlantısında kesintilere neden olabilir. Tercih edilen düzeltme, daha güçlü ve modern şifre paketleri ve protokolleri sağlamak için sunucunun yapılandırmasını iyileştirmektir. İdeal olarak, TLSv1.2 ve AES-GCM etkinleştirilmeli ve İletim Gizliliği şifre paketleri (ECDHE) etkinleştirilip tercih edilmelidir.

Alternatif bir yöntem de, uygulamayı, sunucuyla iletişim kurmak için özel bir SSLSocketFactory kullanacak şekilde değiştirmektir. Fabrika, varsayılan şifre paketlerinin yanı sıra sunucunun gerektirdiği bazı şifre paketlerine sahip SSLSocket örnekleri oluşturacak şekilde 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'a göre derlenen veya targetSdkVersion uygulamasını Android 7.0 ya da sonraki bir sürüme ayarlayan uygulamalar, uygun olduğu durumlarda bu davranışları doğru bir şekilde desteklemek için uygulamalarını değiştirmelidir.

Serileştirme Değişiklikleri

Android 7.0 (API düzeyi 24), varsayılan seriVersionUID değerinin hesaplanmasında spesifikasyonla eşleşmediği bir hatayı düzeltmiştir.

Serializable uygulayan ve açık bir serialVersionUID alanı belirtmeyen sınıfların varsayılan seri 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ından stream classdesc serialVersionUID değeriyle bir serialVersionUID alanı eklenmesi gerekir (ör. bu durumda 1234). Bu değişiklik, serileştirme kodu yazmayla ilgili tüm iyi uygulama önerilerine uyar 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 bir statik başlatıcı yönteminin varlığı veya olmaması, bu sınıf için hesaplanan varsayılan SeriVersionUID'yi etkiler. Hata düzeltmesinden önce, bir sınıfta yoksa bir statik başlatıcı için hesaplamada süper sınıf kontrol edilir.

Daha net bir ifadeyle, bu değişiklik API düzeyi 23 veya altını hedefleyen uygulamaları, serialVersionUID alanı olan sınıfları ya da statik başlatıcı yöntemi olan sınıfları etkilemeyecek.

Diğer önemli noktalar

  • Bir uygulama Android 7.0 üzerinde çalışırken daha düşük bir API düzeyini hedeflediğinde kullanıcı ekran boyutunu değiştirirse uygulama işlemi sonlandırılır. Uygulamanın bu senaryoyla sorunsuzca başa çıkabilmesi gerekir. Aksi takdirde, kullanıcı uygulamayı Son Kullanılanlar'dan geri yüklediğinde kilitlenir.

    Bu davranışın oluşmadığından emin olmak için uygulamanızı test etmelisiniz. Bunu, uygulamayı DCM üzerinden 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 sonlandırılmaz ancak yapılandırma değişikliklerine yine de kötü yanıt verebilir.

  • Android 7.0 uygulamaları, yapılandırma değişikliklerini sorunsuz bir şekilde işleyebilmeli 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ığındaki bir TCP soketine yazmayı katı mod ihlali olarak işaretlemedi. Android 7.0 bu hatayı düzeltir. Bu davranışı sergileyen uygulamalar artık android.os.NetworkOnMainThreadException döndürür. Ağ işlemlerinin ana iş parçacığında gerçekleştirilmesi genellikle kötü bir fikirdir. Bunun nedeni, bu işlemlerin genellikle ANR'lere ve jank'a neden olan yüksek bir gecikmeye sahip olmasıdır.
  • Debug.startMethodTracing() yöntem ailesi artık varsayılan olarak çıktıları SD kartın üst düzeyinde değil, paylaşılan depolama alanındaki pakete özgü dizininizde saklar. Bu durumda, uygulamaların bu API'leri kullanmak için artık WRITE_EXTERNAL_STORAGE izni istemesine gerek yoktur.
  • Birçok platform API'si, Binder işlem genelinde gönderilen büyük yükleri kontrol etmeye başladı ve sistem artık TransactionTooLargeExceptions öğelerini sessizce günlüğe kaydetmek veya gizlemek yerine RuntimeExceptions olarak yeniden yayınlıyor. Yaygın bir örnek, Activity.onSaveInstanceState() uygulamasında çok fazla veri depolamaktır. Bu durum, uygulamanız Android 7.0'ı hedeflediğinde ActivityThread.StopInfo uygulamasının RuntimeException hatasına neden olur.
  • Bir uygulama View öğesine Runnable görevleri yayınlarsa ve View bir pencereye bağlı değilse sistem, Runnable görevini View ile sıraya alır. View bir pencereye eklenene kadar Runnable görevi yürütülmez. Bu davranış, aşağıdaki hataları düzeltir:
    • Bir uygulama, istenen pencerenin kullanıcı arayüzü iş parçacığı dışındaki bir iş parçacığından View için yayın gönderirse Runnable, sonuç olarak yanlış iş parçacığında çalışabilir.
    • Runnable görevi, döngü oluşturucu 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ışıyorsa ancak bu paketi farklı bir uygulama yüklemişse sistem için kullanıcı onayı gerekir. Bu senaryoda uygulamalar, PackageInstaller.uninstall() yöntemini çağırdıklarında döndürme durumu olarak STATUS_PENDING_USER_ACTION beklemelidir.
  • Tek algoritması SHA1PRNG, kriptografik olarak zayıf olduğu için Crypto adlı JCA sağlayıcısı kullanımdan kaldırıldı. Bu sağlayıcı artık kullanılamadığından uygulamalar, anahtarları (güvenli olmayan bir şekilde) türetmek için artık SHA1PRNG kullanamaz. Daha fazla bilgi için Android N'de güvenlik "Kripto" sağlayıcısı kullanımdan kaldırıldı başlıklı blog yayınına göz atın.