0

I am implementing an Android ODM system. I would like to create a VirtualDisplay constructed around an ImageReader so that the process providing the virtual display will receive the series of frames coming out of SurfaceFlinger as HardwareBuffer instances.

The intention is to fetch out the Linux dmabuf handle to each received HardwareBuffer by using AHardwareBuffer_fromHardwareBuffer() to get the corresponding native object, then convert it to an EGLImage with eglCreateNativeClientBufferANDROID() and then finally use eglExportDMABUFImageMESA() to obtain the dmabuf filedescriptor.

The critical piece of API -- AHardwareBuffer_fromHardwareBuffer() -- lives in the native library called "libandroid". Google documentation (see https://source.android.com/devices/architecture/images/vndk_design_android_o.pdf) explicitly indicates that vendor programs are prohibited from using API in libandroid.

This seems strange, because libandroid is already exposed in the application NDK. I think this means that backward portability in all future Android releases is therefore already demanded of libandroid.

Is there any existing way that I can make my vendor program link against this API? If not, could AHardwareBuffer_fromHardwareBuffer() be migrated out to the VNDK in a similar way as some of the other native C++ API's related to AHardwareBuffer have been?

Updated:

It's a pre-installed service that needs (in addition to doing these VirtualDisplay and ImageReader mechanics) to do some interaction with a custom HAL (so: not anything that implements one of the standard Google HIDL interfaces) that my customer is implementing.

I think that relegates us to needing to pre-install into the /vendor partition, right? I don't know whether this technically speaking makes me a "VNDK process", but the restriction against linking against libandroid kicks in anytime that I put "vendor: true" into the Blueprint file.

This pre-installed service sits in the AOSP tree because I'd like to sign it with the platform key so that the service can set its android:persistent property in AndroidManifest.xml to avoid it being subject to arbitrary shutdown from ActivityManager.

Other pre-installed applications will go badly if this VirtualDisplay doesn't end get instantiated. I'm uncertain what this means for GSI. Maybe you're likely to say that, with a GSI image installed for testing, none of those other preinstalled apps are present either so there's no problem.

Matt Hoosier
  • 1
  • 1

1 Answers1

1

Is this process a regular application (APK that provides Activities, Services, etc.) that just happens to be pre-installed on the device? I'd imagine it is if you're using VirtualDisplay and ImageReader. If so, there should be no problem using libandroid.

The restriction on libandroid is specifically for VNDK processes, i.e. lower level parts of the system. The restriction is there because several things in libandroid depend on the Android Framework, ART runtime, etc. as well as unversioned and non-fixed internal interfaces to them. So the usual versioning of VNDK-available libraries, where literally vndk binaries from old versions of the OS must work on newer versions of the OS, doesn't work for libandroid because of those dependencies on non-stable internal interfaces.

But if you're writing something that sits above the framework and is only using public APIs, then it's not a VNDK process and those restrictions don't apply.

(Note: I work on Android and have been involved in AHardwareBuffer APIs. But I'm not a VNDK expert nor an expert on the rules around vendor processes and vendor-preinstalled applications. So take this as reflecting my own personal understanding, and not an official statement from the Android team: if there's official documentation that contradicts what I've said, it's probably right and I'm wrong.)

Jesse Hall
  • 6,441
  • 23
  • 29
  • Thanks for the reply. See the updated description in the question for answers to your questions. – Matt Hoosier Aug 09 '19 at 15:36
  • Regarding the whole GSI thing: my product won't launch for another three years. My impression is that by that time, Google will have gotten around to directly pushing out updates to the system image. Is it wise to be putting any product-dependent code on /system? – Matt Hoosier Aug 09 '19 at 19:31
  • What about putting the logic in the /product partition: https://source.android.com/devices/bootloader/product-partitions – Alain Aug 09 '19 at 19:34
  • I see. We're far enough outside what I know well that I'm not able to answer the clarified question with much confidence. But using the product partition like Alain suggested seems pretty promising. – Jesse Hall Aug 10 '19 at 03:48
  • If the description that /product is forbidden by SELinux policy to interact with any Treble HALs is accurate, then that seems like a showstopper to me. – Matt Hoosier Aug 12 '19 at 14:03