Ekran desteği

Bu görüntülemeye özgü alanlarda yapılan güncellemeler aşağıda sağlanmıştır:

Etkinlikleri ve ekranları yeniden boyutlandırma

Bir uygulamanın çoklu pencere modunu veya yeniden boyutlandırmayı desteklemeyebileceğini belirtmek için etkinlikleri resizeableActivity=false özelliğini kullanır. Genel Etkinlikler yeniden boyutlandırıldığında uygulamaların karşılaştığı sorunlar şunlardır:

  • Bir etkinliğin yapılandırması, uygulamadan veya başka bir uygulamadan farklı olabilir görsel olmayan bileşene sahiptir. Yaygın olarak yapılan bir hata, görüntülü reklam metriklerini uygulamadan okumaktır bağlam. Döndürülen değerler şuradaki görünür alan metriklerine göre ayarlanmaz: gösterilen bir etkinliktir.
  • Bir etkinlik yeniden boyutlandırma ve kilitlenme işlemlerini yerine getiremeyebilir, bozuk bir kullanıcı arayüzü görüntüleyebilir, veya örnek durumu kaydedilmeden yeniden başlatma nedeniyle kaybolabilir.
  • Bir uygulama, mutlak giriş koordinatlarını kullanmaya çalışabilir ( göreceli olarak). Bu, girdinin bozulmasına neden olabilir. Çoklu pencere.

Android 7 (ve sonraki sürümler) cihazlarda uygulama ayarlanabilir Her zaman tam ekran modunda çalışmak için resizeableActivity=false. İçinde Bu durumda platform, yeniden boyutlandırılamayan etkinliklerin bölünmesini önler tıklayın. Kullanıcı, yeniden boyutlandırılamayan bir etkinliği başlatıcıdan çağırmaya çalışırsa Bölünmüş ekran modundayken platform bölünmüş ekran modundan çıkar ve yeniden boyutlandırılamayan etkinliği tam ekran modunda başlatır.

Bu özelliği açıkça false olarak ayarlayan ve manifesto, uyumlu olmadığı sürece çoklu pencere modunda başlatılmamalıdır. uygulandığında:

  • Sürece aynı yapılandırma uygulanır. Bu da tüm etkinlikleri içerir ve etkinlik olmayan bileşenler içerir.
  • Uygulanan yapılandırma, uygulama uyumluluğu için CDD şartlarını karşılıyor görüntüler.

Android 10'da platform, boyutu değiştirilemeyen etkinliklerin bölünmüş ekran moduna geçmesini engeller, ancak Etkinlik sabit bir yön veya en boy oranı beyan etmişse geçici olarak ölçeklendirilir oranı. Aksi takdirde etkinlik, Android'de olduğu gibi ekranın tamamını kaplayacak şekilde yeniden boyutlandırılır. 9 ve altı.

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

Bir etkinlik, üzerinden çoklu pencereyle uyumlu olmadığı bildirildiğinde android:resizeableActivity özelliğinin kullanımını etkinliği aşağıda açıklanan koşullardan birini karşıladığında etkinlik ve işlem orijinal yapılandırma ve kullanıcıya uygulamayı yeniden başlatma uygulama sürecini takip edin.

  • Yönü android:screenOrientation
  • Uygulama, API düzeyini hedefleyerek varsayılan maksimum veya minimum en boy oranına sahip veya en boy oranını açıkça belirtiyorsa

Bu şekilde, belirtilen en boy oranıyla yeniden boyutlandırılamayan bir etkinlik gösteriliyor. Cihaz katlanırken pencere, alana sığacak şekilde küçültülür. uygun sinemaskop kullanarak en boy oranını koruma. Ayrıca, kullanıcıya etkinliği yeniden başlatma seçeneği sağlandığında etkinlik değiştirildiğini gösterir.

Katlanmış durumda olan cihazın yapılandırması, boyutu ve en boy oranı etkinlik değişmez ancak etkinliği yeniden başlatma seçeneği görüntülenir.

