Android 5.0 Davranış Değişiklikleri

API Düzeyi: 21

Android 5.0, yeni özellikler ve becerilerin yanı sıra çeşitli sistem değişiklikleri 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 uygulama yayınladıysanız uygulamanızın Android 5.0'daki bu değişikliklerden etkilenebileceğini unutmayın.

Yeni platform özelliklerini genel hatlarıyla incelemek için Android Lollipop'ta öne çıkan özellikler sayfasına göz atın.

Videolar

Dev Byte: Android 5.0'daki Yenilikler

Dev Bayt: Bildirimler

Android Çalışma Zamanı (ART)

Android 5.0'da ART çalışma zamanı, platform varsayılanı olarak Dalvik'in yerini alır. ART çalışma zamanı, Android 4.4'te deneysel olarak kullanıma sunulmuştur.

ART'ın yeni özelliklerine genel bakış için ART'ın tanıtımı sayfasını inceleyin. Önemli yeni özelliklerden bazıları şunlardır:

  • Önceden (AOT) derleme
  • İyileştirilmiş çöp toplama (GC)
  • İyileştirilmiş hata ayıklama desteği

Çoğu Android uygulaması, ART kapsamında herhangi bir değişiklik olmadan çalışacaktır. Ancak, Dalvik'te işe yarayan bazı teknikler ART'ta işe yaramaz. En önemli sorunlar hakkında bilgi edinmek için Android Çalışma Zamanında (ART) Uygulama Davranışını Doğrulama bölümüne bakın. Aşağıdaki durumlarda özellikle dikkatli olun:

  • Uygulamanız C/C++ kodunu çalıştırmak için Java Yerel Arayüzü (JNI) kullanıyor.
  • Standart olmayan kod oluşturan geliştirme araçlarını (bazı kod karartıcılar gibi) kullanıyorsunuz.
  • Atık toplama ile uyumlu olmayan teknikler kullanıyorsunuz.

Bildirimler

Bildirimlerinizde bu Android 5.0 değişikliklerini dikkate aldığınızdan emin olun. Android 5.0 ve sonraki sürümler için bildirimlerinizi tasarlama hakkında daha fazla bilgi edinmek için bildirim tasarım kılavuzuna bakın.

Materyal tasarım stili

Bildirimler, yeni materyal tasarım widget'larına uyacak şekilde, beyaz (veya çok açık renkli) arka planların üzerine koyu renk metinle çizilir. Tüm bildirimlerinizin yeni renk şemasıyla düzgün göründüğünden emin olun. Bildirimleriniz yanlış görünüyorsa bunları düzeltin:

  • Simge resminizin arkasındaki daire içinde bir vurgu rengi ayarlamak için setColor() kullanın.
  • Renk içeren öğeleri güncelleyin veya kaldırın. Sistem, işlem simgelerinde ve ana bildirim simgesinde bulunan alfa olmayan tüm kanalları yoksayar. Bu simgelerin yalnızca alfa olacağını varsaymanız gerekir. Sistem, bildirim simgelerini beyaz, işlem simgelerini ise koyu gri olarak çizer.

Ses ve titreşim

Şu anda Ringtone, MediaPlayer veya Vibrator sınıflarını kullanarak bildirimlerinize ses ve titreşim ekliyorsanız sistemin bildirimleri öncelikli modda doğru şekilde sunabilmesi için bu kodu kaldırın. Bunun yerine, ses ve titreşim eklemek için Notification.Builder yöntemlerini kullanın.

Cihazın RINGER_MODE_SILENT değerine ayarlanması cihazın yeni öncelik moduna girmesine neden olur. RINGER_MODE_NORMAL veya RINGER_MODE_VIBRATE değerine ayarlarsanız cihaz öncelik modundan çıkar.

Daha önce Android, tablet cihazlarda ses düzeyini kontrol etmek için ana akış olarak STREAM_MUSIC kullanıyordu. Android 5.0'da hem telefon hem de tablet cihazların ana ses akışı artık birleştirilmiştir ve STREAM_RING veya STREAM_NOTIFICATION tarafından kontrol edilir.

Kilit ekranı görünürlüğü

