A real phone on a shelf is not automatically a motion-testing rig. Our view: sensor testing begins with the stimulus you must create and the response you must measure. The word “physical” tells you little about whether a remote operator can perform that experiment.
Android devices can have different sensor configurations, and apps can discover available sensors through Android's sensor APIs. The Android sensors overview documentation explains that manufacturers do not have to include every sensor type. Verify the actual device instead of assuming that every Android handset has the component your test needs.
Separate logic from measurement
Android's emulator can simulate conditions including rotation, location, and several sensor inputs, as described in Run apps on the Android Emulator. Controlled inputs are useful for asking whether software responds as intended to a known condition. A simulated response is evidence about that configured test, not a measurement of a handset's real-world sensor accuracy.
| Question | Suitable test requirement |
|---|---|
| Does the app handle a known input? | A controllable input and a defined expected response |
| Does the app handle a missing sensor? | A fixture or configuration that exercises absence |
| What does this handset measure? | The actual sensor, a controlled physical stimulus, and a reference |
| Can a remote operator perform the test? | A supported way to apply the stimulus and collect evidence |
The table is our proposed test-planning framework. A screenshot may show that an app displays a value, but an accuracy claim needs a reference and known conditions. Define the allowed measurement error and procedure before comparing a displayed value with an expectation.
Ask who can move the phone
For a test involving motion, light, proximity, or another physical stimulus, identify who or what can produce that stimulus at the device. Record the mounting, surrounding conditions, and repeat procedure where they matter. A remote session is useful only if the necessary input and evidence are available.
In a hypothetical compass-app test, a phone remains fixed beside unknown equipment while an operator watches its display remotely. In this invented example, the operator cannot infer compass accuracy from the displayed direction alone. A controlled reference and a suitable physical procedure are still needed.
Android's Android sensors overview documentation describes sensor attributes such as vendor, resolution, and maximum range, as well as timestamped events. For a development test, record the relevant reported attributes and observed data through an authorized instrumentation path. A requested sample rate should not be treated as proof of the actual delivery rate.
Keep the remote-product claim narrow
HiveReach's HiveReach product guide describes manual screen and pointer control of a supported Android phone. It does not establish a facility for physically moving that phone, changing its lighting, injecting sensor values, or exposing sensor logs. Confirm a supported procedure before assigning a sensor experiment to the service.
For an agency or independent developer, our recommendation is to divide sensor work into software behavior checks and physical measurement checks, then obtain the environment each needs. Report exactly which class of test was completed. “We saw the screen” and “we validated the sensor” should never be interchangeable in a release note.