In Android 9 (und niedriger) gingen SurfaceFlinger und DisplayManagerService davon aus, dass es höchstens zwei physische Displays mit den hartcodierten IDs 0 und 1 gibt. Wie unter Statische Display-IDs beschrieben, nutzt SurfaceFlinger jetzt eine Hardware Composer API (HWC), um stabile Display-IDs zu generieren, mit denen eine beliebige Anzahl von physischen Displays verwaltet werden kann.
Das Framework kann das IBinder-Token für ein physisches Display über SurfaceControl#getPhysicalDisplayToken abrufen, nachdem es die 64‑Bit-Display-ID von SurfaceControl#getPhysicalDisplayIds oder aus einem DisplayEventReceiver-Hotplug-Ereignis abgerufen hat.
Unter Android 10 ist das primäre interne Display TYPE_BUILT_IN und alle sekundären Displays werden unabhängig vom Verbindungstyp als TYPE_HDMI gekennzeichnet. Daher werden zusätzliche interne Displays derzeit als extern behandelt. Als Problemumgehung können im gerätespezifischen Code Annahmen über DisplayAddress.Physical#getPort getroffen werden, wenn der HWC bekannt ist und die Logik der Portzuweisung vorhersehbar ist.
Implementierung
Bisher wurden Displays anhand von 32‑Bit-IDs identifiziert, wobei 0 für das interne Display, 1 für das externe Display, [2, INT32_MAX] für virtuelle HWC-Displays und -1 für ein ungültiges Display oder ein virtuelles Display ohne HWC steht. Damit SurfaceFlinger und DisplayManagerService mehr als zwei Displays erfassen und zuvor gesehene Displays erkennen können, sollten Displays stabile und persistente IDs haben.
Wenn der HWC IComposerClient.getDisplayIdentificationDataunterstützt und Daten zur Displayidentifikation bereitstellt, parset SurfaceFlinger die EDID-Struktur und weist physischen und HWC-virtuellen Displays stabile 64‑Bit-Display-IDs zu. Die IDs werden mit einem Optionstyp angegeben, wobei der Nullwert ein ungültiges Display oder ein virtuelles Display ohne HWC darstellt. Ohne HWC-Unterstützung wechselt SurfaceFlinger zum bisherigen Verhalten mit maximal zwei physischen Displays.