[Feature Request]: Do not remove AIDL API or proposal to refactor API for external APPs

[adelobosko]

Checklist

• I have used the search function for OPEN ISSUES to see if someone else has already submitted the same feature request.

• I have also used the search function for CLOSED ISSUES to see if the feature was already implemented and is just waiting to be released, or if the feature was rejected.

• I will describe the request with as much detail as possible.

• This request contains only one single feature, not a list of multiple (related) features.

• I have read and understood the Contribution Guidelines.

• I agree to follow this project's Code of Conduct

Contact Details

No response

Feature or improvement you want

I want to keep using API (current AIDL / refactored AIDL / any other API):

• received message listener;
• send message;
• nodes postition change listener (with additional data: position timestamp, satellites, seqnumber, etc.)
• get the current version of the API;
• get current node connection state to the node;
• get connected node info;
• connect/disconnect listeners;

I propose refactoring the current AIDL API or creating a new one with the following principles (if the current one will be removed):

• The API should not depend on internal app models or internal communication mechanisms. API models should exist exclusively for the external API contract.
• The API version should be separated from the APP version, so external integrators only need to update when the API major version changes.
• This provides flexibility: the API major version can change independently when breaking changes are introduced, while APP major versions may change for unrelated reasons such as firmware compatibility updates, UI redesigns, or internal refactoring.
• App versions change frequently due to bug fixes, UI updates, firmware support changes, and other maintenance tasks. Separating APP and API versions prevents unnecessary contract updates for external applications.
• The API should remain as simple and primitive as possible.
• The API should not expose or depend on internal processes or internal data models.
• For example:
  • sendMessage(nodeId, messageText)
  • replyToMessage(messageId, messageText)
  • getNodeInfo(nodeId)
  • onNodePositionChanged(out nodeId, out newPositionInfo)
  • onMessageReceived(out nodeId, out messageInfo)

This minimizes the possibility of breaking changes because the internal application layer handles API requests and maps them to the current App-Device communication models internally.

Why should this be added?

Separating APP version and AIDL version solves several architectural and compatibility problems:

• Independent evolution
  The application can release new UI, features, or bug fixes without changing the IPC/API contract defined by AIDL.
• Backward/forward compatibility
  Different app versions can still communicate if they support the same AIDL version.
• Stable IPC contract
  AIDL acts as a stable interface layer between processes/modules/services, reducing breaking changes.
• Safer updates
  Prevents situations where updating the app accidentally breaks communication with older services or clients.
• Version negotiation support
  The system can explicitly check AIDL compatibility instead of relying on the app version.
• Reduced deployment coupling
  Services and clients may be updated independently as long as the AIDL contract remains compatible.
• Easier maintenance and debugging
  Problems can be identified as either:
  • application-level issues, or
  • interface/protocol compatibility issues.
• Support for multi-client ecosystems
  Multiple external clients/apps can interact with the same service using a common AIDL version, even if their APP versions differ.

The presence of an API for external apps to interact with the Meshtastic Android app solves several important problems:

• Integration limitations
  External applications can access Meshtastic functionality without reimplementing Bluetooth, radio communication, or mesh protocols.
• Code duplication
  Third-party developers reuse the existing Meshtastic infrastructure instead of building their own communication stack.
• Hardware access centralization
  Multiple apps can use the same connected Meshtastic device through a single Android app acting as a gateway.
• Reduced complexity for external developers
  Developers interact with a stable API instead of low-level device protocols.
• Protocol abstraction
  Changes in internal mesh protocols or device communication can be hidden behind the API layer.
• Faster ecosystem growth
  New tools, automation systems, maps, telemetry apps, and integrations can be built more easily.
• Security and permission control
  The Android app can centralize authentication, permissions, and connection management instead of exposing direct hardware access to every app.
• Background service reuse
  External apps can benefit from already-running mesh connections, synchronization, and device state maintained by the Meshtastic app.
• Improved maintainability
  API versioning allows controlled compatibility management between Meshtastic and third-party apps.
• Support for automation and specialized use cases
• Enables integrations with:
  • mapping systems,
  • emergency tools,
  • IoT automation,
  • telemetry dashboards,
  • offline communication apps.

Screenshots / Drawings / Technical details

[garthvh]

What app is using it? Are you volunteering to maintain it?

[adelobosko]

What app is using it? Are you volunteering to maintain it?

It's a bridge app between Meshtastic and OsmAnd, currently in a very raw state. I update it little by little when I have the desire and time. I would do another API because the current one makes breaking changes.