resizeableActivity ayarlanmadığında (veya şuna ayarlandığında) true), uygulama yeniden boyutlandırmayı tamamen destekler.

Uygulama

Sabit yönü veya en boy oranı olan ve yeniden boyutlandırılamayan etkinliklere (SCM) özelliklerini de kullanabilirsiniz. Koşul şu şekilde tanımlanır: ActivityRecord#shouldUseSizeCompatMode() SCM etkinliği kullanıma sunulduğunda, ekranla ilgili yapılandırma (boyut veya yoğunluk gibi) istenen geçersiz kılma yapılandırmasına ayarlıdır. Böylece etkinlik artık bağımlı değildir. mevcut ekran yapılandırmasında.

SCM etkinliği ekranın tamamını dolduramıyorsa üste hizalanır ve yatay olarak ortalandı. Etkinlik sınırları şu hesaplamaya göre hesaplanır: AppWindowToken#calculateCompatBoundsTransformation()

Bir SCM etkinliği, kendisinden farklı bir ekran yapılandırması kullandığında kapsayıcı (örneğin, ekran yeniden boyutlandırıldı veya etkinlik başka bir görüntülü ağ), ActivityRecord#inSizeCompatMode() doğru ve SizeCompatModeActivityController (Sistem Kullanıcı Arayüzünde) geri çağırma işlemini gerçekleştirin.

Ekran boyutları ve en boy oranları

Android 10 yeni en boy oranları için destek sağlıyor yüksek oranda uzun ve ince ekranlardan 1:1 oranlarına kadar çeşitli seçeneklerden yararlanabilirsiniz. Uygulamalar, ApplicationInfo#maxAspectRatio ve ekranda görünen ApplicationInfo#minAspectRatio ele alacağız.

Android 10'daki uygulama oranları

Şekil 1. Android'de desteklenen örnek uygulama oranları 10

Cihaz uygulamalarının, farklı boyutlarda Android 9'un gerektirdiğinden daha düşük ve daha düşük çözünürlüklerde (minimum 2.5 inç genişlik veya yükseklik, smallestScreenWidth için minimum 320 DP), ancak yalnızca bu küçük ekranları desteklemeyi seçen etkinlikler inceleyeceğiz.

Uygulamalar, desteklenen minimum boyut beyan ederek şundan daha küçük bir boyut beyan edebilir: veya eşit olması gerekir. android:minHeight ve android:minWidth etkinlik düzeni özelliklerini AndroidManifest yapın.

Görüntüleme politikaları

Android 10 bazı ekranları ayırıp hareket ettirir varsayılan WindowManagerPolicy uygulamasından Görüntülü reklam başına PhoneWindowManager ile şunlar gibi görüntülü dersler:

  • Görüntü durumu ve döndürme
  • Bazı tuşlar ve hareket etkinliği izleme
  • Sistem kullanıcı arayüzü ve dekorasyon pencereleri

Android 9 (ve önceki) sürümlerde, PhoneWindowManager sınıfı işleniyor. görüntüleme politikaları, durum ve ayarlar, döndürme, dekorasyon pencere çerçevesi ve daha fazlası. Android 10, bunların çoğunu Rotasyon izleme hariç, DisplayPolicy sınıfını kullanır. DisplayRotation klasörüne taşındı.

Görüntüleme penceresi ayarları

Android 10'da ekran başına yapılandırılabilir reklam aralık ayarı şunları içerecek şekilde genişletildi:

  • Varsayılan ekran pencere modu
  • Fazla tarama değerleri
  • Kullanıcı döndürme ve döndürme modu
  • Zorunlu boyut, yoğunluk ve ölçeklendirme modu
  • İçerik kaldırma modu (ekran kaldırıldığında)
  • Sistem süslemeleri ve IME için destek

