Aiden Unifies Device Input Across HID, ADB, and HTTP Providers

Major Update: Aiden has unified its input layer so you can keep one set of action semantics for common device interactions while the device type you configure selects the corresponding behavior. This firmware progress brings a clearer approach to cross-platform device input for mobile, desktop, and device-automation development: describe familiar actions consistently, then direct them through the configured HID, ADB, or HTTP path.

How cross-platform device input preserves shared action semantics

Aiden now abstracts device interaction through an MNK Provider. The provider supplies a shared model for input while retaining three distinct configured input paths: HID, ADB, and HTTP.

That separation is important. HID, ADB, and HTTP are not combined into one transport, and Aiden does not treat their underlying behavior as interchangeable. Instead, the MNK Provider gives the firmware a consistent way to represent common input operations across those configured paths.

For you, the immediate benefit is less friction when describing actions. After you set a device type, the same tool semantics can represent clicks, swipes, keyboard shortcuts, and text input. The configured device type then selects the corresponding behavior for the path in use.

This lets your action vocabulary remain stable as your work moves between supported configurations. A click still represents a click, a swipe still represents a swipe, and text entry remains text entry, even when the configured path changes.

Cross-platform device input unifies the details behind each action

The update extends beyond naming common actions. Aiden now unifies the information needed to make those actions meaningful:

• Keyboard layouts for keyboard-oriented input.
• Touch gestures for gesture-oriented interaction.
• Coordinates for position-based actions.
• Structured errors for consistent failure reporting.

The unified model does not erase the differences between the paths. It provides a common semantic layer above them. You can express an action in familiar terms while the selected device type determines how that action is handled.

This is especially useful for HID and ADB automation work, where the same high-level operation may need different path-specific behavior. Rather than redefining the intent of the operation each time, you can retain the intended action and rely on the configuration to select the applicable behavior.

Device type configuration remains an explicit choice

Aiden does not automatically identify or recognize the target platform. You set the device type yourself, and that choice remains required because it determines the configured input path and the behavior used for an action.

This distinction keeps the model precise. The MNK Provider offers a shared structure for common device input operations, but it does not replace configuration with target detection. You choose the device type; Aiden applies the behavior associated with that configuration.

For developers maintaining automation across mobile and desktop contexts, that means fewer changes to the way actions are expressed while preserving the reality that different input paths have different implementations. The result is a more coherent firmware layer without implying broad compatibility claims or a single all-purpose connection method.

Aiden firmware changes behind the unified layer

This input-layer progress was merged through PR #539, PR #543, PR #556, and PR #560.

Together, these changes establish the current direction for the Aiden firmware and its MNK Provider: shared semantics for common input actions, with HID, ADB, and HTTP maintained as separate configured paths. That is a practical foundation for developers who need consistent action definitions without losing the configuration choices that make each path meaningful.

Follow the Aiden firmware repository and join the Aiden Discord community.