Comment by phh | Hacker News Reader

Comment by phh | Hacker News Reader

Parent Full thread

You're confusing shiming with rewriting.

DirectX uses direct hardware access. DirectX uses direct hardware access. That doesn't mean you can't rewrite a DirectX-API implementation without direct hardware access. Likewise, Android's original implementation of MediaCodec uses binder. That doesn't mean that a reimplementation of MediaCodec API requires binder. The vast majority of Android public APIs do not assume binder. The only exception is Service binding, and even then, it's an assumption in name: It assumes that android.os.Binder will provide you an IPC. Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC. Even the usage towards multiple app (whose only real usage would be Play Services) doesn't actually require binder. The requirement on that part is just the ""stable"" ser-des.

As an app developer, you (should) never connect directly to /dev/binder, because its API/ABI isn't stable. (it changed like 3 times in the last 6 years?)

> Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC.

I'd be absolutely shocked if that was even a little bit true. Android's binder & AIDL generated code will absolutely do in-process passthrough to avoid the syscall for local calls, but ~nobody is bothering with AIDL unless it's to enable IPC. So that local pass-through is almost certainly rarely if ever used except on "accident" when components nominally support being passed over IPC, but in some cases aren't. An example would be Android's Surface + SurfaceTexture. Normally you're using Surface over IPC either to the display or to media codec or from camera. But if you're using SurfaceTexture, then in that rare scenario it might be local to the process.

But that's definitely a lot less common than IPC binder + AIDL.

All that said, you could almost certainly make a Binder driver shim that just uses unix domain sockets. Heck, Android itself even has one: https://cs.android.com/android/platform/superproject/main/+/...

What'd be a lot harder is handling some of the more advanced graphics & multimedia features. Android's gralloc HAL in particular is likely borderline impossible to implement on Linux as it assumes tight integration between all of the camera, media/video, GPU, and display stacks, and also largely assumes it's on unified memory.

Reply on news.ycombinator.com