DisplayWindowSettings sınıfı bunlara ilişkin ayarları içerir seçenekleri vardır. Bunlar şurada /data bölümündeki diskte kalıcıdır: Bir ayar her değiştirildiğinde display_settings.xml. Örneğin, için DisplayWindowSettings.AtomicFileStorage ve DisplayWindowSettings#writeSettings(). Cihaz üreticileri şunları yapabilir: cihazları için display_settings.xml dilinde varsayılan değerler sağlar yapılandırma. Ancak, dosya /data konumunda depolandığı için, silme işlemiyle silinirse dosyayı geri yüklemek için ek mantık gerekebilir.

Android 10 varsayılan olarak Devam ederken görüntüleme için tanımlayıcı olarak DisplayInfo#uniqueId Ayarlar'ı tıklayın. uniqueId tüm ekranlar için doldurulmalıdır. İçinde Ayrıca fiziksel ekranlar ve ağ ekranları için kararlıdır. Ayrıca bir sürü tanımlayıcı olarak fiziksel bir ekranın bağlantı noktasını kullanın. Bu bağlantı noktası, DisplayWindowSettings#mIdentifier Her yazma işleminden sonra, tüm ayarlar bir görüntüleme girişi için kullanılan anahtarı güncellemek güvenli olacak şekilde depolama alanına sahip olursunuz. Ayrıntılar için bkz. Statik görüntülü reklam tanımlayıcıları.

Ayarlar, geçmişe ait veriler için /data dizininde saklanır neden. Başlangıçta, kullanıcı tarafından belirlenen şu ayarları korumak için kullanılıyordu: ekran döndürme.

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

Android 9 (ve önceki sürümler), bahsedeceğim. Sisteme bir ekran eklendiğinde, Display#mDisplayId veya DisplayInfo#displayId şuydu: o ekran için statik bir sayaç artırılarak oluşturulur. Eğer aynı ekran eklenip kaldırıldığından farklı bir kimlik ortaya çıktı.

Bir cihazın başlatma sırasında kullanılabilen birden fazla ekranı varsa ekranlar zamanlamaya göre farklı tanımlayıcılar atanmıştır. Android 9 (ve dahil) DisplayInfo#uniqueId dahil olmak üzere, fiziki görüntü kalitesi nedeniyle ekranları birbirinden ayırt etmek için local:0 veya local:1 olarak tanımlanır ve dahili ve harici ekran.

Android 10 DisplayInfo#uniqueId değişiklikleri ve yerel, ağ ve ağ tanımlayıcıları arasında ayrım yapmak için sanal ekranları da kullanabilirsiniz.

Görüntüleme türü Biçim
Yerel 
local:<stable-id>
Ağ 
network:<mac-address>
Sanal 
virtual:<package-name-and-name>

uniqueId güncellemelerine ek olarak, DisplayInfo.address, DisplayAddress, bir yeniden başlatmalarda sabit duran ekran tanımlayıcı. Android'de 10, DisplayAddress fiziksel dönüşümleri destekler ve ağ ekranları. DisplayAddress.Physical, stabil bir veri içeriyor görünen kimliği (uniqueId ile aynıdır) ve DisplayAddress#fromPhysicalDisplayId().

Android 10 ayrıca bağlantı noktası bilgileri (Physical#getPort()). Bu yöntemin kullanılabileceği yerler: tanımlamasına yardımcı olur. Örneğin, DisplayWindowSettings) bilgileri gösterilir. DisplayAddress.Network MAC adresini içerir ve DisplayAddress#fromMacAddress().

Bu eklemeler, cihaz üreticilerinin ekranları statik yapılandırma ve farklı sistem ayarları ile özellikleri yapılandırma Fiziksel ekranlar için bağlantı noktaları gibi statik ekran tanımlayıcılarının kullanılması. Bu yöntemler gizlidir ve yalnızca şurada kullanılmak üzere tasarlanmıştır: system_server

HWC ekran kimliği göz önünde bulundurulduğunda (opak olabilir ve her zaman kararlı olmayabilir) yöntemi, bir ekranın EDID blobunun yanı sıra ekran çıkışı için fiziksel bağlayıcı. SurfaceFlinger, EDID'den üretici veya model bilgilerini çıkarıp bu çerçeveye maruz kalan stabil 64 bit ekran kimliklerini oluşturur. Bu yöntem desteklenmediğinde veya hata oluştuğunda, SurfaceFlinger eski MD moduna dönerse burada DisplayInfo#address null ve DisplayInfo#uniqueId, yukarıda açıklandığı gibi sabit kodlanmıştır.

Bu özelliğin desteklendiğini doğrulamak için şu komutu ç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 önceki sürümler), SurfaceFlinger ve DisplayManagerService sabit kodlu kimlikleri 0 olan en fazla iki fiziksel ekranın olduğu varsayıldı ve 1.

