Developer Hub / Hardware key mapping

Hardware key mapping

Inspect a physical key, preserve the original mapping and provide a reliable restore path before changing behavior.

Publishing standardDevelopers

Connect and validate your application on target hardware.

A reversible key customization that cannot silently strand the operator or block required system behavior.

Teams customizing scan triggers, action keys or workflow shortcuts on managed handhelds.

Technical content is the core of RuggedLayer. Public resources show reproducible device-interface patterns and the evidence needed to move an existing app toward deployment, while restricted manufacturer SDKs remain behind approved distribution channels.

Comparable device evidence with method, version and limitations.

Developer resourcesHardware key mapping
RuggedLayer Test LabIntermediate
Technical guides, SDK notes, sample apps and compatibility data for connecting existing enterprise applications to rugged Android devices.Teams customizing scan triggers, action keys or workflow shortcuts on managed handhelds.
  • A physical device with a documented target key and an approved deployment policy.
  • A recovery path that does not depend on the remapped key.
  • An explicit decision about whether the change is app-level or device-level.

Publishing standard

Build and validate enterprise Android integrations with versioned evidence.

Technical content is the core of RuggedLayer. Public resources show reproducible device-interface patterns and the evidence needed to move an existing app toward deployment, while restricted manufacturer SDKs remain behind approved distribution channels.

  1. 01

    Decide the smallest control surface

    Use application-level key handling when the workflow can stay inside the app. Use device-level mapping only when the deployment policy and model support it.

  2. 02

    Snapshot before changing

    Read and store the original key code, action and interception state in a controlled deployment record. Never assume the factory mapping is identical across variants.

  3. 03

    Map one key at a time

    Apply one reversible change, verify it in the target workflow and keep navigation, emergency, payment and system keys outside the demo.

  4. 04

    Restore and reboot

    Verify restore, reboot persistence, factory reset behavior and a physical recovery procedure. A successful remap without recovery is not deployment-ready.

Sample apps / Kotlin

SDK and API patterns

The public example models safe state transitions; actual device-level mapping remains model- and policy-specific.

key-restore-plan.kt

data class KeySnapshot(
  val keyCode: Int,
  val action: String?,
  val intercepted: Boolean,
)

interface KeyPort {
  fun snapshot(keyCode: Int): KeySnapshot
  fun apply(keyCode: Int, action: String)
  fun restore(snapshot: KeySnapshot)
}

fun applyTemporaryMapping(port: KeyPort, keyCode: Int, action: String) {
  val original = port.snapshot(keyCode)
  try {
    port.apply(keyCode, action)
    // Verify the workflow here before the device leaves the lab.
  } catch (error: Throwable) {
    port.restore(original)
    throw error
  }
}
No vendor binary, API reference, firmware or source sample is published until its redistribution permission and supported scope are recorded.

SDK distribution

Publication gate

No vendor binary, API reference, firmware or source sample is published until its redistribution permission and supported scope are recorded.

The key has no known entry

Stop and record the model-specific limitation; do not write a guessed mapping.

The app loses navigation input

Use the physical recovery path, restore the snapshot and remove the mapping from deployment.

Mapping disappears after reboot

Mark it session-only and move persistence into the deployment configuration if approved.

How to read the references

Comparable device evidence with method, version and limitations.

  1. 01

    Record the original mapping and test a restore before applying the change.

  2. 02

    Verify the action in foreground, background, reboot and reset scenarios.

  3. 03

    Confirm system navigation and emergency behavior remain available.

  4. 04

    Keep a recovery instruction beside the device during the test.

Connect and validate your application on target hardware. Add the key policy and recovery procedure to the deployment checklist.

Resources

SDK and API patterns

No vendor binary, API reference, firmware or source sample is published until its redistribution permission and supported scope are recorded.

Connect and validate your application on target hardware.

Share the non-confidential app workflow, current device and integration path; we will scope the closest validation deliverable.

Connect and validate my application