Ekran Desteği

Bu ekrana özel alanlarda yapılan güncellemeler aşağıda verilmiştir:

Etkinlikleri ve ekranları yeniden boyutlandırma

Bir uygulama çoklu pencere modu veya yeniden boyutlandırma desteklemeyebilir belirtmek için faaliyetler kullanmak resizeableActivity=false niteliğini. Etkinlikler yeniden boyutlandırıldığında uygulamaların karşılaştığı yaygın sorunlar şunlardır:

  • Bir etkinlik, uygulamadan veya görsel olmayan başka bir bileşenden farklı bir yapılandırmaya sahip olabilir. Yaygın bir hata, uygulama bağlamından görüntüleme metriklerini okumaktır. Döndürülen değerler, bir etkinliğin görüntülendiği görünür alan metriklerine ayarlanmaz.
  • Bir etkinlik, yeniden boyutlandırmayı ve kilitlenmeyi işleyemez, bozuk bir kullanıcı arayüzü görüntüleyebilir veya örnek durumunu kaydetmeden yeniden başlatma nedeniyle durumunu kaybedebilir.
  • Bir uygulama, çoklu pencerede girişi bozabilecek mutlak giriş koordinatlarını (pencere konumuna göreli olanlar yerine) kullanmayı deneyebilir.

Android 7 (ve üzeri) olarak, bir uygulama seti olabilir resizeableActivity=false her zaman tam ekran modunda çalışacak şekilde. Bu durumda platform, yeniden boyutlandırılamayan etkinliklerin bölünmüş ekrana girmesini engeller. Kullanıcı, halihazırda bölünmüş ekran modundayken başlatıcıdan yeniden boyutlandırılamayan bir etkinlik başlatmaya çalışırsa, platform bölünmüş ekran modundan çıkar ve yeniden boyutlandırılamayan etkinliği tam ekran modunda başlatır.

Açıkça bu özelliği ayarlamak Uygulamalar false uyumluluk modu uygulandığı sürece Manifestte, çoklu pencere modunda başlatılan edilmemelidir:

  • Tüm aktiviteleri ve aktivite dışı bileşenleri içeren sürece aynı konfigürasyon uygulanır.
  • Uygulanan yapılandırma, uygulama uyumlu ekranlar için CDD gereksinimlerini karşılar.

Android 10'da platform, yeniden boyutlandırılamayan etkinliklerin bölünmüş ekran moduna geçmesini yine de engeller, ancak etkinlik sabit bir yön veya en boy oranı bildirmişse, bunlar geçici olarak ölçeklenebilir. Değilse, etkinlik, Android 9 ve önceki sürümlerde olduğu gibi tüm ekranı dolduracak şekilde yeniden boyutlandırılır.

Varsayılan uygulama aşağıdaki politikayı uygular:

Bir etkinlik kullanımı yoluyla çoklu pencere ile uyumlu olarak ilan zaman android:resizeableActivity nitelik ve bu etkinliğin koşullardan biri, aşağıda tarif karşıladığında uygulanan ekran yapılandırması değiştirmek gerektiğinde, o zaman, etkinlik ve işlem orijinal konfigürasyon ile kaydedilir ve kullanıcıya, güncellenmiş ekran yapılandırmasını kullanmak için uygulama sürecini yeniden başlatma olanağı sağlanır.

  • Uygulanması yoluyla sabit yönlendirme mi android:screenOrientation
  • Uygulama, API düzeyini hedefleyerek varsayılan maksimum veya minimum en boy oranına sahiptir veya en boy oranını açıkça beyan eder

Bu şekil, beyan edilmiş bir en boy oranına sahip, yeniden boyutlandırılamayan bir etkinliği gösterir. Aygıtı katlarken, uygun mektup kutusu kullanılarak en-boy oranı korunurken pencere alana sığacak şekilde küçültülür. Ayrıca, aktivitenin görüntülenen alanı her değiştirildiğinde kullanıcıya bir aktiviteyi yeniden başlatma seçeneği sunulur.

Aygıtı açarken etkinliğin yapılandırması, boyutu ve en boy oranı değişmez, ancak etkinliği yeniden başlatma seçeneği görüntülenir.

