Hacker News Reader

Comment by dep_b | Hacker News Reader

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.

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)

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) that supports this. For example, libhwbinder (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/+/m... (along with a separate hidl tool in another repo).

Reply on news.ycombinator.com