Android 5.0 Davranış Değişiklikleri

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

Dev Byte: 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 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() 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ı tek seferde 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 Ş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.