Bu sayfa, Cloud Translation API ile çevrilmiştir.

Android 5.0 Davranış Değişiklikleri

API düzeyi: 21

Android 5.0, yeni özellikler ve özelliklerle birlikte çeşitli sistem değişiklikleri 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 Android 5.0'deki bu değişikliklerden etkilenebileceğini unutmayın.

Yeni platform özelliklerine genel bir bakış için Android Lollipop'un öne çıkan özellikleri başlıklı makaleyi inceleyin.

Videolar

Geliştirici Bilgisi: Android 5.0'deki Yenilikler

Geliştirici Bilgisi: Bildirimler

Android Çalışma Zamanı (ART)

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

ART'ın yeni özelliklerine genel bakış için ART'ı tanıtıyoruz başlıklı makaleyi inceleyin. Yeni özelliklerin bazıları şunlardır:

Önceden derleme (AOT)
İyileştirilmiş atık toplama (GC)
Geliştirilmiş hata ayıklama desteği

Çoğu Android uygulaması, ART altında herhangi bir değişiklik yapılmadan çalışmalıdır. Ancak Dalvik'te çalışan bazı teknikler ART'te çalışmaz. En önemli sorunlar hakkında bilgi edinmek için Android Çalışma Zamanında (ART) Uygulama Davranışını Doğrulama başlıklı makaleyi inceleyin. Aşağıdaki durumlarda özellikle dikkat edin:

Uygulamanız, C/C++ kodunu çalıştırmak için Java Native Interface'ı (JNI) kullanıyor.
Standart olmayan kod oluşturan geliştirme araçlarını (ör. bazı kod karartıcıları) kullanıyorsunuz.
Sıkıştırılmış çöp toplama ile uyumlu olmayan teknikler kullanıyorsanız

Bildirimler

Bildirimlerinizin Android 5.0'daki bu değişiklikleri dikkate aldığından emin olun. Android 5.0 ve sonraki sürümler için bildirimlerinizi tasarlama hakkında daha fazla bilgi edinmek isterseniz bildirim tasarım kılavuzuna göz atın.

Materyal Tasarım stili

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

Simge resminizin arkasındaki daire içinde vurgu rengi ayarlamak için setColor() seçeneğini kullanın.
Renk içeren öğeleri güncelleyin veya kaldırın. Sistem, işlem simgelerindeki ve ana bildirim simgesindeki alfabe dışı tüm kanalları yoksayar. Bu simgelerin yalnızca alfa karakter içereceğini varsaymalısınız. 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 öncelik modunda 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ı RINGER_MODE_SILENT olarak ayarlamak, cihazın yeni öncelik moduna girmesine neden olur. Cihazı RINGER_MODE_NORMAL veya RINGER_MODE_VIBRATE olarak ayarlarsanız öncelik modundan çıkar.

Daha önce Android, tablet cihazlarda ses seviyesini kontrol etmek için ana akış olarak STREAM_MUSIC'ü kullanıyordu. Android 5.0'de hem telefon hem de tablet cihazlar için ana ses akışı birleştirildi ve STREAM_RING veya STREAM_NOTIFICATION ile kontrol ediliyor.

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

Android 5.0'de bildirimler varsayılan olarak kullanıcının kilit ekranında gösterilir. Kullanıcılar, hassas bilgileri korumayı seçebilir. Bu durumda sistem, bildirim tarafından gösterilen metni otomatik olarak sansürleyebilir. Bu çıkartılmış bildirimi özelleştirmek için setPublicVersion() seçeneğ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 aktarma kontrollerini gösteren bildirimler uyguluyorsanız özel RemoteViews.RemoteView nesnesi yerine yeni Notification.MediaStyle şablonunu kullanmayı düşünebilirsiniz. Hangi yaklaşımı seçerseniz seçin, kilit ekranından denetimlerinize erişilebilmesi için bildirimin görünürlüğünü VISIBILITY_PUBLIC olarak ayarladığınızdan emin olun. Android 5.0'den itibaren sistemin kilit ekranında RemoteControlClient nesneleri göstermediğini unutmayın. Daha fazla bilgi için Uygulamanız RemoteControlClient kullanıyorsa başlıklı makaleyi inceleyin.

Uyarı bildirimi

Artık bildirimler, cihaz etkinken (yani cihazın kilidi açıkken ve ekranı açıkken) küçük bir kayan pencerede (uyarı bildirimi olarak da bilinir) gösterilebilir. Bu bildirimler, bildiriminizin kompakt biçimine benzer şekilde görünür. Tek fark, uyarı bildiriminde işlem düğmelerinin de gösterilmesidir. Kullanıcılar, mevcut uygulamadan ayrılmadan uyarı bildirimiyle ilgili işlem yapabilir veya bildirimi kapatabilir.