Varsayılan olarak bildirimler, Android 5.0'da artık kullanıcının kilit ekranında görünür. Kullanıcılar, hassas bilgilerin açığa çıkmasını önlemeyi seçebilir. Bu durumda, bildirim tarafından görüntülenen metin otomatik olarak çıkartılır. Çıkartılan bu bildirimi özelleştirmek için setPublicVersion() özelliğini kullanın.

Bildirim kişisel bilgi içermiyorsa veya bildirimde medya oynatma kontrolüne izin vermek istiyorsanız setVisibility() yöntemini çağırın ve bildirimin görünürlük düzeyini VISIBILITY_PUBLIC olarak ayarlayın.

Medya oynatma

Medya oynatma durumunu veya aktarım kontrollerini gösteren bildirimler uyguluyorsanız özel RemoteViews.RemoteView nesnesi yerine yeni Notification.MediaStyle şablonunu kullanmayı düşünün. Hangi yaklaşımı seçerseniz seçin, kontrollerinize kilit ekranından erişilebilmesi için bildirimin görünürlüğünü VISIBILITY_PUBLIC olarak ayarladığınızdan emin olun. Android 5.0'dan itibaren sistemin kilit ekranında RemoteControlClient nesnelerini artık göstermediğini unutmayın. Daha fazla bilgi için Uygulamanız RemoteControlClient kullanıyorsa bölümüne bakın.

Uyarı bildirimi

Bildirimler, artık cihaz etkin olduğunda (cihazın kilidi açıkken ve ekranı açıkken) küçük bir kayan pencerede (uyarı bildirimi olarak da adlandırılır) görüntülenebilir. Bu bildirimler, bildiriminizin küçük biçimine benzer ancak uyarı bildiriminde işlem düğmeleri de gösterilir. Kullanıcılar geçerli uygulamadan ayrılmadan uyarı bildirimleriyle ilgili işlem yapabilir veya bildirimi kapatabilir.

Uyarı bildirimlerini tetikleyebilecek koşullara örnek olarak aşağıdakiler verilebilir:

  • Kullanıcının etkinliği tam ekran modundadır (uygulama fullScreenIntent kullanıyor)
  • Bildirim yüksek önceliğe sahip ve zil sesleri veya titreşimler kullanıyor

Uygulamanız bu senaryolardan herhangi birinde bildirimler kullanıyorsa uyarı bildirimlerinin doğru şekilde sunulduğundan emin olun.

Medya Denetimleri ve RemoteControlClient

RemoteControlClient sınıfı kullanımdan kaldırıldı. En kısa sürede yeni MediaSession API'ye geçin.

Android 5.0'daki kilit ekranları, MediaSession veya RemoteControlClient cihazınız için aktarım kontrollerini göstermez. Uygulamanız bunun yerine bir bildirim aracılığıyla kilit ekranından medya oynatma kontrolü sağlayabilir. Bu durum, uygulamanızın medya düğmelerinin sunumu üzerinde daha fazla kontrol sahibi olmasını sağlarken, kilitli ve kilidi açık cihazlarda kullanıcılar için de tutarlı bir deneyim sağlar.

Android 5.0, bu amaç için yeni bir Notification.MediaStyle şablonu sunar. Notification.MediaStyle, Notification.Builder.addAction() ile eklediğiniz bildirim işlemlerini uygulamanızın medya oynatma bildirimlerine yerleştirilmiş küçük düğmelere dönüştürür. Bu bildirimin devam eden bir medya oturumunu kontrol ettiğini sisteme bildirmek için oturum jetonunuzu setSession() yöntemine iletin.

Bildirimi tüm kilit ekranlarında (güvenli veya başka şekilde) gösterilmesinin güvenli olduğunu belirtmek için bildirimin görünürlüğünü VISIBILITY_PUBLIC olarak ayarladığınızdan emin olun. Daha fazla bilgi için Kilit ekranı bildirimleri bölümüne bakın.

Uygulamanız Android TV veya Wear platformunda çalışıyorsa medya oynatma kontrollerini görüntülemek için MediaSession sınıfını uygulayın. Uygulamanızın Android cihazlarda medya düğmesi etkinliklerini alması gerekiyorsa da MediaSession öğesini uygulamanız gerekir.

