API Düzeyi: 21
Android 5.0, yeni özellikler ve imkanların 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 bir 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'un öne çıkan özellikleri bölümüne göz atın.
Videolar
Dev Byte: Android 5.0'daki Yenilikler
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 ile tanışın bölümüne bakın. Önemli yeni özelliklerden bazıları şunlardır:
- Ahead-of-time (AOT) derlemesi
- İyileştirilmiş çöp toplama (GC)
- Geliştirilmiş hata ayıklama desteği
Çoğu Android uygulaması ART kapsamında hiçbir değişiklik olmadan çalışı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 üreten geliştirme araçları (bazı kod karartıcılar gibi) kullanıyorsunuz.
- Çöp toplamayla 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 üzere bildirim tasarım kılavuzuna bakın.
Materyal tasarım stili
Bildirimler, yeni materyal tasarım widget'larıyla eşleşmesi için beyaz (veya çok açık) arka planların üzerine koyu renk metinle çiziliyor. 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 bir vurgu rengi ayarlamak için
setColor()
düğmesini kullanın. - Renk içeren öğeleri güncelleyin veya kaldırın. Sistem, işlem simgelerinde ve ana bildirim simgesinde 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 ç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 doğru şekilde öncelikli modda 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
olarak ayarlarsanız
cihaz
öncelik modundan çıkar.
Android daha önce tablet cihazlarda ses seviyesini kontrol etmek için ana akış olarak STREAM_MUSIC
kullanıyordu. Android 5.0'da, hem telefon hem de tablet cihazlar için 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 sürümünde 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 sistem tarafından 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 bir RemoteViews.RemoteView
nesnesi yerine yeni Notification.MediaStyle
şablonunu kullanmayı düşünün. Hangi yaklaşımı seçerseniz seçin, kontrollerinize kilit ekranından erişilebilir olması için bildirimin görünürlüğünü VISIBILITY_PUBLIC
olarak ayarladığınızdan emin olun. Android 5.0'dan itibaren sistemin artık kilit ekranında RemoteControlClient
nesnelerini 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 (yani cihazın kilidi ve ekranı açıkken) küçük bir kayan pencerede (uyarı bildirimi olarak da adlandırılır) görünebilir. Bu bildirimler, bildiriminizin küçük biçimine benzer bir şekilde görünür. Tek fark, uyarı bildiriminde işlem düğmelerini de göstermesidir. Kullanıcılar geçerli uygulamadan ayrılmadan uyarı bildirimleriyle ilgili işlem yapabilir veya bildirimleri kapatabilir.
Uyarı bildirimlerini tetikleyebilecek koşul örnekleri şunlardır:
- Kullanıcının etkinliği tam ekran modundadır (uygulama
fullScreenIntent
kullanır) - Bildirim yüksek önceliğe sahip olup 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ında, MediaSession
veya RemoteControlClient
cihazlarınız için taşıma kontrolleri gösterilmez. Bunun yerine uygulamanız 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 kullanıcılara kilitli ve kilidi açık cihazlarda tutarlı bir deneyim sunar.
Android 5.0, bu amaç için yeni bir
Notification.MediaStyle
şablonunu kullanıma sunuyor.
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. Bu bildirimin devam eden bir medya oturumunu kontrol ettiğini sisteme bildirmek için oturum jetonunuzu setSession()
yöntemine iletin.
Bildirimi herhangi bir kilit ekranında (güvenli veya başka bir ş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 MediaSession
özelliğini de uygulamanız gerekir.
getNearbyTasks()
Android 5.0'da yeni eşzamanlı doküman 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 artık kullanımdan kaldırılmıştır. Geriye dönük uyumluluk için bu yöntem yine de çağıran uygulamanın kendi görevleri ve muhtemelen hassas olmayan diğer görevler (ör. Home) 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()
kullanın.
Android NDK'da 64 Bit Destek
Android 5.0, 64 bit sistemler için destek sunuyor. 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'nin 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 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'daki ö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ü amaç verilirse istisna oluşturur.
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 intent 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, karma içeriği ve üçüncü taraf çerezlerini varsayılan olarak engeller. Karma içerik ve üçüncü taraf çerezlerine izin vermek için sırasıyla
setMixedContentMode()
vesetAcceptThirdPartyCookies()
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ı tek seferde oluşturmak istiyorsanız
enableSlowWholeDocumentDraw()
yöntemini çağırarak bu optimizasyonu devre dışı bırakın.
- Sistem, karma içeriği ve üçüncü taraf çerezlerini varsayılan olarak engeller. Karma içerik ve üçüncü taraf çerezlerine izin vermek için sırasıyla
- 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 Şartı
İzinler'e genel bakış bölümünde de açıklandığı gibi Android uygulamaları, platformun önceden tanımlanmış sistem izinlerini kullanmadan, bileşenlere erişimi özel bir şekilde yönetmenin bir yolu olarak özel izinler tanımlayabilir. Uygulamalar, manifest dosyalarında tanımlanan
<permission>
öğelerinde özel izinler tanımlar.
Özel izinler tanımlamanın meşru ve güvenli bir yaklaşım olduğu birkaç senaryo vardır. Bununla birlikte, özel izinler oluşturmak bazen gereksizdir ve izinlere atanan koruma düzeyine bağlı olarak bir uygulama için potansiyel riskler doğurabilir.
Android 5.0, belirli bir özel izni tanımlayan diğer uygulamalarla aynı anahtarla imzalanmadığı sürece yalnızca bir uygulamanın belirli bir izni tanımlayabilmesini sağlamak için davranış değişikliği içerir.
Yinelenen özel izinler kullanan uygulamalar
Herhangi bir uygulama kendi istediği özel izni tanımlayabilir. Bu nedenle, birden fazla uygulama aynı özel izni tanımlayabilir. Örneğin, benzer işlev sunan iki uygulama, özel izinleri için aynı mantıksal adı türetebilir. Uygulamalar, aynı özel izin tanımlarını içeren ortak halk kitaplıkları veya kod örnekleri de içerebilir.
Android 4.4 ve önceki sürümlerde kullanıcılar bu tür birden fazla uygulamayı belirli bir cihaza yükleyebiliyordu. Buna rağmen sistem, ilk yüklenen uygulamanın belirttiği koruma düzeyini atabiliyordu.
Android 5.0 sürümünden itibaren sistem, farklı anahtarlarla imzalanmış uygulamalar için özel izinler üzerinde yeni bir benzersizlik kısıtlaması getirmektedir. Artık bir cihazdaki belirli bir özel izni, izni tanımlayan diğer uygulama aynı anahtarla imzalanmadığı sürece, yalnızca bir uygulama (adına göre belirlendiği şekilde) 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 önceden olduğu 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ın manifest dosyasında
<permission>
öğesi beyan ediliyor mu? Öyleyse uygulamanızın veya hizmetinizin düzgün çalışması için bunlar gerçekten gerekli mi? Bunun yerine bir sistem varsayılan izni 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 izinleriniz, diğer uygulamaların paylaşabileceği yaygın terimleri temel alan veya basit adlar kullanıyor mu?
Yeni yüklemeler ve güncellemeler
Yukarıda da bahsedildiği gibi, Android 4.4 veya önceki sürümleri çalıştıran cihazlara 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 cihazlardaki yeni yüklemeler ve güncellemeler için sistem, mevcut bir yerleşik uygulama tarafından önceden tanımlanmış özel bir izni tanımlarsa sistem, uygulamanızın yüklenmesini engeller.
Android 5.0 sistem güncellemesine sahip 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'a güncellemelerini aldığında bu durumdan etkilenebilir. Sistem güncellemesi yüklendikten sonra sistem, özel izinlerinin kontrol edilmesi de dahil olmak üzere yüklü uygulamaları yeniden doğrular. Uygulamanız daha önce doğrulanmış başka bir uygulama tarafından 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 mümkün olan 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 tüm
<permission>
öğelerini uygulamanızdan kaldırın. - Mümkün olduğunda özel izinlerinizi sistem varsayılan izinleriyle değiştirmeniz iyi bir fikir olabilir.
- 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, 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 olarak 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, 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 yapılmıştır.
- 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ışı bırakılmıştı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ında kesintilere neden olabilir.
Google Play Hizmetleri'ndeki Güvenlik Sağlayıcısı Yükleyici'nin, bu değişiklikleri Android 2.3 ve daha sonraki tüm Android platformu sürümlerinde zaten sunduğunu unutmayın.
Sunucu, etkinleştirilmiş ş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 ve protokolleri sağlamak için sunucunun yapılandırmasını iyileştirmektir. İdeal olarak, TLSv1.2 ile AES-GCM etkinleştirilmelidir ve İ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 çalışmayan ö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 çözüm, sunucuyu TLS/SSL protokolüne uyacak şekilde yükseltmektir. Bu işlem, sunucunun yeni protokoller üzerinde başarılı bir şekilde anlaşmasını ya da TLSv1 veya daha eski protokolleri anlaşmasını ve anlamadığı TLS uzantılarını yoksaymasını sağlar. Bazı durumlarda, sunucu yazılımı yükseltilene kadar TLSv1.1 ve TLSv1.2'nin devre dışı bırakılması 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 protokoller etkinken 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 denetimi altındayken yöneticiye yönetilen profil üzerinde kontrol olanağı verir. 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 amaç tetiklerse ve yönetilen profilde amaç için 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ıyorsa ve yönetilen profilde bu amacı işleyebilecek bir uygulama yoksa bu işlem ActivityNotFoundException
olarak sonuçlanır.
Etkinleştirmeden önce herhangi bir amaç için en az bir işleyici olup olmadığını kontrol ederek bunu önleyebilirsiniz. Geçerli bir işleyici olup olmadığını kontrol etmek için Intent.resolveActivity()
numaralı telefonu arayın. Bunun bir örneğini Fotoğraf Çekme: Kamera Uygulamasıyla Fotoğraf Çekme 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'si diğer profilde geçerli değildir. Bu, genellikle yalnızca oluşturduğu dosyalara erişen uygulamalar için normalde 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. Amaç, yönetilen profildeki bir uygulama tarafından etkinleştirilirse kameranın, görüntüyü yönetilen profilin uygulamalarının okuyabileceği bir konuma yazabilmesi gerekir.
Güvenliği sağlamak amacıyla, bir profilden diğerine geçebilecek bir amaca dosya eklemeniz gerektiğinde, dosya için bir içerik URI'si oluşturup kullanmanız gerekir. Dosyaları içerik URI'leriyle paylaşma hakkında daha fazla bilgi için Dosya Paylaşma konusuna bakın.
Örneğin, cihaz yöneticisi kişisel profildeki kamera tarafından ACTION_IMAGE_CAPTURE
uygulamasının işlenmesine izin verebilir. Tetikleme amacının EXTRA_OUTPUT
özelliği, fotoğrafın nerede depolanması gerektiğini 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ına yönelik desteği kaldırır; ana ekrandaki widget'ları desteklemeye devam eder.