3 ms·

Another opportunity wasted to create a unified Android driver model that would allow easy upgrades.

by dep_b 10y ago

sigmar 10y ago
The Android driver model is not what holds back updates. Time and monetary cost of OEM customizations, subsequent carrier bloat, and testing (all performed in series) are what hold back upgrades.
- npelly 10y ago
  Agree. Driver abstraction layers are not a cure-all. First, OEMs want to customize the O/S above the driver level. Second, a strict DAL with a canonical O/S on top slows hardware innovation. All devices end up functionally the same because they have to fit the same DAL, and they can't customize the O/S to take advantage of new HW. Take Android Wear. It took the DAL approach. As a result, O/S upgrades are immediately available to all devices (awesome!). But there is very little differentiation - all Wear devices use the same small set of SoC's and peripherals, and are functionally the same. Google decides on HW innovations. (This was true of Wear 1.0, not sure if changed with Wear 2.0)
EddieRingle 10y ago
I was curious so I took a look: It seems they're implementing a new system; there are shared libraries in /vendor/lib/hw on my Pixel running O that aren't there on my Pixel XL running 7.1. sailfish:/ $ ls /vendor/lib/hw android.hardware.audio.effect@2.0-impl.so android.hardware.graphics.composer@2.1-impl.so android.hardware.vibrator@1.0-impl.so android.hardware.audio@2.0-impl.so android.hardware.graphics.mapper@2.0-impl.so android.hardware.vr@1.0-impl.so android.hardware.boot@1.0-impl.so android.hardware.keymaster@3.0-impl.so flp.default.so android.hardware.camera.provider@2.4-impl.so android.hardware.light@2.0-impl.so gatekeeper.msm8996.so android.hardware.configstore@1.0-impl.so android.hardware.memtrack@1.0-impl.so keystore.msm8996.so android.hardware.contexthub@1.0-impl.so android.hardware.nfc@1.0-impl.so sensors.vl530l0.tof.so android.hardware.drm@1.0-impl.so android.hardware.power@1.0-impl.so sound_trigger.primary.msm8996.so android.hardware.gatekeeper@1.0-impl.so android.hardware.sensors@1.0-impl.so vulkan.msm8996.so android.hardware.gnss@1.0-impl.so android.hardware.soundtrigger@2.0-impl.so android.hardware.graphics.allocator@2.0-impl.so android.hardware.thermal@1.0-impl.so You can see some development in the AOSP repos (follow https://r.android.com https://r.android.com) that supports this. For example, libhwbinder (https://android.googlesource.com/platform/system/libhwbinder/+/master https://android.googlesource.com/platform/system/libhwbinder...) looks to be an interface for talking with a /dev/hwbinder device, and the kernel seems to have been updated recently to support multiple Binder device instances. HAL interfaces are defined in HIDL, which looks to be implemented here: https://android.googlesource.com/platform/system/libhidl/+/master https://android.googlesource.com/platform/system/libhidl/+/m... (along with a separate hidl tool in another repo).

Another opportunity wasted to create a unified Android driver model that would allow easy upgrades.

by dep_b 10y ago

Another opportunity wasted to create a unified Android driver model that would allow easy upgrades.

The Android driver model is not what holds back updates. Time and monetary cost of OEM customizations, subsequent carrier bloat, and testing (all performed in series) are what hold back upgrades.

npelly 10y ago
Agree. Driver abstraction layers are not a cure-all. First, OEMs want to customize the O/S above the driver level. Second, a strict DAL with a canonical O/S on top slows hardware innovation. All devices end up functionally the same because they have to fit the same DAL, and they can't customize the O/S to take advantage of new HW. Take Android Wear. It took the DAL approach. As a result, O/S upgrades are immediately available to all devices (awesome!). But there is very little differentiation - all Wear devices use the same small set of SoC's and peripherals, and are functionally the same. Google decides on HW innovations. (This was true of Wear 1.0, not sure if changed with Wear 2.0)

EddieRingle 10y ago

I was curious so I took a look: It seems they're implementing a new system; there are shared libraries in /vendor/lib/hw on my Pixel running O that aren't there on my Pixel XL running 7.1. sailfish:/ $ ls /vendor/lib/hw android.hardware.audio.effect@2.0-impl.so android.hardware.graphics.composer@2.1-impl.so android.hardware.vibrator@1.0-impl.so android.hardware.audio@2.0-impl.so android.hardware.graphics.mapper@2.0-impl.so android.hardware.vr@1.0-impl.so android.hardware.boot@1.0-impl.so android.hardware.keymaster@3.0-impl.so flp.default.so android.hardware.camera.provider@2.4-impl.so android.hardware.light@2.0-impl.so gatekeeper.msm8996.so android.hardware.configstore@1.0-impl.so android.hardware.memtrack@1.0-impl.so keystore.msm8996.so android.hardware.contexthub@1.0-impl.so android.hardware.nfc@1.0-impl.so sensors.vl530l0.tof.so android.hardware.drm@1.0-impl.so android.hardware.power@1.0-impl.so sound_trigger.primary.msm8996.so android.hardware.gatekeeper@1.0-impl.so android.hardware.sensors@1.0-impl.so vulkan.msm8996.so android.hardware.gnss@1.0-impl.so android.hardware.soundtrigger@2.0-impl.so android.hardware.graphics.allocator@2.0-impl.so android.hardware.thermal@1.0-impl.so You can see some development in the AOSP repos (follow https://r.android.com https://r.android.com) that supports this. For example, libhwbinder (https://android.googlesource.com/platform/system/libhwbinder/+/master https://android.googlesource.com/platform/system/libhwbinder...) looks to be an interface for talking with a /dev/hwbinder device, and the kernel seems to have been updated recently to support multiple Binder device instances. HAL interfaces are defined in HIDL, which looks to be implemented here: https://android.googlesource.com/platform/system/libhidl/+/master https://android.googlesource.com/platform/system/libhidl/+/m... (along with a separate hidl tool in another repo).