get{7/}Tasks()

Android 5.0'da yeni eşzamanlı belge ve etkinlik görevleri özelliğinin kullanıma sunulmasıyla birlikte (aşağıdaki Son kullanılanlar ekranındaki eşzamanlı dokümanlar ve etkinlikler bölümüne bakın) kullanıcı gizliliğini iyileştirmek için ActivityManager.getRecentTasks() yöntemi kullanımdan kaldırıldı. Geriye dönük uyumluluk için bu yöntem, çağıran uygulamanın kendi görevleri ve muhtemelen hassas olmayan diğer bazı görevler (ör. Home) da dahil olmak üzere verilerinin küçük bir alt kümesini döndürür. Uygulamanız kendi görevlerini almak için bu yöntemi kullanıyorsa bu bilgileri almak yerine getAppTasks() politikasını kullanın.

Android NDK'da 64 Bit Destek

Android 5.0'da 64 bit sistemler desteği sunulmaktadır. 64 bit geliştirme, mevcut 32 bit uygulamaları tam olarak desteklemeye devam ederken adres alanını artırır ve performansı iyileştirir. 64 bit desteği, kriptografi için OpenSSL performansını da iyileştirir. Ayrıca bu sürümde, yeni yerel medya NDK API'leri ve yerel OpenGL ES (GLES) 3.1 desteği sunulmaktadır.

Android 5.0'da sağlanan 64 bit desteği kullanmak için Android NDK sayfasından NDK Revision 10c'yi indirip yükleyin. NDK'da yapılan önemli değişiklikler ve hata düzeltmeleri hakkında daha fazla bilgi edinmek için Düzeltme 10c sürüm notlarına bakın.

Hizmete Bağlama

Context.bindService() yöntemi artık açık bir Intent gerektiriyor ve örtülü bir amaç varsa istisna oluşturuyor. Uygulamanızın güvenli olduğundan emin olmak için Service cihazınızı başlatırken veya bağlarken açık bir intent kullanın ve hizmet için amaç filtreleri beyan etmeyin.

Web Görünümü

Android 5.0, uygulamanızın varsayılan davranışını değiştirir.

  • Uygulamanız API düzeyi 21 veya üstünü hedefliyorsa:
    • Sistem, varsayılan olarak karma içeriği ve üçüncü taraf çerezlerini engeller. Karma içerik ve üçüncü taraf çerezlerine izin vermek için sırasıyla setMixedContentMode() ve setAcceptThirdPartyCookies() yöntemlerini kullanın.
    • Sistem artık HTML belgesinin çizilecek bölümlerini akıllı bir şekilde seçiyor. Bu yeni varsayılan davranış, bellek ayak izini azaltmaya ve performansı artırmaya yardımcı olur. Dokümanın tamamını aynı anda oluşturmak istiyorsanız enableSlowWholeDocumentDraw() yöntemini çağırarak bu optimizasyonu devre dışı bırakın.
  • Uygulamanız 21'in altındaki API düzeylerini hedefliyorsa: Sistem, karma içeriğe ve üçüncü taraf çerezlerine izin verir ve her zaman belgenin tamamını aynı anda oluşturur.

Özel İzinler için Benzersizlik Gereksinimi

İzinlere genel bakış bölümünde açıklandığı gibi, Android uygulamaları özel izinleri, platformun önceden tanımlanmış sistem izinlerini kullanmadan bileşenlere erişimi özel bir şekilde yönetmenin bir yolu olarak tanımlayabilir. Uygulamalar, manifest dosyalarında belirtilen <permission> öğelerinde özel izinler tanımlar.

Özel izinler tanımlamanın meşru ve güvenli bir yaklaşım olduğu az sayıda senaryo vardır. Bununla birlikte, özel izinler oluşturmak bazen gereksizdir ve izinlere atanan koruma düzeyine bağlı olarak uygulama için risk oluşturabilir.

Android 5.0, belirli bir özel izni tanımlayan diğer uygulamalarla aynı anahtarla imzalanmadığı sürece, yalnızca bir uygulamanın bu izni tanımlayabilmesini sağlayacak bir davranış değişikliği içerir.

