Suggestion: Is a REST API planned?

[TakahiroMiyaura]

Hi, Team.

Foundry Local, which has entered General Availability (GA), supports a REST API.
Is this not available for the Android version?

Reason for the request:
There are various approaches to Android development, and it is not limited to Java or Kotlin. I believe that a REST API would expand the range of integration options when actually embedding Foundry Local into an app, significantly enhancing the product’s value.

I am currently exploring ways to utilize Foundry Local on devices such as AI Glass(ex: Even G2,GUIDE01). Some of these new devices allow for the implementation of plugins using Node.js or Python on companion smartphone apps. With a REST API, it might be possible to call Foundry Local. We would very much like to try this out.

Regards,
Takahiro

[EmmaNingMS]

Could you help elaborate the workflow you expect for our evaluation?

You could use the FL GA version for getting REST API. Foundry Local Android works conceptually similar to a REST API, but it exposes a native AIDL bound service that Android applications can bind to directly, enabling more efficient on-device communication on Android. Compared with a REST API, an AIDL bound service is usually a better fit for on-device Android-to-Android communication because it avoids the HTTP stack, JSON serialization, and network transport overhead.

[TakahiroMiyaura]

Thank you for your reply.

I'm conducting this as an experiment rather than developing a specific product. Since this is a somewhat unique use case, I hope our findings will be useful as a reference for your project.

Based on the news that an Android version of FL is available, I am planning to test a workflow focused on the following two points:

1. Running as a local LLM on Android-based XR devices: I envision embedding the LLM within a native XR application to handle lightweight tasks offline. For this, we plan to experiment using the existing .aar file.
2. Integrating with AR/AI glasses via an Android host app: The target device is the Even Realities G2 AI glasses. In this setup, information is retrieved by a linked smartphone app and displayed on the glasses' lenses.

The reason for my initial question pertains to Point 2. While the G2 allows for custom features, they must be implemented as plugins for the dedicated host app. These plugins are written in TypeScript/JavaScript, making it difficult to interface directly with native libraries.
I also regularly use the REST API in the PC version of Foundry Local. Therefore, I am interested in whether the REST API will be available for the Android version as well. If so, I believe it would enable me to verify Point 2 for this Android/smart glasses integration.

[CheCheTortas]

Hi Miyaura (@TakahiroMiyaura) and team,

Thanks for providing such detailed context about your use case! Integrating with the Even Realities G2 AI glasses and dealing with the constraints of TypeScript/JS-based host app plugins changes the picture completely.

While Emma Ning (@EmmaNingMS) is absolutely right regarding the raw performance and low overhead of IPC via AIDL (avoiding network stacks and JSON serialization overhead locally), we completely understand the DX (Developer Experience) and integration hurdles when dealing with web-view or JS-hybrid environments that cannot easily bind to a native Android Service.

To balance platform performance with high extensibility, we are evaluating the following architectural paths:

1. The Local Sidecar Proxy Approach (Embedded HTTP Server)

Instead of replacing the core AIDL architecture, we could expose an optional, lightweight embedded HTTP server (e.g., using Ktor or a micro-Netty implementation) running inside a Foreground Service.

• How it works: It would listen locally on localhost:PORT. Your TypeScript environment can perform standard REST fetches to it. The sidecar proxy handles the HTTP request, communicates internally with Foundry via AIDL on the native side, and returns the JSON payload back to your plugin.
• Pros: Full REST API compatibility for web/hybrid environments without degrading the native AIDL performance path for core Android clients.

2. Native Wrapper Scaffolding (Paved Path)

If resource constraints prevent us from running an internal loopback server, we could provide a standardized reference wrapper (a native Android library/bridge scaffold) that handles the AIDL binding. Developers using hybrid frameworks (React Native/Node-based host apps) could implement this bridge into their native application layer to communicate directly with our service.

Next Steps:

We want to enable these emerging XR/Smart Glasses scenarios efficiently. We are currently auditing the footprint of introducing a local loopback server option.

We will keep this issue open while we formalize the roadmap decision for this feature. Any additional constraints regarding your TS environment’s networking capabilities are highly welcome!

Best,
CheChe
🤘🏻😎
I apologize for not communicating until now, but I had to rise from the ashes.