SurfaceFlinger, Android 10 sürümünden itibaren Sabit görüntü kimlikleri oluşturmak için Donanım Oluşturucu (HWC) API'si, bu kimliklerin yönetilmesini sağlar. isteğe bağlı sayıda fiziksel ekran. Daha fazla bilgi edinmek için bkz. Statik görüntülü reklam tanımlayıcıları.

Çerçeve, fiziksel bir değer için IBinder jetonunu arayabilir edindikten sonra SurfaceControl#getPhysicalDisplayToken ile görüntüle SurfaceControl#getPhysicalDisplayIds veya DisplayEventReceiver hotspot etkinliğinden

Android 10 (ve önceki) sürümlerde birincil dahili ekran TYPE_INTERNAL ve tüm ikincil ekranlar TYPE_EXTERNAL olarak işaretlendi bağlantı türünden bağımsız olarak değiştirebilirsiniz. Bu nedenle, diğer dahili ekranlar harici ekran olarak değerlendirilir. Geçici bir çözüm olarak, cihaza özgü kod, HWC biliniyorsa ve bağlantı noktası tahsis ediliyorsa DisplayAddress.Physical#getPort ve mantığın öngörülebilir olmasına dikkat edin.

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

  • Android 11'de başlatma sırasında bildirilen ilk ekran birincil görüntülü reklam. Bağlantı türü (dahili veya harici) alakasız. Bununla birlikte, birincil ekranın bağlantısının kesilemeyeceği doğrudur ve bu yöntem şu şekildedir: pratikte dahili bir ekran olması gerekir. Bazı katlanabilir telefonlarda birden fazla dahili ekranlara yönelik.
  • İkincil ekranlar Display.TYPE_INTERNAL olarak doğru şekilde sınıflandırıldı veya Display.TYPE_EXTERNAL (eski adıyla Display.TYPE_BUILT_IN) ve Display.TYPE_HDMI) gerektirir.

Uygulama

Android 9 ve önceki sürümlerde ekranlar 32 bit kimliklerle tanımlanır. Burada 0 dahili ekran, 1 harici ekran; [2, INT32_MAX] HWC sanal ekranları, -1 ise geçersiz bir ekranı veya HWC olmayan bir sanal ekranı temsil eder.

Android 10'dan itibaren ekranlar kararlı tutulur ve kalıcı kimlikler içerir. Böylece, SurfaceFlinger ve DisplayManagerService ikiden fazla ekranı izlemek ve önceden görülen ekranları tanımak için. HWC IComposerClient.getDisplayIdentificationData özelliğini destekler ve görüntülü reklam SurfaceFlinger, EDID yapısını ayrıştırır ve kararlı Fiziksel ekranlar ve HWC sanal ekranlar için 64 bit ekran kimlikleri. Kimlikler, bir seçenek türü; burada null değer, geçersiz bir görüntülü reklam veya HWC olmayan sanal bir işlemi temsil eder görüntüleyin. SurfaceFlinger, HWC desteği olmadan eski davranışına geri dönüyor. çoğu iki fiziksel ekran.

Ekran başına odak

