[phh]

I disagree. Apps barely use Binder directly, but mostly call framework jar (which yes will do binder, but since they are reimplementing framework jar that's fine). Intents and permissions can be implemented without binder as the API is quite semantic. It may happen that the app uses Binder for same-app IPC, but since app does ser-des itself, you can easily replace Android.os.binder by whatever IPC you want, The only "real" issue I can see , and you're right there, is Play Services. I think that handling that case specifically later (once floss apps/apps that don't require play services work properly), is not too horrific (it basically needs to compile the aidl into not calling binder, but redirecting it to a custom lib)

[sigh_again]

So, as I said, hacks on top of hacks on top of hacks :D If you're going to shim and reimplement, piece by piece some APIs like Binder... Just use Binder, that is already upstreamed in the kernel for so long.

[phh]

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?)

[kllrnohj]

> 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.