A partir de 27 de março de 2025, recomendamos usar android-latest-release
em vez de aosp-main
para criar e contribuir com o AOSP. Para mais informações, consulte Mudanças no AOSP.
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Referência da estrutura vr_module
#include <
vr.h
>
Implemente esse HAL para receber callbacks quando um aplicativo de realidade virtual (RV) estiver sendo usado. Os aplicativos de RV têm uma série de requisitos especiais de exibição e desempenho, incluindo:
-
Latência baixa do sensor: a latência total de ponta a ponta da IMU, do acelerômetro e do giroscópio para um callback visível pelo app precisa ser extremamente baixa (normalmente, menos de 5 ms). Isso é necessário para o suporte ao sensor HIFI.
-
Baixa latência de exibição: a latência total de ponta a ponta das chamadas de renderização da GPU até a atualização real da tela precisa ser a mais baixa possível. Isso é feito usando o SurfaceFlinger em um modo de buffer único e garantindo que as chamadas de exibição sejam sincronizadas corretamente com a detecção de tela. Esse comportamento é exposto por uma extensão EGL para aplicativos. Confira abaixo as extensões EGL necessárias para isso.
-
Tela de baixa persistência: as configurações de persistência da tela precisam ser definidas o mais baixo possível, mantendo um brilho razoável. Para uma tela típica com 60 Hz, os pixels precisam ser iluminados por menos de 3,5 ms para serem considerados de baixa persistência. Isso evita o efeito fantasma durante os movimentos em uma configuração de RV e precisa ser ativado no
HAL
lights.h
quando BRIGHTNESS_MODE_LOW_PERSISTENCE estiver definido.
-
Desempenho consistente da GPU e da CPU: quando uma carga de trabalho mista de GPU/CPU é fornecida para um aplicativo de RV com bursts de trabalho em intervalos regulares várias vezes por frame, a programação da CPU precisa garantir que o trabalho da linha de renderização do aplicativo seja executado de forma consistente em 1ms após a programação e concluído antes do final da janela de exibição. Para isso, um único núcleo de CPU precisa ser reservado exclusivamente para a linha de renderização do aplicativo de RV em execução no modo de RV e disponibilizado no cpuset "top-app". Da mesma forma, uma CPU, GPU e clockrate de barramento adequados precisam ser mantidos para garantir que a carga de trabalho de renderização seja concluída no tempo alocado para renderizar cada frame quando a flag POWER_HINT_SUSTAINED_PERFORMANCE tiver sido definida no
power.h
HAL enquanto estiver no modo de RV quando o dispositivo não estiver sendo limitado termicamente.
-
As extensões EGL necessárias precisam estar presentes: todas as configurações de GPU necessárias para permitir os recursos acima são necessárias, incluindo as extensões EGL: EGL_ANDROID_create_native_client_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_EXT_protected_content, EGL_KHR_mutable_render_buffer, EGL_KHR_reusable_sync e EGL_KHR_wait_sync.
-
Relatório térmico preciso: as temperaturas e os limites térmicos precisos precisam ser informados no
HAL
thermal.h
. Especificamente, a temperatura da pele atual precisa ser informada com precisão para DEVICE_TEMPERATURE_SKIN, e o vr_throttling_threshold informado para esse dispositivo precisa informar com precisão o limite de temperatura acima do qual o regulador térmico do dispositivo limita a CPU, a GPU e/ou as frequências de bus abaixo do mínimo necessário para um desempenho consistente (consulte o ponto anterior).
Em geral, espera-se que os fornecedores que implementam esse HAL usem set_vr_mode como uma dica para ativar o ajuste de desempenho específico da RV necessário para qualquer um dos requisitos acima e ativar os recursos do dispositivo ideais para os modos de exibição de RV. A chamada set_vr_mode pode simplesmente não fazer nada se nenhuma otimização estiver disponível ou for necessária para atender aos requisitos acima.
Nenhum método nesse HAL será chamado simultaneamente pelo framework do Android.
Definição na linha
82
do arquivo
vr.h
.
Métodos comuns do módulo. Ela
precisa
ser o primeiro membro de
vr_module
, já que os usuários dessa estrutura podem transmitir um
hw_module_t
para um ponteiro
vr_module
em contextos em que se sabe que o
hw_module_t
faz referência a um
vr_module
.
Definição na linha
89
do arquivo
vr.h
.
Método de conveniência para a implementação do HAL configurar qualquer estado necessário na inicialização do ambiente de execução. Ele é chamado uma vez pelo VrManagerService durante a fase de inicialização. Nenhum método desse HAL será chamado antes da inicialização.
Definição na linha
96
do arquivo
vr.h
.
Definição na linha
110
do arquivo
vr.h
.
void(* set_vr_mode)(struct
vr_module
*module, bool enabled)
|
Defina o estado do modo de RV. Os possíveis estados do parâmetro ativado são: "false": o modo de RV está desativado, desative todas as configurações específicas de RV. "true": o modo de RV está ativado, ative todas as configurações específicas de RV.
Isso é chamado sempre que o sistema Android entra ou sai do modo de RV. Isso geralmente ocorre quando o usuário muda para ou de um aplicativo de RV que está fazendo renderização estereoscópica.
Definição na linha
107
do arquivo
vr.h
.
A documentação desse struct foi gerada com base no seguinte arquivo:
-
hardware/libhardware/include/hardware/
vr.h
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-26 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-07-26 UTC."],[],[],null,["# Android Hardware Abstraction Layer: vr_module Struct Reference\n\nvr_module Struct Reference\n==========================\n\n[Data Fields](#pub-attribs) \nvr_module Struct Reference \n\n`\n#include \u003c\n`[vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)`\n\u003e\n`\n\n|----------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| Data Fields ----------- ||\n| struct [hw_module_t](/reference/hal/structhw__module__t) | [common](/reference/hal/structvr__module#a71ea01183b3998cad6a2301a37a42fc7) |\n| ||\n| void(\\* | [init](/reference/hal/structvr__module#a1621887a15b003a1ba7be81d52b0abb0) )(struct [vr_module](/reference/hal/structvr__module) \\*module) |\n| ||\n| void(\\* | [set_vr_mode](/reference/hal/structvr__module#a8c9e8990b6b65b068703cd615be68fb5) )(struct [vr_module](/reference/hal/structvr__module) \\*module, bool enabled) |\n| ||\n| void \\* | [reserved](/reference/hal/structvr__module#aa1a42885ba14c2168dc14d3f219b5e99) \\[8-2\\] |\n| ||\n\n\nDetailed Description\n--------------------\n\n\nImplement this HAL to receive callbacks when a virtual reality (VR) application is being used. VR applications characteristically have a number of special display and performance requirements, including:\n\n- Low sensor latency - Total end-to-end latency from the IMU, accelerometer, and gyro to an application-visible callback must be extremely low (\\\u003c5ms typically). This is required for HIFI sensor support.\n- Low display latency - Total end-to-end latency from the GPU draw calls to the actual display update must be as low as possible. This is achieved by using SurfaceFlinger in a single-buffered mode, and assuring that draw calls are synchronized with the display scanout correctly. This behavior is exposed via an EGL extension to applications. See below for the EGL extensions needed for this.\n- Low-persistence display - Display persistence settings must be set as low as possible while still maintaining a reasonable brightness. For a typical display running at 60Hz, pixels should be illuminated for \\\u003c=3.5ms to be considered low-persistence. This avoids ghosting during movements in a VR setting, and should be enabled from the [lights.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/lights.h) HAL when BRIGHTNESS_MODE_LOW_PERSISTENCE is set.\n- Consistent performance of the GPU and CPU - When given a mixed GPU/CPU workload for a VR application with bursts of work at regular intervals several times a frame, the CPU scheduling should ensure that the application render thread work is run consistently within 1ms of when scheduled, and completed before the end of the draw window. To this end, a single CPU core must be reserved for solely for the currently running VR application's render thread while in VR mode, and made available in the \"top-app\" cpuset. Likewise, an appropriate CPU, GPU, and bus clockrate must be maintained to ensure that the rendering workload finishes within the time allotted to render each frame when the POWER_HINT_SUSTAINED_PERFORMANCE flag has been set in the [power.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/power.h) HAL while in VR mode when the device is not being thermally throttled.\n- Required EGL extensions must be present - Any GPU settings required to allow the above capabilities are required, including the EGL extensions: EGL_ANDROID_create_native_client_buffer, EGL_ANDROID_front_buffer_auto_refresh, EGL_EXT_protected_content, EGL_KHR_mutable_render_buffer, EGL_KHR_reusable_sync, and EGL_KHR_wait_sync.\n- Accurate thermal reporting - Accurate thermal temperatures and limits must be reported in the [thermal.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/thermal.h) HAL. Specifically, the current skin temperature must accurately be reported for DEVICE_TEMPERATURE_SKIN and the vr_throttling_threshold reported for this device must accurately report the temperature limit above which the device's thermal governor throttles the CPU, GPU, and/or bus clockrates below the minimum necessary for consistent performance (see previous bullet point).\n\n\nIn general, vendors implementing this HAL are expected to use set_vr_mode as a hint to enable VR-specific performance tuning needed for any of the above requirements, and to turn on any device features optimal for VR display modes. The set_vr_mode call may simply do nothing if no optimizations are available or necessary to meet the above requirements.\n\n\nNo methods in this HAL will be called concurrently from the Android framework.\n\n\nDefinition at line\n[82](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\nof file\n[vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\n.\n\nField Documentation\n-------------------\n\n\n|-----------------------------------------------------------------|\n| struct [hw_module_t](/reference/hal/structhw__module__t) common |\n\n\nCommon methods of the module. This\n*must*\nbe the first member of\n[vr_module](/reference/hal/structvr__module)\nas users of this structure may cast a\n[hw_module_t](/reference/hal/structhw__module__t)\nto a\n[vr_module](/reference/hal/structvr__module)\npointer in contexts where it's known that the\n[hw_module_t](/reference/hal/structhw__module__t)\nreferences a\n[vr_module](/reference/hal/structvr__module)\n.\n\n\nDefinition at line\n[89](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\nof file\n[vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\n.\n\n|-----------------------------------------------------------------------------|\n| void(\\* init)(struct [vr_module](/reference/hal/structvr__module) \\*module) |\n\n\nConvenience method for the HAL implementation to set up any state needed at runtime startup. This is called once from the VrManagerService during its boot phase. No methods from this HAL will be called before init.\n\n\nDefinition at line\n[96](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\nof file\n[vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\n.\n\n|------------------------|\n| void\\* reserved\\[8-2\\] |\n\n\nDefinition at line\n[110](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\nof file\n[vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\n.\n\n|--------------------------------------------------------------------------------------------------|\n| void(\\* set_vr_mode)(struct [vr_module](/reference/hal/structvr__module) \\*module, bool enabled) |\n\n\nSet the VR mode state. Possible states of the enabled parameter are: false - VR mode is disabled, turn off all VR-specific settings. true - VR mode is enabled, turn on all VR-specific settings.\n\n\nThis is called whenever the the Android system enters or leaves VR mode. This will typically occur when the user switches to or from a VR application that is doing stereoscopic rendering.\n\n\nDefinition at line\n[107](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\nof file\n[vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)\n.\n\n*** ** * ** ***\n\nThe documentation for this struct was generated from the following file:\n\n- hardware/libhardware/include/hardware/ [vr.h](https://android.googlesource.com/platform/hardware/libhardware/+/master/include/hardware/vr.h)"]]