Ne zaman resizeableActivity (ya da ayarlandığında ayarlı değil true ), uygulamanın tam boyutlandırma destekler.

uygulama

Sabit yönlendirmeye veya en boy oranına sahip yeniden boyutlandırılamayan bir etkinliğe kodda boyut uyumluluk modu (SCM) adı verilir. Koşul tanımlanan ActivityRecord#shouldUseSizeCompatMode() . Bir SCM etkinliği başlatıldığında, ekranla ilgili yapılandırma (boyut veya yoğunluk gibi) istenen geçersiz kılma yapılandırmasında sabitlenir, bu nedenle etkinlik artık mevcut ekran yapılandırmasına bağlı değildir.

SCM etkinliği tüm ekranı dolduramıyorsa, üste hizalanır ve yatay olarak ortalanır. Etkinlik sınırları tarafından hesaplanır AppWindowToken#calculateCompatBoundsTransformation() .

Bir SCM aktivitesi kabı farklı bir ekran konfigürasyonunu kullanarak, (örneğin, ekran yeniden boyutlandırılır ya da aktivite bir ekrana taşındı), ActivityRecord#inSizeCompatMode() doğru ve bir SizeCompatModeActivityController (Sistem arayüzünde) işlemi göstermek için bir geri arama alır yeniden başlat düğmesi.

Ekran boyutları ve en boy oranları

Android 10, uzun ve ince ekranların yüksek oranlarından 1:1 oranlarına kadar yeni en boy oranları için destek sağlar. Uygulamalar tanımlayabilirsiniz ApplicationInfo#maxAspectRatio ve ApplicationInfo#minAspectRatio onlar üstesinden olduklarını ekranın.

Android 10 desteklenen Şekil 1: Örnek uygulama oranları

Cihaz uygulamaları boyutları ve Android 9 gerektirdiğine göre daha küçük çözünürlüklerde ikincil görüntüler, ve (2.5 inç olan minimum genişlik veya yükseklik, 320 DP minimum düşürebilir smallestScreenWidth opt Bu küçük görüntüler olabilir desteklemek için), ancak aktivitelerini oraya yerleştirildi.

Uygulamalar, hedef görüntüleme boyutuna eşit oe'den daha küçük bir desteklenen minimum boyut bildirerek etkinleştirebilir. Kullanım android:minHeight ve android:minWidth bunu AndroidManifest etkinlik düzeni özelliklerini.

Görüntüleme politikaları

Android 10 ayırır ve hamle varsayılan belirli ekran politikaları WindowManagerPolicy içinde uygulanması PhoneWindowManager gibi başına ekrana sınıflara,:

  • Ekran durumu ve döndürme
  • Bazı tuşlar ve hareket olayı izleme
  • Sistem kullanıcı arayüzü ve dekorasyon pencereleri

Android 9 (ve daha düşük), In PhoneWindowManager sınıfı ele ekran politikaları, devlet ve ayarlara, döndürme, dekorasyon pencere çerçevesi izleme ve daha fazlası. Android için en çok bu 10 hamle DisplayPolicy sınıfına taşındı rotasyon takibi için hariç DisplayRotation .

Ekran penceresi ayarları

Android 10'da, yapılandırılabilir ekran başına pencere ayarı aşağıdakileri içerecek şekilde genişletildi:

  • Varsayılan ekran pencereleme modu
  • Aşırı tarama değerleri
  • Kullanıcı döndürme ve döndürme modu
  • Zorunlu boyut, yoğunluk ve ölçekleme modu
  • İçerik kaldırma modu (ekran kaldırıldığında)
  • Sistem süslemeleri ve IME desteği

DisplayWindowSettings sınıf Bu seçenekler için ayarlar bulunur. Onlar disk içinde kalıcıdır konum /data Bölümün display_settings.xml bir ayar değiştirilirse her zaman. Ayrıntılar için bkz DisplayWindowSettings.AtomicFileStorage ve DisplayWindowSettings#writeSettings() . Cihaz üreticileri içinde varsayılan değerler sağlayabilir display_settings.xml onların aygıt yapılandırması için. Dosya saklanır Ancak, /data , ek mantık mendil bir silinmesini, dosyayı geri için gerekli olabilir.

