4.8.0.beta

All the changes made so far

This pre-release makes study participation more transparent and reliable: participants receive clearer consent and permission flows, can see whether sensors are actually collecting, and when a researcher permits edits they can maintain a device-specific configuration without silent server overwrites. Researchers receive better sensor-health, configuration, Bluetooth-connection, and study-exit context with the collected data.

Highlights

• Added persistent, per-sensor study consent.
• Added a researcher-controlled editable mode with participant-owned sensor settings.
• Added actionable collection states for collecting, delayed, blocked, event-driven, disabled, and unavailable sensors.
• Added custom hardware-sensor sampling rates in Hz with live interval conversion.
• Added frequency-aware sensor-health reporting to the research database.
• Made manual study updates reviewable before they replace an editable configuration.
• Made study exit conditional on acknowledgement from the research database.
• Fixed Network Traffic collection on current Android devices.
• Added Bluetooth connection-state data.
• Reduced unnecessary preference refreshes and full-screen recreation.

Permissions and Study Consent

Permission and consent requests now follow the sensors a study actually needs instead of presenting every possible request at startup.

• Startup requests only the permissions needed by the core app and sync framework.
• The legacy client path was aligned to enable only necessary sensors instead of starting unrelated collection.
• A per-sensor consent screen lets participants review each requested data source before enrollment is finalized.
• Consent decisions are stored per study and sensor, enforced when configurations are applied, and retained across Activity recreation and app restarts.
• Runtime permissions are requested sequentially; already granted permissions are skipped and each missing permission is requested at most once per sequence.
• Accessibility and Location settings prompts are sequenced so one request does not obscure or interrupt another.
• If Android no longer allows an in-app permission prompt, the participant receives an explanation and a route to the application settings.
• Denying a permission no longer causes the requesting service to restart repeatedly or creates a permission-dialog loop.
• Fixed repeated Accessibility requests.
• Hardened Bluetooth behavior when runtime permissions are missing or revoked.
• Removed the unnecessary READ_CONTACTS request.
• Corrected GET_ACCOUNTS handling so it is requested only on Android versions where the legacy sync framework requires it.
• Wi‑Fi scanning now detects when Android Location services are disabled and guides the participant to enable them.
• Consent is not incorrectly activated for program joins that do not require the study-consent flow.
• Added missing sensor consent mappings and centralized consent checks so join, update, and editable-mode behavior agree.

Editable and Locked Study Modes

Researchers continue to control whether participants may edit study settings through enable_config_update.

Locked mode

• The server configuration remains authoritative.
• Participants see only sensors enabled for the study.
• Local attempts to change researcher-controlled settings are rejected.

Editable mode

• All supported and unsupported sensor options remain visible.
• Participant changes are persisted into the active study configuration rather than treated as temporary drift.
• Opening the app and scheduled configuration checks do not silently restore the server configuration.
• Each participant sensor change adds a compliance record carrying the effective study configuration, allowing researchers to interpret subsequently collected data.
• The sensor list, status text, and icon state update in place without recreating the whole Activity.

Manual study updates

• Check for study updates is the explicit way to compare an editable configuration with the server.
• The participant sees which sensors the server proposes to activate or deactivate before anything changes.
• Agree and update applies only the exact configuration the participant reviewed.
• Keep my settings retains the current device-specific configuration.
• Leave the study opens a separate confirmation before any exit action is taken.
• If the server configuration changes between preview and acceptance, the app requests a new review instead of applying an unseen version.
• Accepting an update opens the consent flow when newly enabled sensors require additional consent or permission.

Sensor Availability and Collection Status

The interface now distinguishes configuration state from actual data collection.