Yinelenen özel izinler kullanan uygulamalar

Herhangi bir uygulama istediği özel izni tanımlayabilir. Bu nedenle, birden fazla uygulama aynı özel izni tanımlayabilir. Örneğin, iki uygulama benzer özellik sunuyorsa her iki uygulama, kendi özel izinleri için aynı mantıksal adı türetebilir. Uygulamalar, aynı özel izin tanımlarını içeren yaygın halk kitaplıklarını veya kod örneklerini de dahil edebilir.

Sistem, ilk yüklenen uygulamanın belirttiği koruma düzeyini atamış olsa da, Android 4.4 ve önceki sürümlerde kullanıcılar belirli bir cihaza bu tür birden fazla uygulama yükleyebilmiştir.

Android 5.0'dan itibaren sistem, farklı anahtarlarla imzalanmış uygulamalar için özel izinler üzerinde yeni bir benzersizlik kısıtlaması uyguluyor. Artık bir cihazdaki tek bir uygulama, izni tanımlayan diğer uygulama aynı anahtarla imzalanmadığı sürece, verilen özel izni (adıyla belirlendiği üzere) tanımlayabilir. Kullanıcı yinelenen bir özel izne sahip bir uygulama yüklemeye çalışırsa ve izni tanımlayan yerleşik uygulamayla aynı anahtarla imzalanmazsa sistem yüklemeyi engeller.

Uygulamanızla ilgili dikkat edilmesi gereken noktalar

Android 5.0 ve sonraki sürümlerde uygulamalar eskisi gibi kendi özel izinlerini tanımlamaya ve <uses-permission> mekanizmasını kullanarak diğer uygulamalardan özel izinler istemeye devam edebilir. Ancak Android 5.0'da kullanıma sunulan yeni şartla birlikte, uygulamanız üzerindeki olası etkileri dikkatlice değerlendirmeniz gerekir.

Dikkate almanız gereken bazı noktalar aşağıda belirtilmiştir:

  • Uygulamanız, manifest dosyasında <permission> öğesi tanımlıyor mu? Varsa bunların uygulama veya hizmetinizin düzgün çalışması için gerçekten gerekli mi? Bunun yerine sistemin varsayılan iznini kullanabilir misiniz?
  • Uygulamanızda <permission> öğeleri varsa bunların nereden geldiğini biliyor musunuz?
  • Başka uygulamaların <uses-permission> aracılığıyla özel izinlerinizi istemesini gerçekten istiyor musunuz?
  • Uygulamanızda <permission> öğelerini içeren ortak metin veya örnek kod kullanıyor musunuz? Bu izin öğeleri gerçekten gerekli mi?
  • Özel izinlerinizde basit veya diğer uygulamaların paylaşabileceği yaygın terimleri temel alan adlar kullanılıyor mu?

Yeni yüklemeler ve güncellemeler

Yukarıda belirtildiği gibi, Android 4.4 veya önceki sürümleri çalıştıran cihazlara uygulamanızın yeni yükleme ve güncellemelerinden etkilenmez ve davranışta herhangi bir değişiklik olmaz. Android 5.0 veya sonraki sürümleri çalıştıran cihazlardaki yeni yüklemeler ve güncellemeler için sistem, mevcut bir yerleşik uygulama tarafından önceden tanımlanmış özel bir izni tanımlıyorsa uygulamanızın yüklenmesini engeller.

Android 5.0 sistem güncellemesiyle mevcut yükleme sayısı

Uygulamanız özel izinler kullanıyorsa ve yaygın olarak dağıtılıp yüklendiyse kullanıcılar cihazlarını Android 5.0'a güncellemelerini aldığında, uygulamanız bundan etkilenebilir. Sistem güncellemesi yüklendikten sonra sistem, özel izinlerinin kontrol edilmesi de dahil yüklü uygulamaları yeniden doğrular. Uygulamanız doğrulanmış başka bir uygulama tarafından daha önce tanımlanmış özel bir izin tanımlıyorsa ve uygulamanız diğer uygulamayla aynı anahtarla imzalanmamışsa sistem uygulamanızı yeniden yüklemez.

Öneriler

