Closed kholk closed 3 years ago
Unfortunately I'm lost for time (it's been freezing here for a week, we can ice-skate on "natural ice" since ~8 years??!?!) but this - as you rightfully closed - makes little sense.
It'd be fine if these libraries are merely required for fallbacks, like graphics where mapper@3.0
is probed and there is a fallback for mapper@2.0
(for which it obviously needs to dynamically link against that interface library) - even though none of our HALs (passthrough or binderized) host it.
However, as I understand from internal discussions the camera binaries literally try to probe interfaces like vendor.display.config@1.9
even though we're only hosting @2.0
. This simply means:
@1.x
, instead of just @2.0
:
pdx206:/ # lshal | grep displ
...
DM Y vendor.display.config@2.0::IDisplayConfig/default 0/4 775 608
...
pdx206:/ # ps -A 775
USER PID PPID VSZ RSS WCHAN ADDR S NAME
system 775 1 10951900 18824 binder_io+ 0 S vendor.qti.hardware.display.composer-service
That's the composer. It doesn't look like this is possible, check display-commonsys-intf
, services/config/src
. Not a single reference to 1.x
config.
@2.0
) matching closed-source tags should be available for this as well.
These interfaces are required by various (many!) components.