Architecture rule
Use wedge for controlled form-entry workflows where focus behavior is acceptable. Use intents when structured scan delivery is available and scanner configuration can remain external. Use the SDK when the app must own trigger sessions, symbologies, output mode or detailed scanner state. Validate the exact device and firmware.
Keyboard wedge: low code, hidden state
Wedge mode injects characters into the focused control and can work with web or legacy apps. It is portable at the input level but depends on focus, keyboard layout, IME, prefix, suffix and timing.
Prevent scans from entering search, notes or authentication fields. Define whether Enter or Tab is appended and test long codes, rapid scans and manual typing.
- Explicit scan-ready field state
- Prefix and suffix documented
- IME and keyboard layout fixed
- Duplicate-submit protection
Broadcast intent: structured delivery with Android lifecycle rules
Intent output separates scan data from text focus. The receiver can inspect the action and extras, validate length and route the event to the active workflow.
Action names, extras and receiver requirements vary by vendor and SDK version. Register and unregister with the appropriate lifecycle, restrict exposure where possible and reject unexpected payloads.
- Exact action and extra keys
- Receiver export and permission review
- Foreground and background behavior
- Raw bytes versus decoded string
Vendor SDK: explicit control and explicit coupling
An SDK can open and close the scanner, select output mode, configure symbologies and start or stop decode sessions. This is appropriate when scan behavior is part of the application state machine.
Wrap vendor calls behind an application interface, record return values and make cleanup idempotent. Keep a device compatibility matrix because API availability does not guarantee identical engine or firmware behavior.
- Adapter around vendor API
- Open, start, stop and close ownership
- Configuration read-back where available
- Failure and timeout states visible
Validate data integrity and lifecycle
Test cold start, resume, screen lock, app switching, rotation if supported, reboot, MDM kiosk mode and rapid repeated triggers. Confirm that each physical scan creates one intended business event.
Use known byte sequences for non-ASCII and control characters. Decide whether the application stores raw bytes, decoded text, symbology and timestamp. Avoid logging sensitive scanned values.
- One scan equals one transaction
- No scan goes to the wrong screen
- Encoding and length verified
- Recovery needs no device reboot
Wedge vs intent vs SDK
Choose the minimum integration level that still provides the required control.
| Criterion | Keyboard wedge | Broadcast intent | Vendor SDK |
|---|---|---|---|
| Implementation effort | Low | Medium | Medium to high |
| Focus dependency | High | Low | Low |
| Scanner control | Mostly external configuration | External or limited | Application-owned |
| Data structure | Characters and suffix | Named extras | API event or broadcast |
| Portability | Input-level portability | Vendor action mapping | Vendor API adapter required |
Integration validation checklist
Record results by device, OS, firmware, SDK and application build.
- 01
Only the intended output mode is active
- 02
Focus and suffix behavior tested for wedge
- 03
Intent action and extras validated
- 04
Receiver lifecycle and exposure reviewed
- 05
SDK open and close return values handled
- 06
Rapid trigger and duplicate events tested
- 07
Sleep, resume, reboot and app switching tested
- 08
Encoding and long payloads verified
- 09
Restricted data excluded from logs
- 10
Rollback and configuration reset documented
Frequently asked questions
Is keyboard wedge reliable enough for production?
It can be when the workflow tightly controls focus, keyboard configuration, suffix and duplicate submission. Validate every screen that can receive input.
Are Android scanner intents standardized?
No. Broadcast action names, extras, configuration and permissions can differ by device vendor and SDK version.
Should an app always use the vendor SDK?
No. Use it when the application needs scanner control or state that wedge and configured intents cannot provide. The SDK adds lifecycle and compatibility work.
Evidence and limitations
Engineering architecture guidance / exact behavior requires device validation
Android platform principles are combined with UROVO SDK evidence; no cross-vendor API equivalence is claimed.
Reviewed: 2026-08-10
- Android developer documentation: input events and broadcast receivers
- RuggedLayer approved UROVO Android SDK v4.1.0326 API reference