Varsayılan olarak, Android 10 kullanan DisplayInfo#uniqueId ayarlarını ısrarlı zaman gösterilmesi için bir tanımlayıcı olarak. uniqueId tüm ekranlar için doldurulmalıdır. Ayrıca, fiziksel ve ağ ekranları için kararlıdır. Bu ayarlanabilir tanımlayıcı olarak fiziksel bir ekran, limanını kullanmak da mümkündür DisplayWindowSettings#mIdentifier . Her yazmada, tüm ayarlar yazılır, böylece depolamada bir ekran girişi için kullanılan anahtarı güncellemek güvenlidir. Ayrıntılar için bkz Statik ekran tanımlayıcıları .

Ayarlar kalıcıyken /data tarihi nedenlerden ötürü dizinde. Başlangıçta, ekran döndürme gibi kullanıcı tarafından belirlenen ayarları sürdürmek için kullanılıyorlardı.

Statik görüntü tanımlayıcıları

Android 9 (ve daha düşük sürümler), çerçevedeki görüntüler için kararlı tanımlayıcılar sağlamadı. Bir görüntüleme sistemine ilave edildiğinde Display#mDisplayId veya DisplayInfo#displayId statik bir sayacın saymaya ekranda bu oluşturulmuştur. Sistem aynı ekranı ekleyip kaldırdıysa, farklı bir kimlik ortaya çıktı.

Bir aygıtın önyüklemeden itibaren birden fazla ekranı varsa, zamanlamaya bağlı olarak ekranlara farklı tanımlayıcılar atanabilir. Android 9 (ve öncesi) dahil ederken DisplayInfo#uniqueId , fiziksel görüntüler ya olarak tanımlandı çünkü ekranlar arasında ayrım yapmak yeterli bilgi içermiyordu local:0 veya local:1 dahili ve harici ekranı temsil etmek.

Android 10 değişiklikler DisplayInfo#uniqueId istikrarlı tanımlayıcı eklemek ve yerel, ağ ve sanal ekranlar arasında ayrım yapmak.

Ekran tipi Biçim
Yerel
local:<stable-id>
network:<mac-address>
Gerçek
virtual:<package-name-and-name>

Güncellemeleri ek olarak uniqueId , DisplayInfo.address içeren DisplayAddress , yeniden doğmuş genelinde istikrarlı bir görüntü tanımlayıcı. Android 10 yılında DisplayAddress fiziksel ve ağ ekranları destekler. DisplayAddress.Physical (aynı sabit bir görüntü kimliğini içeren uniqueId ) ile oluşturulabilir DisplayAddress#fromPhysicalDisplayId() .