Android 5.0 veya sonraki sürümleri çalıştıran cihazlarda uygulamanızı hemen incelemenizi, gerekli düzenlemeleri yapmanızı ve güncellenmiş sürümü kullanıcılarınıza en kısa sürede yayınlamanızı öneririz.

  • Uygulamanızda özel izinler kullanıyorsanız bunların kaynağını ve bunlara gerçekten ihtiyacınız olup olmadığını göz önünde bulundurun. Uygulamanızın düzgün çalışması için gerekli olduğundan emin değilseniz <permission> öğelerinin tamamını uygulamanızdan kaldırın.
  • Mümkün olduğunda özel izinlerinizi sistem varsayılan izinleriyle değiştirmeyi düşünün.
  • Uygulamanız özel izinler gerektiriyorsa özel izinlerinizi, uygulamanıza özgü olacak şekilde yeniden adlandırın (ör. uygulamanızın tam paket adına ekleyerek).
  • Farklı anahtarlarla imzalanmış bir uygulama paketiniz varsa ve bu uygulamalar, paylaşılan bir bileşene özel bir izin aracılığıyla erişiyorsa özel iznin paylaşılan bileşende yalnızca bir kez tanımlandığından emin olun. Paylaşılan bileşeni kullanan uygulamalar, özel izni kendileri tanımlamamalıdır. Bunun yerine, <uses-permission> mekanizması aracılığıyla erişim isteğinde bulunmalıdır.
  • Aynı anahtarla imzalanmış bir uygulama paketiniz varsa her uygulama, gereken şekilde aynı özel izinleri tanımlayabilir. Sistem, uygulamaların her zamanki gibi yüklenmesine izin verir.

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

Android 5.0'da, uygulamalar tarafından HTTPS ve diğer TLS/SSL trafiği için kullanılan varsayılan TLS/SSL yapılandırması değişiyor:

  • TLSv1.2 ve TLSv1.1 protokolleri artık etkin.
  • AES-GCM (AEAD) şifre paketleri artık etkin,
  • MD5, 3DES, dışa aktarma ve statik anahtar ECDH şifre paketleri artık devre dışıdır,
  • İletim Gizliliği şifre paketleri (ECDHE ve DHE) tercih edilir.

Bu değişiklikler, aşağıda listelenen az sayıda durumda HTTPS veya TLS/SSL bağlantısının kesilmesine neden olabilir.

Google Play Hizmetleri'nden Security ProviderInstaller öğesinin, bu değişiklikleri Android 2.3 ve daha yeni Android platform sürümleri genelinde zaten sunduğunu unutmayın.

Sunucu, etkin şifre paketlerinin hiçbirini desteklemiyor

Örneğin, bir sunucu yalnızca 3DES veya MD5 şifre paketlerini destekleyebilir. Tercih edilen düzeltme, daha güçlü ve modern şifre paketleri ve protokoller sağlamak için sunucunun yapılandırmasını iyileştirmektir. İdeal olarak TLSv1.2 ve AES-GCM etkinleştirilmelidir. Ayrıca İletim Gizliliği şifre paketleri (ECDHE, DHE) 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.

Uygulama sunucuya bağlanmak için kullanılan şifre paketleri hakkında yanlış varsayımlarda bulunuyor

Örneğin, bazı uygulamalar authType parametresinin RSA olmasını beklediği ancak ECDHE_RSA veya DHE_RSA ile karşılaştığı için bozulan özel bir X509TrustManager içerir.

Sunucu TLSv1.1, TLSv1.2 veya yeni TLS uzantılarına karşı hoşgörüsüz

Örneğin, bir sunucuyla TLS/SSL el sıkışması yanlışlıkla reddedilir veya durur. Tercih edilen düzeltme, sunucuyu TLS/SSL protokolüne uygun olacak şekilde yükseltmektir. Bu, sunucunun bu yeni protokoller üzerinde başarılı bir şekilde anlaşmasını ya da TLSv1 veya daha eski protokoller üzerinde anlaşmasını ve anlamadığı TLS uzantılarını yoksaymasını sağlar. Bazı durumlarda TLSv1.1 ve TLSv1.2'nin sunucuda devre dışı bırakılması, sunucu yazılımı yükseltilene kadar geçici bir önlem olarak işe yarayabilir.