• Added a centralized hardware detector for physical sensors.
• Hardware checks used by the UI and configuration application now share the same helper instead of maintaining separate rules.
• Unsupported sensors remain visible in editable mode with an explicit explanation such as “This device has no gyroscope sensor.”
• An unavailable sensor cannot be activated: its checkbox is disabled, stale enabled values are cleared, and a write-time guard rejects activation through another UI path.
• Hardware-blocked sensors are excluded when a server configuration is applied to the device.
• Opening a sensor in editable mode shows an inline, non-editable collection-status row.
• Participant-facing states include Collecting, Delayed, Waiting for first sample, Enabled and waiting for an event, Blocked, Unavailable on this device, and Disabled.
• Blocked states identify missing runtime permission, Accessibility, or Android Location requirements.
• Status details include the latest sample time and, where possible, a concrete action the participant can take.
• Sensor icons use the same collection state as the status text, avoiding conflicting indicators.

Frequency and Sampling Settings

• Replaced ambiguous free-text hardware-sensor frequencies with sensor-specific presets and a Custom value… option.
• Added appropriate presets and defaults for individual sensors.
• Custom hardware-sensor rates are entered and displayed in Hz, including decimal values such as 2.5 Hz.
• The custom-rate dialog explains that Hz means samples per second and displays the corresponding interval live—for example, 20 Hz is one sample every 50 ms.
• Hardware-sensor rates are converted to Android's required microsecond sampling period only when stored; polling and scan frequencies remain expressed in seconds.
• Applied the same preset/custom interaction to Ambient Noise and OpenWeather settings.
• Corrected descriptions that previously confused sampling periods, polling intervals, and upload frequency.
• Centralized time-unit conversions and applied them consistently across hardware sampling, Location, Bluetooth, Wi‑Fi, Processor, Applications, and Network Traffic.

Frequency-Aware Sensor Health

• Sampled sensors are evaluated against their configured collection frequency rather than a fixed 30-minute timeout.
• A sample remains healthy for three expected intervals, with a two-minute minimum and one-day maximum to avoid impractically narrow or broad health windows.
• Event-driven sensors are reported as enabled and waiting for an event instead of becoming falsely delayed during a quiet period.
• Added a dedicated diagnostic utility shared by participant status and researcher logging.
• The existing ten-minute study-compliance job writes parseable sensor_status records to aware_log.
• Each record includes the sensor state, device setting, latest sample timestamp, expected freshness window, exclusion state, and reason.
• The same diagnostic records are emitted immediately after joining a study and after applying a configuration update.
• These diagnostics use the existing synchronized log table and require no server database migration.

Study Join, Information, Update, and Leave

• Built the foundation for study-information and enrollment-history improvements.
• Redesigned the study information experience with a reusable study card and a clearer joined-study list.
• Fixed join, leave, and rejoin tracking so the active enrollment is selected by enrollment state rather than a stale URL or historical row.
• Fixed the quitting process and synchronization of study-exit state.
• Fixed study configuration serialization and restoration during reset.
• Corrected configuration synchronization and ensured the current configuration state is saved.
• Participants are reliably notified when a study configuration changes, including when no study screen was open during synchronization.
• Configuration updates apply only changed settings and report which sensors were activated or deactivated.
• Missing or differently shaped sensor settings are parsed through shared helpers instead of being dropped or causing update crashes.
• Live settings that drift from an otherwise unchanged locked configuration are reconciled safely, with backoff to avoid repeated service restarts for unsatisfiable hardware.
• Leaving requires explicit confirmation explaining that collection stops, local study settings are removed, and previously uploaded data remains on the server.
• The app uploads only the quit study exit record rather than waiting for every provider to finish a full synchronization.
• Local study cleanup occurs only after the research database acknowledges the exit record.
• If acknowledgement fails—for example, while offline—the participant remains enrolled, no study settings are removed, and the app asks them to reconnect and retry.

Network Traffic Collection

• Replaced telephony data-activity callbacks with periodic TrafficStats sampling.
• Network Traffic now records Wi‑Fi and mobile received/sent bytes and packets at frequency_network_traffic.
• Wi‑Fi-only devices and sessions no longer depend on a cellular callback before data is written.
• Unsupported mobile counters fall back safely while total traffic remains collectable.
• Counter resets do not create negative traffic values.
• Repeated service starts replace the previous callback instead of creating duplicate collection schedules, and stopping the service removes pending callbacks.
• Network Traffic participates in the same frequency-aware collection diagnostics as other sampled sensors.