Uyarı bildirimlerini tetikleyebilecek koşullara örnek olarak şunlar verilebilir:

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

Uygulamanız bu senaryolardan herhangi biri kapsamında bildirim uyguluyorsa uyarı bildirimlerinin doğru şekilde sunulmasına dikkat edin.

Medya Kontrolleri ve RemoteControlClient

RemoteControlClient sınıfı için destek sonlandırıldı. En kısa sürede yeni MediaSession API'ye geçin.

Android 5.0'teki kilit ekranlarında MediaSession veya RemoteControlClient cihazınız için aktarma kontrolleri gösterilmez. Bunun yerine uygulamanız, kilit ekranından bir bildirim aracılığıyla medya oynatma kontrolü sağlayabilir. Bu sayede uygulamanız, medya düğmelerinin sunumu üzerinde daha fazla kontrol sahibi olurken kilitli ve kilidi açık cihazlardaki kullanıcılara tutarlı bir deneyim sunar.

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

Bildirimi, tüm kilit ekranlarında (güvenli veya güvenli olmayan) gösterilmesi güvenli olarak işaretlemek için görünürlüğünü VISIBILITY_PUBLIC olarak ayarlayın. Daha fazla bilgi için Kilit ekranı bildirimleri başlıklı makaleyi inceleyin.

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 etkinlikleri alması gerekiyorsa MediaSession'ü de uygulamanız gerekir.

getRecentTasks()

Android 5.0'de yeni eşzamanlı doküman ve etkinlik görevleri özelliğinin kullanıma sunulmasıyla birlikte (aşağıdaki Son uygulamalar ekranında eşzamanlı dokümanlar ve etkinlikler bölümüne bakın), kullanıcı gizliliğini iyileştirmek için ActivityManager.getRecentTasks() yönteminin desteği sonlandırılmıştır. 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. Ev) dahil olmak üzere verilerinin küçük bir alt kümesini döndürmeye devam eder. Uygulamanız kendi görevlerini almak için bu yöntemi kullanıyorsa bu bilgileri almak için getAppTasks() yerine kullanın.

Android NDK'da 64 Bit Desteği

Android 5.0, 64 bit sistemler için destek sunar. 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'in performansını da iyileştirir. Ayrıca bu sürümde, yeni yerel medya NDK API'lerinin yanı sıra yerel OpenGL ES (GLES) 3.1 desteği de kullanıma sunulmuştur.

Android 5.0'de sunulan 64 bit desteğini kullanmak için Android NDK sayfasından NDK 10c düzeltmesini indirip yükleyin. NDK'daki önemli değişiklikler ve hata düzeltmeleri hakkında daha fazla bilgi için 10c düzeltme sürümünün sürüm notlarına bakın.

Bir hizmete bağlama

Context.bindService() yöntemi artık açık bir Intent gerektiriyor ve implicit intent verildiğinde istisna atıyor. Uygulamanızın güvenliğini sağlamak için Service'ünüzü başlatırken veya bağlarken açık bir intent kullanın ve hizmet için intent filtreleri tanımlamayın.

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, karma içerik ve üçüncü taraf çerezlerini varsayılan olarak engeller. Karışık içeriğe ve üçüncü taraf çerezlerine izin vermek için sırasıyla setMixedContentMode() ve setAcceptThirdPartyCookies() yöntemlerini kullanın.
- Sistem artık çizilecek HTML dokümanı bölümlerini akıllıca seçiyor. Bu yeni varsayılan davranış, bellek kullanımını azaltmaya ve performansı artırmaya yardımcı olur. Belgenin tamamını tek seferde oluşturmak istiyorsanız enableSlowWholeDocumentDraw() işlevini çağırarak bu optimizasyonu devre dışı bırakın.
Uygulamanız 21'den düşük API düzeylerini hedefliyorsa: Sistem, karma içeriğe ve üçüncü taraf çerezlerine izin verir ve her zaman dokümanın tamamını bir kerede oluşturur.

Özel İzinler İçin Benzersizlik Şartı

İzinler genel bakış sayfasında belirtildiği gibi, Android uygulamaları, platformun önceden tanımlanmış sistem izinlerini kullanmadan bileşenlere erişimi özel bir şekilde yönetmek için özel izinler tanımlayabilir. Uygulamalar, manifest dosyalarında tanımlanan <permission> öğelerinde özel izinleri tanımlar.

Özel izinleri tanımlamanın geçerli ve güvenli bir yaklaşım olduğu birkaç senaryo vardır. Ancak özel izin oluşturmak bazen gereksizdir ve izinlere atanan koruma düzeyine bağlı olarak uygulamada potansiyel risk oluşturabilir.

