我正在实现一个Android ODM系统。我想创建一个围绕ImageReader构建的VirtualDisplay，以便提供虚拟显示的进程将接收来自SurfaceFlinger的一系列帧作为HardwareBuffer实例。
目的是通过使用 AHardwareBuffer_fromHardwareBuffer(( 获取相应的本机对象，将 Linux dmabuf 句柄提取到每个收到的 HardwareBuffer，然后使用 eglCreateNativeClientBufferANDROID(( 将其转换为 EGLImage，最后使用 eglExportDMABUFImageMESA(( 获取 dmabuf 文件描述符。
API 的关键部分 - AHardwareBuffer_fromHardwareBuffer(( - 位于名为"libandroid"的本机库中。Google 文档(见 https://source.android.com/devices/architecture/images/vndk_design_android_o.pdf(明确指出禁止供应商程序在 libandroid 中使用 API。
这看起来很奇怪，因为 libandroid 已经在应用程序 NDK 中公开了。我认为这意味着libandroid已经要求所有未来Android版本中的向后可移植性。
是否有任何现有方法可以使我的供应商计划链接到此 API？如果没有，AHardwareBuffer_fromHardwareBuffer((是否可以像其他一些与AHardwareBuffer相关的本机C++API一样迁移到VNDK？
更新：
这是一个预安装的服务，需要(除了执行这些VirtualDisplay和ImageReader机制(与我的客户正在实现的自定义HAL(因此：不是实现标准Google HIDL接口之一的任何内容(进行一些交互。
我认为这使我们需要预安装到/vendor分区中，对吧？我不知道从技术上讲，这是否使我成为"VNDK进程"，但是每当我将"vendor：true"放入蓝图文件中时，对libandroid链接的限制就会开始。
这个预安装的服务位于 AOSP 树中，因为我想使用平台密钥对其进行签名，以便该服务可以在 AndroidManifest 中设置其 android：persistent 属性.xml以避免它受到 ActivityManager 的任意关闭。
如果此VirtualDisplay没有结束实例化，其他预安装的应用程序将运行不良。我不确定这对GSI意味着什么。也许您可能会说，安装了GSI映像进行测试后，其他预安装的应用程序也不存在，因此没有问题。
此过程是否是恰好预装在设备上的常规应用程序(提供活动、服务等的 APK(？我想如果你使用的是VirtualDisplay和ImageReader。如果是这样，使用 libandroid 应该没有问题。
对libandroid的限制专门针对VNDK进程，即系统的较低级别部分。存在限制是因为libandroid中的一些东西依赖于Android Framework，ART运行时等，以及它们的未版本控制和非固定的内部接口。因此，VNDK 可用库的通常版本控制，其中来自旧版本操作系统的 vndk 二进制文件必须在较新版本的操作系统上运行，不适用于 libandroid，因为这些依赖于不稳定的内部接口。
但是，如果您正在编写位于框架之上并且仅使用公共 API 的内容，那么它不是 VNDK 进程，并且这些限制不适用。
(注意：我在Android上工作，并参与了AHardwareBuffer API。但我不是VNDK专家，也不是供应商流程和供应商预安装应用程序规则的专家。因此，请认为这反映了我个人的理解，而不是Android团队的官方声明：如果有官方文档与我所说的相矛盾，那可能是对的，我是错的。