Bluetooth Data and Reliability

• Added a Bluetooth data column that records connection status, giving researchers more context than discovery data alone.
• Hardened Bluetooth runtime-permission handling.
• Applied the shared frequency-unit conversion to Bluetooth scan scheduling.
• Preserved hardware and permission explanations in participant-facing sensor status.

Interface Responsiveness and Consistency

• Added consistent dialog sizing and window behavior across the phone interface.
• Removed manual onContentChanged() calls where preference setters already notify their own rows.
• Sensor categories refresh once per synchronization pass even when several status_* settings belong to the same category.
• Unchanged setShouldDisableView() state is not written repeatedly.
• Added and removed study sensors are reconciled in place instead of restarting the interface.
• Applied redundant-refresh fixes to both the current settings interface and the maintained legacy path.
• Ambient Noise and OpenWeather retain preference references on their Activity and use lifecycle-managed listeners.
• Plugin preference rows no longer refresh unnecessarily when values have not changed.

Plugin Stability

• Fixed crash loops in Ambient Noise and OpenWeather.
• Fixed Ambient Noise silence detection.
• Fixed an Ambient Noise sample-size timing race.
• Corrected plugin preference refresh behavior.
• Added frequency dropdowns and defaults for Ambient Noise and OpenWeather.

Security

• Removed the exposed API key from the interface and source.

Build, Dependencies, and Release Automation

• Stopped tracking generated APK and JAR artifacts.
• Replaced vendored dependencies with declared build dependencies where appropriate.
• Removed dangling Anko dependency references.
• Removed dead Gradle configuration, redundant declarations, and an obsolete data-offload path.
• Removed a redundant provider _ID declaration.
• Added a tag-triggered GitHub Actions release workflow.
• Updated release CI SDK setup for 2026 runner images.

Researcher and Data Impact

• Participant-specific editable configurations are retained on the device and included in compliance history.
• Sensor-health records provide context for missing or delayed data without requiring a new database table.
• Study exit is visible as an acknowledged aware_studies record with an exit timestamp and study_compliance = "quit study".
• Network Traffic produces one Wi‑Fi and one mobile row per configured interval, including zero-value rows when a transport had no traffic, making collection cadence explicit.
• Bluetooth records now include connection status.
• Existing configuration formats remain compatible: hardware-sensor sampling periods are still stored in microseconds even though custom values are presented in Hz.

Tests and Validation

• Added unit coverage for generalized configuration parsing and missing-sensor handling.
• Added unit coverage for configuration synchronization and saved state.
• Added unit coverage for hardware availability and configuration exclusion.
• Added unit coverage for sensor diagnostics and actionable participant status text.
• Added unit coverage for frequency-unit conversion, Hz conversion, and freshness windows.
• Added unit coverage for permission request sequencing.
• Added unit coverage for consent persistence and enforcement.
• Added unit coverage for editable configuration persistence, preview, approval, and manual synchronization.
• Added unit coverage for Network Traffic counter deltas and unsupported-counter handling.
• Core and phone unit-test suites pass.
• Ambient Noise and OpenWeather builds pass.
• Debug APK assembly passes.
• Network Traffic was verified on a physical Android device: after one configured 30-second interval, the previously empty database contained separate Wi‑Fi and mobile rows with non-zero Wi‑Fi byte and packet deltas.

Known Limitation

• When a participant enables a sensor that requires a runtime permission or Accessibility service, the app opens the appropriate grant flow. Fully reverting every just-enabled checkbox immediately after every possible denial/settings-return path remains follow-up work; the collection-status row still reports the sensor as blocked and explains the missing requirement.

Full Changelog: v4.2.1-fork.2...4.8.0.beta