Aynı anda bağımsız ekranları hedefleyen çeşitli giriş kaynaklarını desteklemek için Android 10 birden fazla telefonu destekleyecek şekilde odaklı pencerelerde, ekran başına en fazla bir tane. Bu yalnızca özel amaçlıdır Birden fazla kullanıcının aynı cihazla etkileşimde bulunduğu cihaz türleri ve farklı giriş yöntemleri veya cihazlar (ör. Android) kullanma Otomotiv.

Bu özelliğin çok ekranlı cihazlar veya masaüstü benzeri cihazlar için kullanılan cihazlar da dahil olmak üzere normal cihazlar paylaşmaya istekli olmalıdır. Bu durum esas olarak, kullanıcıların web sitenizdeki belirli bir giriş odağı olduğunu merak edebilirsiniz.

Bir metin giriş alanına güvenli bilgileri giren kullanıcıyı hayal edin örneğin bir bankacılık uygulamasına giriş yaparak veya ekleyebilirsiniz. Kötü amaçlı bir uygulama, zararlı bir içeriğe sahip sanal bir ekran dışı Bu API, bir metin giriş alanıyla birlikte bir etkinliği yürütmek için kullanılır. Meşru ve Kötü amaçlı işlemler odak noktasıdır ve her ikisinde de etkin bir giriş göstergesi görüntülenir (yanıp sönen imleç).

Ancak, bilgisayar korsanı (donanım veya yazılım) yalnızca en üstteki etkinlik (en son başlatılan uygulama) kötü amaçlı bir uygulama, gizli bir sanal ekran oluşturduğunda birincil cihaz ekranında yazılım klavyesi kullanırken.

com.android.internal.R.bool.config_perDisplayFocusEnabled hesabını kullan ayarlayabilirsiniz.

Uyumluluk

Sorun: Android 9 ve önceki sürümlerde, olduğunu tespit ettik.

Çözüm: Nadir durumlarda, masaüstünden iki pencerenin sistem yalnızca pencereye odaklanıp o kadar kolay olur. Bu kısıtlama, şunları hedefleyen uygulamalar için kaldırılmıştır: Android 10'un kullanıma sunulmasından sonra birden çok pencerenin aynı anda odaklanmasını destekler.

Uygulama

WindowManagerService#mPerDisplayFocusEnabled şunu kontrol eder: kontrol edebilirsiniz. ActivityManager ayında, ActivityDisplay#getFocusedStack() artık genel yerine kullanılıyor bir değişkende izleme. ActivityDisplay#getFocusedStack() değeri önbelleğe almak yerine Z sırasına göre odağı belirler. Böylece, WindowManager, etkinliklerin Z sırasını izlemesi için yeterlidir.

ActivityStackSupervisor#getTopDisplayFocusedStack() şunları alır: sistemin en üstte odaklanan yığının söz konusu olduğu durumlar için benzer bir yaklaşım tanımlanmalıdır. Yığınlar yukarıdan aşağıya doğru çekiliyor ve uygun olan ilk yığına eklenir.

InputDispatcher artık birden fazla odaklanmış pencereye sahip olabilir (ekran başına bir adet). Bir giriş etkinliği görüntülemeye özgüyse gönderilir odaklanılmış pencereye doğru taşıyabilirsiniz. Aksi takdirde, odaklanılan ekranda, kullanıcının belirli bir pencerede etkileşim kurduğunuzda elde edilen gelir.

Bkz. InputDispatcher::mFocusedWindowHandlesByDisplay ve InputDispatcher::setFocusedDisplay(). Odaklanılan uygulamalar da güncellendi Giriş Yöneticisi Hizmeti'nde NativeInputManager::setFocusedApplication()

WindowManager ürününde, odaklanılan pencereler de ayrı olarak izlenir. Bkz. DisplayContent#mCurrentFocus ve DisplayContent#mFocusedApp ve ilgili kullanımlar. İlgili odak izleme ve güncelleme yöntemlerinizin WindowManagerService - DisplayContent.