Anforderungen an Media für die Quelldatenverifikation (SDV)

Die Schlüsselwörter MUSS, MÜSSEN, SOLLTE und DRINGEND EMPFOHLEN in diesem Dokument sind wie in RFC 2119 beschrieben zu interpretieren.

Gastsystem (VM-Image)

Die Anforderungen in diesem Abschnitt gelten für das Gastsystem.

Arbeitsspeicher

Das System MUSS mindestens 2 GB Arbeitsspeicher pro VM bereitstellen.

Binärschnittstellen

Geräteimplementierungen:

  • MÜSSEN mit mindestens einer definierten Android NDK ABI kompatibel sein.
  • MÜSSEN für alle VM-Images auf demselben Gerät dieselbe Android NDK ABI verwenden.
  • MÜSSEN mit jeder erforderlichen Bibliothek in der folgenden Liste quellcodekompatibel (z. B. headerkompatibel) und binärkompatibel (für die ABI) sein.
  • MÜSSEN alle folgenden Bibliotheken, die native APIs bereitstellen, für SDV-Apps verfügbar machen:
    • libc (C-Bibliothek)
    • libdl (dynamischer Linker)
    • libdrm.so (Direct Rendering Manager-Userspace-Bibliothek)
    • libgbm.so (Generic Buffer Management)
    • libEGL.so (native OpenGL-Oberflächenverwaltung)
    • libGLESv1_CM.so (OpenGL ES 1.x)
    • libGLESv2.so (OpenGL ES 2.0)
    • libGLESv3.so (OpenGL ES 3.x)
    • liblog (Android-Protokollierung)
    • libtinyalsav2.so (Audioaufnahme und ‑wiedergabe)
    • libvulkan.so (Vulkan)
  • DÜRFEN die öffentlichen Funktionen für die oben genannten nativen Bibliotheken nicht hinzufügen oder entfernen.
  • MÜSSEN alle Funktionssymbole von OpenGL ES 3.1 und Android Extension Pack, wie im NDK definiert, über die Bibliothek „libGLESv3.so“ exportieren. Alle Symbole MÜSSEN vorhanden sein. OpenGL ES beschreibt jedoch genauer die Anforderungen für den Zeitpunkt, zu dem die vollständige Implementierung der jeweiligen Funktion erwartet wird.
  • MÜSSEN die Funktionssymbole von Vulkan 1.1 sowie die Erweiterungen VK_KHR_surface, VK_KHR_swapchain, VK_KHR_maintenance1 und VK_KHR_get_physical_device_properties2 über die Bibliothek libvulkan.so exportieren. Alle Symbole MÜSSEN vorhanden sein. Vulkan beschreibt jedoch genauer die Anforderungen für den Zeitpunkt, zu dem die vollständige Implementierung der jeweiligen Funktion erwartet wird.
  • SOLLTEN mit dem Quellcode und den Headerdateien erstellt werden, die im Upstream-Open-Source-Projekt für Android verfügbar sind.

Grafik

  • Das System MUSS virtio-gpu für die hardwarebeschleunigte Grafik verwenden. Der treiberseitige Treiber SOLLTE gfxstream für das Rendering verwenden.

Eingabe

Das Gastsystem MUSS die Unterstützung für Eingabeereignisse enthalten, die vom Hostsystem mit virtio-input weitergeleitet werden.

OpenGL ES

Geräteimplementierungen:

  • MÜSSEN die unterstützten OpenGL ES-Versionen (1.1, 2.0, 3.0, 3.1, 3.2) über die nativen APIs korrekt identifizieren.
  • MÜSSEN für jede unterstützte OpenGL ES-Version alle entsprechenden nativen APIs unterstützen.
  • MÜSSEN sowohl OpenGL ES 1.1 als auch 2.0 unterstützen.
  • DRINGEND EMPFOHLEN wird, OpenGL ES 3.1 zu unterstützen.
  • SOLLTEN OpenGL ES 3.2 unterstützen.
  • MÜSSEN alle anderen implementierten OpenGL ES-Erweiterungen mit den verwalteten OpenGL ES-APIs und nativen APIs melden und DÜRFEN umgekehrt keine Erweiterungsstrings melden, die sie nicht unterstützen.
  • MÜSSEN die folgenden Erweiterungen unterstützen:
    • EGL_EXT_image_dma_buf_import
    • EGL_EXT_image_dma_buf_import_modifiers
    • EGL_KHR_fence_sync
    • EGL_KHR_image_base
    • EGL_KHR_wait_sync
    • GL_OES_EGL_image

Für Geräteimplementierungen wird DRINGEND EMPFOHLEN, OpenGL ES mit der ANGLE-Bibliothek und dem Vulkan-Backend zu implementieren.

Vulkan

Geräteimplementierungen:

  • DRINGEND EMPFOHLEN wird, Vulkan 1.3 zu unterstützen.
  • DÜRFEN keine Vulkan-Variantenversion unterstützen (d. h., der Variantenteil der Vulkan-Kernversion MUSS null sein).
  • MÜSSEN die folgenden Erweiterungen unterstützen:
    • VK_ANDROID_external_memory_android_hardware_buffer
    • VK_EXT_external_memory_dma_buf
    • VK_EXT_queue_family_foreign
    • VK_KHR_external_memory_fd
    • VK_KHR_external_semaphore_fd

