gRPC Server on android

185 views
Skip to first unread message

Dolanor Maergal

unread,
Mar 24, 2025, 10:50:46 AMMar 24
to grpc.io
Hi,

I'd like to run a gRPC server on android to access some part of the Android API from another stack (not java or kotlin). Potentially, that server should be able to run some intent and get their result.
Has anyone done that?

before
App -> (JNI using android NDK) -> Android SDK

after
App -> (gRPC client request) -> gRPC Server (in Java) -> Android SDK

Why?
JNI + NDK is cumbersome, error prone and hard to debug. Having a simple Request/Response from the App gRPC client would be an improvement in DX.

In my use case, latency is not that big a problem. But if somebody already did something like that and had bad experience, I'm all ears.

Vissa Janardhan Krishna Sai (xWF)

unread,
Mar 26, 2025, 9:46:42 AMMar 26
to grpc.io
Hi, 

You can run a gRPC server inside an Android app, exposing APIs like launching intents, accessing system services, or interacting with the Android framework. This allows any gRPC-capable client (Python, C++, Rust, etc.) to call the Android system without using JNI.

How It Works
  1. Set up a gRPC server in Java/Kotlin inside an Android Service.

  2. Expose Android API functionality via gRPC endpoints.

  3. Handle incoming gRPC requests and return results.

  4. Run the gRPC server as a Foreground Service to ensure it stays alive.

  5. Connect from an external app or another stack via a gRPC client.


Eric Anderson

unread,
Apr 2, 2025, 6:31:48 PMApr 2
to Dolanor Maergal, grpc.io
For just message-passing, I think it'd work basically as expected.

The only concern I'd have is if you ever need to retain specialized Android objects across RPCs. Many Android objects are special and are only serializable over Binder. gRPC Java does have Binder support, which allows passing these between processes. While gRPC C Core used to have Binder support, it was removed due to lack of maintainers and usage. So there's not an implementation to transfer these to non-Java.

If you end up having to deal with those specialized objects, you'll need the Java process to hang on to them for the non-Java process or design the RPCs such that the object doesn't need to persist across RPCs.

--
You received this message because you are subscribed to the Google Groups "grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/grpc-io/3be965f4-ac62-42f5-8877-9158923d105cn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages