Skip to content

binder: BinderChannelBuilder should not force clients to hard code an android.app.Service class name #9062

@jdcormie

Description

@jdcormie

Is your feature request related to a problem?

BinderChannelBuilder requires an AndroidComponentAddress and an AndroidComponentAddress requires a ComponentName (the package name and class name of the target android.app.Service). This forces clients to hard code the server's class name.

Because client and server APKs can't be upgraded atomically, servers with external clients must keep the same service name forever, to accommodate old clients. If two gRPC services are hosted in the same android.app.Service, they must be hosted in the same android:process forever.

Describe the solution you'd like

Android naturally supports a layer of indirection using https://developer.android.com/guide/components/intents-filters. Since SDK 21, bindService() Intents must be explicit but this doesn't require specifying the full ComponentName. An Intent that specifies a setPackage() filter is also considered explicit. Clients of a gRPC service/interface named com.foo.ISomething might do something like:

BinderChannelBuilder.forTarget("intent://#Intent;action=com.foo.ISomething;pkg=com.foo;end", ...)
  ...
  .build();

Servers could keep their Service class names private and use to map to Services in the AndroidManifest.xml instead:

<service name="com.server.app.Service1" process=":p1">
  <intent-filter>
    <action name="com.foo.ISomething"/>
  </intent-filter>
</service>

Several Google apps, including photos, already uses this technique for their AIDL services.

Describe alternatives you've considered

Could use a NameResolverProvider that calls PackageManager#resolveService(), but that costs one extra IPC round trip to the system server before calling bindService(). Any cached addresses could also get out of sync with reality when the target's package is upgraded.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions