4.8.1.beta

The crucial changes that are made for this pre-release

• Sensor and plugin consent is now shown before joining a study instead of after, and covers the plugins a study needs as well as its sensors, grouped into labelled sections
• Leaving a study now always completes on the device, even when the research database cannot be reached; telling the researcher is best-effort, and the exit record states when it could not be delivered
• New: when a researcher changes a study's database password, the app tells a rejected password apart from a database that is simply down, asks the participant to re-enter it, and pauses uploads until it is accepted
• Fixed joining a study from a link or QR code, which crashed before any validation had run
• A study that needs a participant-entered password can now be joined from a link or QR code; the app asks for the password instead of failing with nothing the participant can do
• Join failures now say what is actually wrong: an invalid configuration, a missing password, a wrong password, or a database that cannot be reached. An unreachable database is no longer reported as a wrong password
• Study addresses are checked before anything is downloaded, so a missing or malformed address gives a message instead of failing silently
• When several study config checks are triggered at once, the app now runs one check instead of queuing every request
• The app now stops waiting for a study configuration that does not answer in time, and refuses a configuration file larger than 5 MB
• Sensors whose hardware the device does not have are now also ignored when a config update is applied, not only on first sync
• Fixed a background timer that kept a processor core busy for hours for every pending ESM questionnaire
• Fixed a pending ESM questionnaire preventing a study join from ever starting
• The background collection notice is now always visible and silent, says that study data is being collected, and opens the app when tapped; added the notification permission that Android 13 and later require
• Fixed screenshot capture restarting in a loop and creating a new capture session on every background service start
• Fixed MQTT failing to start on an empty or malformed port, keep-alive, or quality-of-service setting
• Fixed a worker thread being leaked on every restart of the background service
• Fixed a scheduled action failing the whole scheduler when it pointed at something no longer installed or carried an unreadable value
• Further Ambient Noise collection stability fixes
• Fixed repeated permission requests looping in the background after a permission was denied
• Security: database passwords are no longer written to the device log, including the database connection log
• Security: password, secret, and token values are masked in logged study configuration and study data
• Security: uploads are always encrypted, and a study that publishes its database's certificate authority in its configuration also gets the server's identity verified, so data reaches that study's server and no other host. A study that publishes no authority still gets an encrypted connection, but the server it connects to is not verified
• Upload progress is tracked in its own table, so each table is uploaded once instead of being re-sent from the beginning whenever the log was cleared
• Device information is now one row per device, rewritten when the device's hardware or Android version actually changes, and the server records a row per change
• Device information drops four fields that carried no information: the serial (which Android stops reporting), the build type, the device label, and the brand (the manufacturer says the same thing)
• Log entries now carry the kind of entry they are, so restarts, schedules, uploads, study changes and sensor diagnostics can be counted separately
• Study rows now record when the configuration was last updated, name the join and re-join events explicitly, and carry the configuration only on the rows where it changed
• Device information is no longer sent to awareframework.com when a device is first recorded
• Fixed the on-device database never upgrading: a schema change was aborted part-way and silently rolled back, so several releases' worth of database changes had never reached a phone that already had AWARE installed. Upgrades now complete, keeping existing data, and a failed upgrade is recorded instead of being discarded
• A study configuration is now applied even while the research database is unreachable. Only the upload waits for the database to come back; the participant is no longer told every minute that their study configuration is broken when nothing is wrong with it
• A wrong database password and an unreachable database now give different messages when the study configuration is checked
• Fixed a crash when the screen was rotated while a study was being joined
• New: the participant is told when the study needs something from them — a study password, or consent for sensors a researcher has newly added — as a notification, so a paused study is noticed without opening the app. Notifications appear only for changes that need a decision: a frequency-only change is applied quietly
• New: the main screen shows how far collected data has reached the research database, and each sensor shows the same alongside when it last recorded
• New: the participant is told when data stops reaching the research database, and told once rather than repeatedly. Data continues to be collected and kept on the device until it can be sent. Researchers see when delivery started failing, why, and when it recovered
• Fixed sensors reporting that they had never collected anything once their data had been uploaded and cleared from the device; the status and the researcher diagnostics now count delivered data as data the sensor collected
• Fixed the magnetometer comparing one axis against the wrong two when deciding whether a reading changed enough to record, which made any magnetometer threshold keep and drop readings unpredictably
• Sensor sensitivity settings (accelerometer, barometer, gravity, gyroscope, light, linear accelerometer, magnetometer, proximity, rotation, temperature) changed from raw numeric entry to descriptive presets stated in each sensor's own unit, with recommended values per sensor. A sensitivity larger than the sensor's readings ever change by is refused, and one already set that way now says the sensor is recording nothing instead of showing the number alone
• Fixed a single sensor's delivery failure being hidden by the other sensors still delivering: whether data is reaching the research database is now tracked per sensor rather than as one flag for the whole upload. The main screen names the sensors that are not delivering, and a sensor that recovers no longer clears a warning that belongs to a different one. Researchers see each affected sensor's failure and its recovery separately
• Fixed location collection stopping permanently the first time a study configuration was applied, and never resuming for as long as the app kept running, while the location sensor still reported itself as active. GPS, network and passive location are now re-registered when the sensor restarts
• Fixed an upload waiting indefinitely when the research database accepts the connection and then stops answering. The wait is now bounded, so the stall is reported to the participant and the researcher instead of passing unnoticed for hours, and one stalled table no longer holds back every other table's upload. Collection is unaffected either way and data is kept on the device until it can be sent

Full Changelog: 4.8.0.beta...4.8.1.beta

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 receiv...

v4.2.1-fork.2

Fixed bugs from previous pre-release

Consents

Before, the app only asked for 5 consents: Location, Wi‑Fi, Bluetooth, Telephony, and Calls/Messages. Applications and Keyboard sensors had no consent entry at all, so participants never saw a clear request for them.

Now Applications and Keyboard have their own consent entries. Participants see a request for every sensor the study uses, and the enable flow works more consistently (no more sensors quietly skipped).

Crash on sensor update

When a study update changed which sensors were on or off, the app sometimes crashed. The cause: code like Integer.parseInt(Aware.getSetting(...)) and Double.valueOf(Aware.getSetting(...)) read a setting and converted it to a number with no try/catch. If that setting was empty or not a number at that moment, this threw a NumberFormatException and crashed the app. This was already fixed for Applications, Processor, and the Ambient Noise plugin (AudioAnalyser.java, AudioAnalysis.java) in an earlier fix – see commit 6c37754.

Now every sensor has the same safe try/catch handling, so the app no longer crashes on study join, re-join, or config updates. Unit tests were added to lock this fix in place.

Config sync now checks real device state, not just saved text

Before, when checking for study updates, the app only compared the saved config text to the new config text from the server. It never checked what was actually running on the phone. So if the phone's real sensor settings drifted away from the config (for example after a reset), the app still said "no updates" and never fixed it – even though a sensor could be silently off.

Now the app also checks the live sensor settings on the phone, not just the saved config text. If it finds a mismatch, it fixes it automatically. This means the sensor list and "what's collecting" info shown to the participant is now accurate, and drift gets self-corrected instead of going unnoticed.

Sensor hardware detection refactor

The project's README says aware-phone should hold the participant-facing UI logic, and aware-core should hold the internal logic. Sensor hardware detection (checking if the phone has a given sensor, like a barometer) broke this rule, so the logic lived only in the UI layer, so background code couldn't use it.

Now hardware detection lives in aware-core, in one shared place. The UI code and the background config-sync check both use the same logic, so they can never disagree about whether a sensor's hardware exists.

Sensor exclusion log for researchers

Before, if a sensor could not collect data – no hardware, missing permission, Accessibility Service off, or Location Services off – only the participant could see this, inside the app. The researcher had no way to know why a sensor showed no data.

Now the app writes a log line for each excluded sensor and its reason. This log goes to the researcher's database the same way other logs already do, so no new setup is needed. Researchers can now see, per participant, which sensors are excluded and why (no hardware, missing permission, Accessibility off, or Location Services off).

---

Which APK should I download?

This release has 5 APK files, one for each phone CPU type. Pick the one that matches your phone. If you are not sure, arm64-v8a is correct for almost all modern Android phones (bought from 2017 or later).

File name	Use it if...
aware-phone-arm64-v8a-debug.apk	Your phone is a normal modern Android phone (most common choice).
aware-phone-armeabi-v7a-debug.apk	Your phone is an older or budget 32-bit Android phone.
aware-phone-armeabi-debug.apk	Very old phone, only needed if the other options don't install.
aware-phone-x86-debug.apk	Only for Android emulators or old Intel-based tablets.
aware-phone-x86_64-debug.apk	Only for Android emulators or Intel-based Chromebooks.

How to check your phone's CPU type: go to Settings → About phone, and look for "CPU" or "Processor" info. If you don't see it there, you can install a free app like "Droid Hardware Info" from the Play Store, which shows this clearly.

If you install the wrong one: the app will simply fail to install or crash right away – it will not damage your phone. Just delete it and try a different file.

v4.2.1-fork.1

Changes / fixes made so far

Study config sync reliability

• Fixed a race where overlapping sync triggers (scheduled poll, manual button, app resume) could interleave Aware.reset() calls and corrupt settings: syncs are now serialized through a single-thread executor.
• Fixed study lookup to use Aware.getActiveStudy() instead of matching webservice_server against study_url by string prefix – any drift between a join link and the resolved config URL silently broke every future sync.
• Aware.reset() now preserves device_id/device_label/webservice_server/frequency_webservice/pending_study_update_notice across its wipe, and self-heals webservice_server from aware_studies if it ever drifts.
• Switched config-diff comparison from JSONAssert LENIENT to NON_EXTENSIBLE so added/removed sensor entries are actually detected.

Study settings lock & update notifications

• Participants can no longer edit sensor/config settings while enrolled in a study unless the researcher's config sets enable_config_update – enforced at both navigation time and write time.
• Participants are reliably notified of curated study changes (sensors added/removed, lock toggled) even if the app wasn't open when the sync happened, via a persisted pending-notice setting.
• Fixed a WindowLeaked crash when a study-update dialog triggered recreate() while a nested settings screen was still open.

Wi-Fi / Location enforcement

• WiFi data collection requires the OS-level Location toggle; participants are now prompted to enable it, and the sensor status screen reports "Location services are off" as the reason WiFi isn't collecting.

Sensor consent screen

• New per-sensor runtime-permission consent screen shown after joining a study that needs runtime permissions (location, contacts, call log, etc.), replacing ad-hoc permission prompts.

Plugin crash fixes

• Fixed NumberFormatException crash loops in the ambient_noise and OpenWeather plugins when a study config sync (Aware.reset()) left a setting momentarily empty mid-read — including a recurring crash during ambient_noise's up-to-60s recording loop that was force-killing the app.

Security

• The OpenWeather plugin no longer displays the raw API key in its settings summary (was shown in plaintext). Removed a hardcoded default API key baked into source (XML default + code fallback) – rotate that key since it may already be exposed.