Multimedia-Kompatibilität

  • Geräteimplementierungen MÜSSEN die Wiedergabe von rohen Audioinhalten mit den folgenden Merkmalen ermöglichen:

    • Quellformate:Lineares PCM, 16 Bit, 8 Bit, Float
    • Kanäle:Mono, Stereo, gültige Mehrkanal-Konfigurationen mit bis zu acht Kanälen
    • Abtastraten (in Hz):
      • 8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 in den oben aufgeführten Kanalkonfigurationen
      • 96000 in Mono und Stereo

  • Geräteimplementierungen MÜSSEN die Aufnahme von rohen Audioinhalten ermöglichen. Geräteimplementierungen MÜSSEN mindestens die folgenden Merkmale unterstützen:

    • Format:Lineares PCM, 16 Bit
    • Abtastraten:8000, 11025, 16000, 44100, 48000 Hz
    • Kanäle:Mono

  • Geräteimplementierungen SOLLTEN die Aufnahme von rohen Audioinhalten mit den folgenden Merkmalen ermöglichen:

    • Format:Lineares PCM, 16 Bit und 24 Bit
    • Abtastraten:8000, 11025, 16000, 22050, 24000, 32000, 44100, 48000 Hz
    • Kanäle:So viele Kanäle wie Mikrofone auf dem Gerät

  • Geräteimplementierungen MÜSSEN die Audiowiedergabe und ‑aufnahme über die libtinyalsav2.so-API unterstützen, wobei das virtio-sound-Gerät für den Hardwarezugriff verwendet wird, und MÜSSEN die ALSA-API unterstützen.

  • Video-Encoder und ‑Decoder MÜSSEN mindestens eines der planaren oder semiplanaren YUV420 8:8:8-Farbformate unterstützen.

  • Video-Decoder und ‑Encoder MÜSSEN den H.264 AVC-Codec unterstützen.

  • Geräteimplementierungen MÜSSEN H.264 Main Profile Level 3.1 und Baseline Profile unterstützen. Die Unterstützung für beliebige Slice-Anordnung (Arbitrary Slice Ordering, ASO), flexible Makroblockanordnung (Flexible Macroblock Ordering, FMO) und redundante Slices (Redundant Slices, RS) ist optional.

  • Video-Encoder:

    • MÜSSEN die Videocodierungsprofile in Standardauflösung (Standard Definition, SD) in der folgenden Tabelle unterstützen.

    • SOLLTEN die Videocodierungsprofile in High Definition (HD) unterstützen, wie in der folgenden Tabelle angegeben.

      SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
      Videoauflösung 320 × 240 Pixel 720 × 480 Pixel 1280 × 720 Pixel 1920 × 1080 Pixel
      Framerate des Videos 20 fps 30 fps 30 fps 30 fps
      Video bitrate 384 kbit/s 2 Mbit/s 4 Mbit/s 10 Mbit/s

  • Video-Decoder:

    • MÜSSEN die Videodecodierungsprofile in HD 720p in der folgenden Tabelle unterstützen.

    • MÜSSEN die Videodecodierungsprofile in HD 1080p in der folgenden Tabelle unterstützen.

      SD (niedrige Qualität) SD (hohe Qualität) HD 720p HD 1080p
      Videoauflösung 320 × 240 Pixel 720 × 480 Pixel 1280 × 720 Pixel 1920 × 1080 Pixel
      Framerate des Videos 30 fps 30 fps 60 fps 30 fps
      Video bitrate 800 kbit/s 2 Mbit/s 8 Mbit/s 20 Mbit/s

  • Geräteimplementierungen MÜSSEN die Unterstützung für Media-Codecs mit der Video4Linux-API bieten.

  • Geräteimplementierungen MÜSSEN den Zugriff auf einen Hardware-Videodecoder mit der Video4Linux-API ermöglichen.

  • Alle hardwarebeschleunigten Video- und Bild-Encoder MÜSSEN das Codieren von Frames von den Hardwarekameras unterstützen. Geräteimplementierungen MÜSSEN den Hardwarezugriff für die Videocodierung und ‑decodierung über virtio-media ermöglichen.

  • Geräteimplementierungen MÜSSEN den Zugriff auf eine Videokamera mit der Video4Linux-API ermöglichen.

Hostsystem (Hypervisor und Hardware)

Die Anforderungen in diesem Abschnitt gelten für das Hostsystem und die Hypervisor-Umgebung.

Virtualisierung

  • Zusätzlich zu den virtio-Geräten, die für das Core-Profil erforderlich sind, MUSS das Hostsystem Folgendes bereitstellen:
    • virtio-gpu: für virtuelle GPU und Anzeige
    • virtio-input: zum Weiterleiten von Eingabeereignissen (z. B. Touch, Tastatur)
    • virtio-sound: für virtuelle Audiogeräte
    • virtio-video oder virtio-media: für virtuelle Videocodec-Geräte

Eingabe

  • Das Gerät MUSS Eingabegeräte unterstützen und Ereignisse mit virtio-input an Gastsysteme weiterleiten. Das Gerät SOLLTE Eingaben über Zeiger, Schaltflächen und Drehregler unterstützen.