Alternatif bir yöntem de, uygulamayı, sunucuyla iletişim kurmak için özel bir SSLSocketFactory kullanacak şekilde değiştirmektir. Fabrika, yalnızca sunucu tarafından doğru şekilde desteklenen protokollerin etkinleştirildiği SSLSocket örnekleri oluşturacak şekilde tasarlanmalıdır.

Yönetilen Profiller için Destek

Cihaz yöneticileri, bir cihaza yönetilen profil ekleyebilir. Bu profilin sahibi yöneticidir. Kullanıcının kişisel profili ve depolama alanı kullanıcının denetimindeyken yöneticiye, yönetilen profil üzerinde denetim olanağı sağlar. Bu değişiklik, mevcut uygulamanızın davranışını aşağıdaki şekillerde etkileyebilir.

Amaçları işleme

Cihaz yöneticileri, yönetilen profilden sistem uygulamalarına erişimi kısıtlayabilir. Bu durumda, bir uygulama normalde söz konusu uygulama tarafından işlenecek yönetilen profilden bir niyet tetiklerse ve yönetilen profilde amaca uygun bir işleyici yoksa amaç bir istisnaya neden olur. Örneğin, cihaz yöneticisi, yönetilen profildeki uygulamaların sistemin kamera uygulamasına erişimini kısıtlayabilir. Uygulamanız yönetilen profilde çalışıyorsa ve MediaStore.ACTION_IMAGE_CAPTURE için startActivityForResult() çağrısı yapıyorsa ve yönetilen profilde bu niyeti işleyebilecek herhangi bir uygulama yoksa ActivityNotFoundException neden olur.

Bunu tetiklemeden önce herhangi bir amaç için en az bir işleyici olup olmadığını kontrol ederek önleyebilirsiniz. Geçerli bir işleyici olup olmadığını kontrol etmek için Intent.resolveActivity() numaralı telefonu arayın. Bunun nasıl yapıldığını Basitçe Fotoğraf Çek: Kamera Uygulamasıyla Fotoğraf Çekin bölümünde görebilirsiniz.

Profiller arasında dosya paylaşma

Her profilin kendi dosya depolama alanı vardır. Dosya URI'si, dosya depolama alanındaki belirli bir konumu ifade ettiğinden, bir profilde geçerli olan bir dosya URI'sı diğer profilde geçerli değildir. Bu, genelde yalnızca oluşturduğu dosyalara erişen uygulamalarda görülen bir sorun değildir. Bununla birlikte, bir uygulama bir amaca dosya eklerse dosya URI'si eklemek güvenli olmaz. Çünkü bazı durumlarda amaç diğer profilde işlenebilir. Örneğin, bir cihaz yöneticisi görüntü yakalama etkinliklerinin kişisel profildeki kamera uygulaması tarafından işlenmesi gerektiğini belirtebilir. Niyet, yönetilen profildeki bir uygulama tarafından tetiklenirse kameranın, görüntüyü yönetilen profilin uygulamalarının okuyabileceği bir konuma yazabilmesi gerekir.

Güvenliğiniz için, bir profilden diğerine geçebilecek bir amaca dosya eklemeniz gerektiğinde dosya için bir içerik URI oluşturup kullanmanız gerekir. Dosyaları içerik URI'leriyle paylaşma hakkında daha fazla bilgi için Dosya Paylaşımı konusuna bakın. Örneğin, cihaz yöneticisi, ACTION_IMAGE_CAPTURE adlı cihazın kişisel profildeki kamera tarafından işlenmesine izin verebilir. Tetikleme amacının EXTRA_OUTPUT değeri, fotoğrafın depolanması gereken yeri belirten bir içerik URI'sı içermelidir. Kamera uygulaması, görüntüyü bu URI tarafından belirtilen konuma yazabilir ve amacı tetikleyen uygulama diğer profilde olsa bile bu dosyayı okuyabilir.

Kilit ekranı widget'ı desteği kaldırıldı

Android 5.0, kilit ekranı widget'ları desteğini kaldırır; ana ekrandaki widget'ları desteklemeye devam etmektedir.