Android 10 de bağlantı noktası bilgi almak için uygun bir yöntem sağlar ( Physical#getPort() ). Bu yöntem, çerçeve içinde ekranları statik olarak tanımlamak için kullanılabilir. Örneğin, içinde kullanılan DisplayWindowSettings ). DisplayAddress.Network MAC adresini içerir ve ile oluşturulabilir DisplayAddress#fromMacAddress() .

Bu eklemeler, cihaz üreticilerinin statik çoklu ekran kurulumlarındaki ekranları tanımlamasına ve fiziksel ekranlar için bağlantı noktaları gibi statik ekran tanımlayıcıları kullanarak farklı sistem ayarlarını ve özelliklerini yapılandırmasına olanak tanır. Bu yöntemler gizlidir ve içinde kullanılmak üzere yalnızca amaçlanan system_server .

Bir HWC görüntü kimliği (opak olabilir ve her zaman sabit olmayabilir) verildiğinde, bu yöntem, ekranın EDID bloğunun yanı sıra görüntü çıkışı için fiziksel bir bağlayıcıyı tanımlayan (platforma özgü) 8 bitlik bağlantı noktası numarasını döndürür. SurfaceFlinger, çerçeveye maruz kalan kararlı 64 bit ekran kimliklerini oluşturmak için EDID'den üretici veya model bilgilerini çıkarır. Bu yöntem desteklenen veya hatalar dışarı değilse, SurfaceFlinger'a geri eski MD moduna düşüyor DisplayInfo#address null ve DisplayInfo#uniqueId yukarıda açıklandığı gibi, kodlanmış olduğunu.

Bu özelliğin desteklendiğini doğrulamak için şunu çalıştırın:

$ dumpsys SurfaceFlinger --display-id
# Example output.
Display 21691504607621632 (HWC display 0): port=0 pnpId=SHP displayName="LQ123P1JX32"
Display 9834494747159041 (HWC display 2): port=1 pnpId=HWP displayName="HP Z24i"
Display 1886279400700944 (HWC display 1): port=2 pnpId=AUS displayName="ASUS MB16AP"

İkiden fazla ekran kullanma

Android 9 (ve daha düşük) olarak, SurfaceFlinger'a ve DisplayManagerService kodlanmış kimlikleri 0 ve 1 ile en fazla iki fiziksel ekranlara varlığını üstlendi.

Android 10'dan başlayarak, SurfaceFlinger, sabit ekran kimlikleri oluşturmak için bir Donanım Besteci (HWC) API'sinden yararlanabilir ve bu da isteğe bağlı sayıda fiziksel ekranı yönetmesini sağlar. Daha fazla bilgi için bkz Statik ekran tanımlayıcıları .

Çerçeve bakabilirsiniz IBinder ile fiziksel bir görüntü için belirteç SurfaceControl#getPhysicalDisplayToken 64 bit görüntü kimliğini aldıktan sonra SurfaceControl#getPhysicalDisplayIds veya gelen DisplayEventReceiver Safe etkinliği.

Android 10 (ve daha düşük), birincil iç ekran TYPE_INTERNAL ve tüm ikincil görüntüler olarak işaretlenir TYPE_EXTERNAL bakılmaksızın bağlantı türü. Bu nedenle, ek dahili ekranlar harici olarak kabul edilir. Çözüm olarak, cihaza özel kodu ile ilgili varsayımlar yapabilirsiniz DisplayAddress.Physical#getPort HWC biliniyorsa ve port tahsisi mantık tahmin edilebilir.

Bu sınırlama, Android 11'de (ve sonraki sürümlerde) kaldırılmıştır.

  • Android 11'de, önyükleme sırasında bildirilen ilk ekran, birincil ekrandır. Bağlantı türü (iç veya dış) önemsizdir. Bununla birlikte, birincil ekranın bağlantısının kesilemeyeceği ve pratikte dahili bir ekran olması gerektiği doğru kalır. Bazı katlanabilir telefonların birden fazla dahili ekranı olduğunu unutmayın.
  • İkincil görüntüler doğru olarak kategorize edilir Display.TYPE_INTERNAL veya Display.TYPE_EXTERNAL (eski adı Display.TYPE_BUILT_IN ve Display.TYPE_HDMI bunların bağlantı tipine bağlı olarak, sırasıyla).

uygulama

Android 9 ve alt olarak, görüntüler 0 iç ekran 32-bit kimlikleri, ile tanımlanır, 1 dış ekran, [2, INT32_MAX] HWC sanal görüntüler ve -1 geçersiz ekran ya da olmayan bir HWC temsil sanal ekran.

Android 10 ile başlayarak, görüntüler SurfaceFlinger'a ve izin veren istikrarlı ve kalıcı kimlikleri, verilen DisplayManagerService İkiden fazla ekranı izlemek ve daha önce görülen görüntüler tanımak için. HWC destekliyorsa IComposerClient.getDisplayIdentificationData ve ekran kimlik verileri sağlar, SurfaceFlinger'a EDID yapısı ve fiziksel ve HWC sanal ekranlar için ayırdığı kararlı 64 bit ekran kimlikleri ayrıştırır. Kimlikler, boş değerin geçersiz bir ekranı veya HWC olmayan sanal ekranı temsil ettiği bir seçenek türü kullanılarak ifade edilir. HWC desteği olmadan, SurfaceFlinger en fazla iki fiziksel ekranla eski davranışa geri döner.

Ekran başına odak

Tek tek ekranları aynı anda hedefleyen birkaç giriş kaynağını desteklemek için Android 10, ekran başına en fazla bir tane olmak üzere birden çok odaklanmış pencereyi destekleyecek şekilde yapılandırılabilir. Bu, yalnızca birden fazla kullanıcının aynı cihazla aynı anda etkileşimde bulunduğu ve Android Automotive gibi farklı giriş yöntemleri veya cihazları kullandığı özel cihaz türleri için tasarlanmıştır.

Kuvvetle bu özellik masaüstünde benzeri deneyimler için kullanılan çoklu ekran cihazlar veya olanlar dahil düzenli cihazlar için etkin olamaz önerilir. Bu, öncelikle, kullanıcıların hangi pencerenin giriş odağı olduğunu merak etmelerine neden olabilecek bir güvenlik endişesinden kaynaklanmaktadır.

Bir metin giriş alanına güvenli bilgiler giren, belki bir bankacılık uygulamasında oturum açan veya hassas bilgiler içeren metin giren bir kullanıcıyı hayal edin. Kötü amaçlı bir uygulama, bir metin giriş alanı da dahil olmak üzere, bir etkinliği yürütmek için sanal bir ekran dışı görüntü oluşturabilir. Meşru ve kötü niyetli etkinliklere odaklanılır ve her ikisi de etkin bir giriş göstergesi (yanıp sönen imleç) görüntüler.

Ancak, bir klavyeden (donanım veya yazılım) girdi yalnızca en üstteki etkinliğe (en son başlatılan uygulama) girildiğinden, gizli bir sanal ekran oluşturarak kötü amaçlı bir uygulama, bir yazılım klavyesi kullanırken bile kullanıcı girdisini alabilir. birincil cihaz ekranında.

Kullanım com.android.internal.R.bool.config_perDisplayFocusEnabled seti başına ekrana odak için.

uyumluluk

Sayı: In Android 9 ve sistemdeki alt, en çok bir pencere bir anda odak vardır.

Çözüm: Aynı süreçten iki pencere odaklı olacağını nadir durumda, sistem Z-sırasına göre daha yüksek olduğunu pencereye sadece odak sağlar. Bu kısıtlama, Android 10'u hedefleyen uygulamalar için kaldırılmıştır; bu noktada, aynı anda odaklanan birden çok pencereyi desteklemeleri beklenir.

uygulama

WindowManagerService#mPerDisplayFocusEnabled bu özelliğin kullanımını kontrol eder. In ActivityManager , ActivityDisplay#getFocusedStack() şimdi bir değişkene yerine küresel izleme kullanılır. ActivityDisplay#getFocusedStack() Z-sırasına yerine değeri önbelleğe alma üzerindeki odağı belirler. Bu, yalnızca bir kaynak olan WindowManager'ın etkinliklerin Z sırasını izlemesi gerektiği içindir.

ActivityStackSupervisor#getTopDisplayFocusedStack() sisteminde üstteki odaklanmış yığını tespit gereken durumlarda için benzer bir yaklaşım getiriyor. Yığınlar yukarıdan aşağıya doğru hareket ettirilir ve ilk uygun yığın aranır.

InputDispatcher artık birden odaklanmış pencereler (ekranın başına bir) sahip olabilir. Bir giriş olayı ekrana özelse, ilgili ekranda odaklanılan pencereye gönderilir. Aksi takdirde, kullanıcının en son etkileşimde bulunduğu ekran olan odaklanmış ekrandaki odaklanmış pencereye gönderilir.

Bkz InputDispatcher::mFocusedWindowHandlesByDisplay ve InputDispatcher::setFocusedDisplay() . Odaklanmış uygulamalar da içinden InputManagerService ayrı güncellenmektedir NativeInputManager::setFocusedApplication() .

In WindowManager , pencereleri de ayrı ayrı izlenir duruldu. Bkz DisplayContent#mCurrentFocus ve DisplayContent#mFocusedApp ve ilgili kullanımları. İlgili odak takibi ve güncellenmesi yöntemleri taşındı WindowManagerService için DisplayContent .