Android 5.0, izini tanımlayan diğer uygulamalarla aynı anahtarla imzalanmadığı sürece belirli bir özel iznin yalnızca bir uygulama tarafından tanımlanmasını sağlamak için bir davranış değişikliği içerir.

Yinelenen özel izinler kullanan uygulamalar

Her uygulama istediği özel izni tanımlayabilir. Bu nedenle, birden fazla uygulamanın aynı özel izni tanımlaması mümkündür. Örneğin, iki uygulama benzer bir özellik sunuyorsa özel izinleri için aynı mantıksal adı kullanabilir. Uygulamalar, aynı özel izin tanımlarını içeren yaygın herkese açık kitaplıkları veya kod örneklerini de içerebilir.

Android 4.4 ve önceki sürümlerde, kullanıcılar belirli bir cihaza bu tür birden fazla uygulama yükleyebiliyordu. Ancak sistem, ilk yüklenen uygulama tarafından belirtilen koruma düzeyini atıyordu.

Android 5.0'den itibaren sistem, farklı anahtarlarla imzalanan uygulamalar için özel izinlerde yeni bir benzersizlik kısıtlaması uyguluyor. Artık, izni tanımlayan diğer uygulama aynı anahtarla imzalanmadığı sürece, cihazdaki belirli bir özel izni (adıyla belirlenir) yalnızca bir uygulama tanımlayabilir. Kullanıcı, yinelenen özel izne sahip bir uygulamayı yüklemeye çalışırsa ve uygulama, izni tanımlayan yerleşik uygulamayla aynı anahtarla imzalanmamışsa sistem yüklemeyi engeller.

Uygulamanızla ilgili dikkat edilmesi gereken noktalar

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

Göz önünde bulundurmanız gereken bazı noktalar:

Uygulamanız manifest dosyasında <permission> öğeleri beyan ediyor mu? Yanıtınız evetse bu izinler uygulamanızın veya hizmetinizin düzgün çalışması için gerçekten gerekli mi? Bunun yerine sistem varsayılan izinlerini kullanabilir misiniz?
Uygulamanızda <permission> öğeleri varsa bunların nereden geldiğini biliyor musunuz?
Diğer uygulamaların <uses-permission> üzerinden özel izinlerinizi istemesini istiyor musunuz?
Uygulamanızda <permission> öğeleri içeren standart veya örnek kod kullanıyor musunuz? Bu izin öğeleri gerçekten gerekli mi?
Özel izinlerinizde basit adlar mı yoksa diğer uygulamaların paylaşabileceği yaygın terimlere dayalı adlar mı kullanılıyor?

Yeni yüklemeler ve güncellemeler

Yukarıda belirtildiği gibi, Android 4.4 veya önceki sürümleri çalıştıran cihazlarda uygulamanızın yeni yüklemeleri ve güncellemeleri bu durumdan etkilenmez ve davranışta herhangi bir değişiklik olmaz. Android 5.0 veya sonraki sürümleri çalıştıran cihazlarda yeni yükleme ve güncellemelerde, mevcut yerleşik bir uygulama tarafından tanımlanmış özel bir izin tanımlanırsa sistem uygulamanızın yüklenmesini engeller.

Android 5.0 sistem güncellemesi yüklü mevcut yüklemeler

Uygulamanız özel izinler kullanıyorsa ve yaygın olarak dağıtılıp yüklüyse kullanıcılar cihazlarını Android 5.0'e güncellediğinde uygulamanız etkilenebilir. Sistem güncellemesi yüklendikten sonra sistem, özel izinlerinin kontrol edilmesi de dahil olmak üzere yüklü uygulamaları yeniden doğrular. Uygulamanız, zaten doğrulanmış başka bir uygulama tarafından tanımlanmış bir özel izin tanı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ü en kısa sürede kullanıcılarınıza yayınlamanızı öneririz.

Uygulamanızda özel izinler kullanıyorsanız bu izinlerin kaynağına ve gerçekten ihtiyacınız olup olmadığına dikkat edin. Uygulamanızın düzgün çalışması için gerekli olduğundan emin olmadığınız tüm <permission> öğelerini uygulamanızdan kaldırın.
Mümkün olduğunda özel izinlerinizi sistem varsayılan izinleriyle değiştirebilirsiniz.
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 uygulamalar özel izin aracılığıyla paylaşılan bir bileşene 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ı, bunun yerine <uses-permission> mekanizması aracılığıyla erişim istemelidir.
Aynı anahtarla imzalanmış bir uygulama paketiniz varsa her uygulama, ihtiyaca göre aynı özel izinleri tanımlayabilir. Sistem, uygulamaların normal şekilde yüklenmesine izin verir.

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

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

