Device Controls

Interpret controls and device readings

An interface can save a preference without enforcing it. EdgeORE's control-effect labels distinguish Enforced, Saved only and Unavailable. This is essential for battery, thermal, CPU and contribution settings because a polished slider otherwise suggests it is already controlling a workload. The website should describe each control's real enforcement path and avoid converting a persisted value into a resource-sharing capability.

Read the label before the value

An enforced daily transfer budget applies at the reviewed transfer gate. A saved CPU preference may not limit another process's work until a suitable runtime uses it. An unavailable thermal reading should fail the relevant policy closed rather than be displayed as a safe zero. A charging-only setting can be meaningful only where the actual operation checks that state. Explain the bounded action controlled by each setting.

Minimum Android support and individual APIs also differ. Thermal status is unavailable on older platforms that lack the required API. Emulators may provide limited or synthetic readings. A missing sensor value is not a normal reading. The UI should distinguish measured, stale, unavailable and illustrative states so an evaluator understands what it can infer.

Test policy transitions

Start from a known reading and change a setting that the implementation actually enforces. Observe the blocked or allowed action and preserve the control label. Test missing readings and confirm fail-closed behavior where specified. Then restart the app and verify saved preferences remain saved without claiming this proves enforcement. Persistence and policy application are separate acceptance tests.

A pause button should describe which work it pauses. In the recorded candidate, there is no qualified earning workload or mining loop. Showing Active because a timer advances would be misleading. If a future owned-host job runs independently, pausing the phone UI may not stop the host; the protocol needs an acknowledged cancellation action and its own timeout semantics.

Avoid misleading telemetry

Disk, battery, thermal and CPU observations are useful operational context. They do not measure accepted training data, storage delivery or paid bandwidth. Any future contribution metric needs a job ID, measurement interval, verification rule and source. A graph of load can look persuasive while proving nothing about customer value. Keep product language precise enough that the user knows what was measured.

Accessibility also matters here. Controls should have readable labels, touch targets, keyboard or screen-reader semantics where appropriate and explicit disabled reasons. Color alone should not distinguish enforced from unavailable. A safe control cannot require the user to infer meaning from mint versus copper. Text and state must remain visible on a small screen.

Establish a control matrix

For each switch or slider, record its persistence path, enforcement path, required readings and unavailable behavior. Compare the matrix with the centralized control-effect definitions and tests. A website example should say Sample data and should not claim a device setting changed through the browser. This matrix is a practical bridge from UI design to reliable implementation and should be reviewed whenever a new workload adapter is added.

---

Wiki home · Qualification updates · Sources and credits