TLSv1.2 ve TLSv1.1 protokolleri artık etkinleştirildi.
AES-GCM (AEAD) şifre paketleri artık etkinleştirildi.
MD5, 3DES, dışa aktarma ve statik anahtar ECDH şifre paketleri artık devre dışı bırakıldı.
İ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ında kesintilere neden olabilir.

Google Play Hizmetleri'ndeki güvenlik ProviderInstaller'ın, Android 2.3 ve önceki Android platform sürümlerinde bu değişiklikleri zaten sunduğunu unutmayın.

Sunucu, etkinleştirilen şifre paketlerinin hiçbirini desteklemiyor

Örneğin, bir sunucu yalnızca 3DES veya MD5 şifre paketlerini destekleyebilir. 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, DHE) 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 örnekleri oluşturacak şekilde tasarlanmalıdır.

Uygulama, sunucuya bağlanmak için kullanılan şifre paketleri hakkında yanlış varsayımlar yapıyor

Örneğin, bazı uygulamalarda authType parametresinin RSA olmasını bekleyen ancak ECDHE_RSA veya DHE_RSA ile karşılaşan özel bir X509TrustManager bulunur.

Sunucu, TLSv1.1, TLSv1.2 veya yeni TLS uzantılarını desteklemiyor

Örneğin, bir sunucuyla TLS/SSL el sıkışması yanlışlıkla reddedilir veya duraklar. Tercih edilen çözüm, sunucuyu TLS/SSL protokolüne uygun olacak şekilde yükseltmektir. Bu, sunucunun bu yeni protokollerle başarılı bir şekilde pazarlık yapmasını veya TLSv1 ya da daha eski protokollerle pazarlık yapmasını ve anlamadığı TLS uzantılarını yoksaymasını sağlar. Bazı durumlarda, sunucu yazılımı yükseltilinceye kadar sunucudaki TLSv1.1 ve TLSv1.2'nin devre dışı bırakılması geçici bir çözüm olarak kullanılabilir.

Alternatif olarak, uygulamayı sunucuyla iletişim kurmak için özel bir SSLSocketFactory kullanacak şekilde değiştirebilirsiniz. Fabrika, yalnızca sunucu tarafından doğru şekilde desteklenen protokollerin etkin olduğu 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. Yönetici, yönetilen profil üzerinde kontrol sahibi olurken kullanıcının kişisel profilini ve depolama alanını kullanıcının kontrolüne bırakır. 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 yönetilen profilden normalde ilgili uygulama tarafından işlenmesi gereken bir intent tetiklerse ve yönetilen profilde intent için uygun bir işleyici yoksa intent bir istisnaya neden olur. Örneğin, cihaz yöneticisi yönetilen profildeki uygulamaların sistemin kamera uygulamasına erişmesini 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 intent'i işleyebilecek bir uygulama yoksa ActivityNotFoundException oluşur.

Bunu önlemek için, herhangi bir intent'i tetiklemeden önce intent için en az bir işleyicinin olup olmadığını kontrol edebilirsiniz. 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 Çekme: Kamera Uygulamasıyla Fotoğraf Çekme başlıklı makalede görebilirsiniz.

Dosyaları profiller arasında 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 dosya URI'si diğerinde geçerli olmaz. Bu durum, genellikle oluşturduğu dosyalara erişen uygulamalar için genellikle sorun teşkil etmez. Ancak bir uygulama bir intent'e dosya eklerse bazı durumlarda intent diğer profilde işlenebilir. Bu nedenle, dosya URI'si eklemek güvenli değildir. Örneğin, bir cihaz yöneticisi, resim yakalama etkinliklerinin kişisel profildeki kamera uygulaması tarafından ele alınması gerektiğini belirtebilir. Intent, yönetilen profildeki bir uygulama tarafından tetikleniyorsa kameranın görüntüyü yönetilen profilin uygulamalarının okuyabileceği bir konuma yazabilmesi gerekir.

Güvende olmak için, bir profilden diğerine geçebilecek bir amaca dosya eklemeniz gerektiğinde dosya için bir içerik URI'si oluşturup kullanmalısınız. Dosyaları içerik URI'leriyle paylaşma hakkında daha fazla bilgi için Dosya Paylaşımı başlıklı makaleyi inceleyin. Örneğin, cihaz yöneticisi ACTION_IMAGE_CAPTURE'ün kişisel profildeki kamera tarafından işlenmesine izin verebilir. Tetikleyici intent'in EXTRA_OUTPUT, fotoğrafın nereye kaydedileceğini belirten bir içerik URI'si içermelidir. Kamera uygulaması, resmi bu URI ile belirtilen konuma yazabilir ve intent'i tetikleyen uygulama, diğer profilde olsa bile bu dosyayı okuyabilir.

Android 5.0'da kilit ekranı widget'ları için destek kaldırılmıştır. Ana ekrandaki widget'lar ise desteklenmeye devam etmektedir.