Repository navigation
Releases
v1.0.0-rc.22
The App can now report its own errors and step timings, separately from any study, when the
participant agrees.
- Opt-in debug information. On first launch the App asks whether to share debug information
with its developers through PostHog; nothing is sent before the participant agrees, and the choice
can be changed at the bottom of the main screen. Events name fixed App steps (import, setup
steps, start, pause, resume, complete, withdraw, category switches, export, startup), their
outcome category and duration, export phase durations with coarse event-count and 50 MB size
buckets, and uncaught errors by exception type and stack frames. They never carry study data,
survey answers, configuration content, study or experiment IDs, the installation code, or error
messages. Session replay, screen-view and deep-link capture are off.
Updating from RC21: install the newer APK over the existing app. Study data, configurations
and choices are unchanged; the debug-information question appears once after the update.
v1.0.0-rc.21
The RC20 tag did not produce a public release: its release run was cancelled after an instrumented
test that still used the removed optional parameter was found. RC21 contains the RC20 changes
below with that test corrected, and follows RC19 as the next public release candidate.
Participants can now understand and shape what a study collects about them, and researchers decide
how much of that a study discloses.
- Three tiers for data categories (configuration schema 2). A signed configuration may now mark
each collectorcore,requestedoroptional, with an optional researcher-written rationale,
and sign a participant disclosure policy with two switches: approximate collection frequency and
a collection timeline. Core behaves like the formerrequired: true. Requested and optional
categories can be skipped at the Access step or turned off during the study; a requested one
first shows a fixed note that this may affect compensation. Schema 1 configurations remain valid
and behave exactly as before (required → core, not required → optional, nothing disclosed).
The researcher tool writes schema 2 and converts an opened schema 1 draft, which must be re-signed. - Turning categories off and back on. While running, a participant choice closes the condition
epoch at one drained boundary and records the collector asOPTIONAL_FAILEDwith reason
PARTICIPANT_DISABLED; while paused, it takes effect at Resume. The choice is durable as a new
PARTICIPANT_CHOICEruntime component and commit kind, so automation cannot turn the collector
back on. Core categories cannot be turned off. - Withdraw asks about unsent data. In a study with automatic upload, Withdraw offers to keep
sending data that has not been sent yet or to stop sending. Stopping is durable and one-way; data
the research team already received stays with them, and manual export still works. - Progress and timeline in Study and my data. Every study shows a progress bar over its signed
duration. When the signed policy allows it, the page also shows paused spans and an hour-by-hour
timeline of when each category collected data, and each category's approximate frequency. - Exports no longer run out of memory. Android's AES-GCM cipher buffered the whole export
before encrypting it, so exporting a full five-day study could exceed the app's memory and
crash (seen on a Pixel 10a with about 89,000 events). Export now encrypts as it writes, with
constant memory, and produces byte-for-byte the same AES-256-GCM output, so the bundle format
and every reader are unchanged. - Kotlin, Python and TypeScript verifiers accept the new commit and component kinds and reject a
participant choice on a core collector or an applied collector the participant turned off. The
event-source registry is unchanged, so earlier exports, including RC13 pilot bundles, still verify.
Updating from RC19 or earlier: install the newer APK over the existing app; do not uninstall
it. The application ID and production signing certificate are unchanged. Accepted schema 1
configurations and existing study data remain supported without conversion. A study signed with
schema 2 requires RC21 or later; earlier releases refuse it at import.
v1.0.0-rc.19
Long cold starts now show saved-data checking progress, elapsed waiting time, and separate
restoration/preparation stages. Each scan reuses one Cipher while independently initializing and
authenticating every saved frame. Progress comes from that same scan, without another decryption
pass. Cancelling recovery closes the unpublished runtime and preserves saved study data.
The RC18 tag did not produce a public release: its API 37 reboot qualification stopped at the
first readiness query's five-second transport limit. RC19 includes the CI control correction and
follows RC17 as the next public release candidate.
- Cold-start readiness queries now share the existing qualification budget. The overall reboot
deadline, safety-pause proof, notification check, stopped data admission and crash/process checks
remain. Live queries and mutation admissions retain their five-second limit; a lost response
fails without relaunching the activity or resubmitting an operation. - PRs run one debug JVM/lint/build lane. Full API 34/API 37 device qualification runs at release
or manual dispatch, alongside the host checks and signed APK build. Publication requires every
result and uses that same verified APK. API 34 now stops before emulator launch if APK prebuild
fails. Native test builds compile only the emulator ABI and retain an NDK-specific Go cache.
Duplicate invocations and 11 source-text or fixed-copy tests were removed; two executable
cold-readiness regression tests were added. Observed PR feedback fell from about 39 minutes to
about 7–13 minutes across runs with different runner/cache conditions, not a fixed guarantee. - The participant website uses simpler study descriptions, shows the current study QR in its
study details, and lets study-guide downloads finish on slow connections.
Updating from RC17: install the newer APK over the existing app; do not uninstall it. The
application ID remains cool.jacoblin.particeps and the production signing certificate is unchanged.
Accepted signed configurations, layout 3 files and existing Keystore keys remain supported without
conversion or reset. Interrupted active studies recover paused until the participant resumes.
Previously retired layouts and unavailable collectors remain unsupported.
Full retained-history authentication still runs before readiness, so startup cost grows with
retained data. These changes do not establish the cause of the reported Samsung S24 Ultra stall
or measure its startup speed. See the crypto and recovery review
and CI scope and timing evidence.
v1.0.0-rc.17
Latest five-day study: download the current signed study and Traditional Chinese instructions from the participant page. The study uses stable filenames and URLs: study.partcfg and participant instructions. The current questionnaire contains seven questions. Download and import the study again for each new setup; installing the APK alone does not update an imported study. Existing enrolled studies keep their original configuration. The dated 20261005 participant ZIP is a historical six-question snapshot, not the current study download.
This release improves participant disclosure, collection recovery, and verification of
five-day study exports. Physical-device admission checks and daily data return remain necessary;
these changes do not establish a completed 120-hour physical-device endurance run.
The RC14, RC15 and RC16 tags did not produce public releases because their CI gates failed. RC17
follows RC13 as the next public release candidate.
-
Application dependency construction and session initialization run in the background behind one
explicit readiness boundary. Participant screens, Android results and study-entry intents,
workers and receivers wait for the same initialized components. Unexpected initialization
failures release waiters and show a neutral failure screen; they do not leave a permanent
loading screen or expose incomplete components. Foreground-service notification and startup
acknowledgement remain immediate, before waiting for the application, so recovery cannot
deadlock with service startup. Existing recovery-required state and participant controls remain
unchanged. This removes filesystem, KeyStore and client construction from process binding;
it does not guarantee responsiveness under arbitrary device CPU starvation. -
Interrupted runtime checkpoint writes can recover from an authenticated base and the complete
authenticated commit log even when a staging snapshot was only partly written. Staging files are
retired only after recovery succeeds. Invalid bases, authenticated conflicting documents, damaged
retained commits and pending-input failures still stop recovery; process recovery remains paused
until the participant explicitly resumes. -
Limited traffic uses separate bounded flow queues in both directions before
paced Layer-3 admission. Previously, waiting for uplink credit stopped TUN reads;
sustained transfers could fill the kernel queue and stall TCP delivery even when
their average rate passed. A downlink FIFO also let download data delay upload
acknowledgements. Each direction now has a shared hard limit of 128 packets and
64 KiB across 1024 fixed hash buckets, with byte-deficit scheduling.
Uplink uses CoDel and capacity drops. Limited downlink admission never waits for
queue capacity on a shared TCP processor: it removes the minimum required tail
packets from the highest occupied-MTU score (ceil(backlog_bytes / 1500)),
including the incoming packet in that decision. Equal scores rotate the
resident tail selected for removal, so smaller resident single-packet queues
cannot always reject a full-MTU newcomer. A strictly highest-score incoming
backlog still loses its incoming tail. Scheduling remains byte based; admitting
a large packet can require multiple small-packet drops, and this policy does
not guarantee ACK priority or progress for every flow under arbitrary traffic.
Its effective byte limit follows 100 ms of configured bandwidth,
bounded by one MTU and 64 KiB; the consumer can hold one additional MTU.
A completed limited enqueue yields to ready workers after releasing its locks,
without waiting for the queue to drain. TCP explicitly uses Reno with SACK-based
recovery and leaves RACK disabled; controlled duplex tests exposed repeated
timeout/recovery cycles with the pinned stack's RACK mode after initial queue
loss. This choice applies to every study profile and does not alter the signed
rate settings. Congestion drops and retransmissions remain possible.
Classification keys are temporary; flow identities and hashes are not recorded
or exported. Counters include only admitted Layer-3 packets, including admitted
retransmissions; downlink admission requires a successful TUN write. Unlimited
profiles retain FIFO queue backpressure. Suspension, profile replacement and
shutdown retain the admission fence, and queued packets use the current profile
when delivered. Hash collisions and opaque traffic can share a bucket; strict
per-flow fairness and lossless delivery are not guaranteed. -
WorkManager initializes on demand with its existing default configuration. Its database is no
longer opened by the eager startup provider, and constructing the action and upload adapters
does not initialize it. Durable timer, action and upload scheduling still request the same
application-wide WorkManager instance when needed. -
Emulator throughput diagnostics can explicitly sample native counters, fixture write progress
and kernel drop/retransmission counters, or run a bounded 300-second stress interval. Routine
release gates retain their 60-second duration and original rate bounds, without periodic
foreground diagnostic broadcasts changing the app's process priority. -
Throughput gates also require each selected connection to make progress after a ten-second
warmup: more than five consecutive complete one-second buckets without payload fails the
measurement even if its aggregate rate passes. A simultaneous upload/download case checks
actual Android-received download payload under the same fixed 512/512 kbps profile, with
bounded start synchronization and the original rate bounds in both directions.
A focused 64/64 kbps duplex run uses the corresponding signed fixture and the
same rate and liveness bounds; the default release suite retains its 512 kbps case. -
Emulator readiness waits for completed boot before querying ActivityManager and
allows the stock SDK image to finish its initial HOME setup within the existing
deadline. API 37 cleanup bounds console commands, terminates only the process
owned by that runner, preserves the original failure status, and records whether
the emulator and temporary AVD were actually removed. -
Usage-event queries now check Usage Access and the unlocked-user state before and after each
query, including an empty barrier flush. Lost access fails the collector without advancing its
successful-query coverage, rather than recording an empty result as successful collection. -
A paused study immediately posts a neutral, persistent reminder to open Particeps and check
its status. Resume or study removal clears it. Notification delivery blocked by permissions or
channel settings is retried during access reconciliation; it is not cached as delivered.
Recovery remains paused until the participant explicitly resumes. -
Participants who have started a study get one Study and my data entry, identical in every
study arm, on the collection panel and on the access panel shown while required access is
repaired. It restates the study, researcher contact, consent text and version, signing-key
fingerprint, installation code and any assigned code, what each data category records and does
not record with the Android access it uses, the upload terms, the fixed VPN paragraph for a study
that may adjust transfer speed, and what Pause, Resume, Withdraw, and Delete local data do. It
also shows the state, study day, planned end once the phone's clock is verified, collecting and
paused time, the size and event count of an export made since Particeps last started, and local
storage measured when the page opens. Both sizes are shown in 50 MB steps ("Less than 50 MB",
"50–100 MB", and so on), and no byte count reaches the screen. The steps limit the bytes stored
per event, which depend on the arm's automation through per-commit overhead, to what a 50 MB
difference reveals. They do not hide when collection runs: the export's event count on this page
and the running screen's live event count stay exact. It has no lifecycle control. The Details
toggle is gone, and the signed configuration ID, which differs between study arms, is no longer
shown anywhere. -
Every setup step, from import through Ready, offers Decline and remove this study. After a
confirmation it removes the study and setup progress through the local deletion path; Android
access granted during setup stays on. -
The paused-since time and an ended study's length come from the commit that entered that state,
so later commits in the same state, such as upload acknowledgements, no longer move them. -
Intervention notifications carry a fixed public version: the app name and "A research activity
is available. Unlock your phone to see it." Android shows it in place of the researcher's title
and message only when the lock screen is set to hide sensitive content; Android's default shows
all content. -
Data-category copy states what each category records and does not record and no longer quotes
profile settings, such as sampling rates or poll intervals, that can differ between arms. The app
category is "Particeps app activity". The fixed traffic-shaping paragraph is reworded to be true
for both selected-app and all-app targets, the consent checkbox reads "data collection and
sharing", and the consent upload sentence and the public participant page say that unsent data
"can still be sent" after pausing or withdrawing. -
Upload progress on the running screen and export phase progress are whole percentages. Batch
counts are no longer shown, because how many commits a study makes depends on its automation. -
Automa...
v1.0.0-rc.13
- Manual encrypted export reads each retained commit once, using a scoped read snapshot instead of
repeating storage recovery and a full JSON prescan. Size-limited uploads stop reading when their
complete-commit budget is reached. Canonical JSON writing buffers characters and emits complete
string spans while retaining Unicode validation. - Exports show phase progress and support cancellation. Pause, completion, and withdrawal remain
available during export, including slow destination writes. Destination open, close, and failed
export cleanup run off the main thread; success is reported only after final close succeeds. - Cancelled or failed exports remove their incomplete file when the document provider permits it,
and report when manual removal is needed. Local study data remains available for retry. - Added a 24-hour study timeline, structured survey and automation editors, and native WebMCP
authoring tools to the researcher site. Improved simulation, import, key handling, review, and
bundle summaries, and fixed study-rule panels collapsing into dividers.
Application update from v1.0.0-rc.12: install the signed RC13 APK over the existing app
without uninstalling or clearing its data. The application ID and production signing certificate
are unchanged, and the Android version code increases. Allow an active export to finish before
updating when possible. RC12 has no export-cancellation control; if updating interrupts an export,
discard that incomplete file and export again after reopening RC13.
Local studies and exported data: RC13 introduces no local-store migration, mandatory reset,
event-source-registry change, or bundle-format change from RC12. Existing signed configurations and
local study data remain in place; they do not need to be re-signed. Reopen the app after updating,
complete normal recovery and access checks, and explicitly Resume the study. Older-release
restrictions documented below still apply. An export includes the fixed data boundary captured
when it starts; later study actions are included in the next export. Only send files for which the
app reports successful completion.
Fresh install: install the signed RC13 APK, then scan a research-team QR code or import its
signed study file. Review the study and data collection, provide consent, complete required access
setup, and explicitly Start.
Verification scope: this prerelease uses a locally built production-signed APK with version
code 40. APK signing and native-packaging verification, native Go race tests and vet, host unit
tests, API 34 storage and participant-export instrumentation, Kotlin-to-Python encrypted-bundle
verification, and debug/release lint and builds passed locally. The remote API 34 complete functional
gate, host CI, and Web, receiver, and analysis consumer checks also passed.
The remote API 37 x86_64 / 16 KiB gate was blocked before instrumentation by the existing
SurfaceFlinger / mapper.ranchu.so DMA-capability assertion on image revision 6 and emulator
37.1.11. All three APK-install attempts failed with a package-service broken pipe. Separate API 37
/ 16 KiB ARM64 compatibility instrumentation passed on the Play Store image revision 4; this does
not establish a pass for the remote x86_64 lane or its full host harness. The automated publisher
was skipped because it depends on that gate. See the
RC13 workflow evidence.
For 53.3 MB of synthetic data, the desktop export-core median decreased from 1.470 seconds to
0.253 seconds; this excludes Android Keystore, storage-provider, and network time and is not a
measurement of export duration on a participant's phone. A blocking provider write or close can
delay cancellation cleanup; study controls remain available while it finishes.
v1.0.0-rc.12
- Fixed the local VPN completing an app's TCP handshake before its protected upstream connection
succeeded. An unreachable IPv6 destination could appear connected and prevent the app from trying
a working IPv4 address. The VPN now connects upstream first and rejects failed connections before
acknowledging them, while retaining IPv4 and IPv6 support. - VPN shutdown cancels pending TCP connections, closes upstream sockets, and waits for endpoint
registration before shutting down the network stack. TCP half-close preserves the server's
response after the client finishes sending. - Added IPv4/IPv6 packet-level regressions for handshake ordering, rejected connections, complete
bidirectional transfers, half-close, and cancellation during connection setup and shutdown.
UDP round-trip tests verify complete packets and shaping transitions. The Android host harness
now requires a complete VPN download; failed transfers and skipped scenarios cannot count as a pass.
Application update from v1.0.0-rc.11: retain any required research exports, then install the
signed RC12 APK over the existing app without uninstalling. The application ID and production
signing certificate are unchanged, and the Android version code increases.
Local studies and exported data: RC12 introduces no local-store migration, mandatory reset,
or event-source-registry change from RC11. Existing signed configurations and local study data remain
in place. Reopen the app after updating, complete normal recovery and access checks, and explicitly
Resume the study. Installing the APK does not change a study's collectors, schedule, consent, or
questionnaire. The restrictions for older configurations documented in earlier releases still apply.
Fresh install: install the signed RC12 APK, then scan a research-team QR code or import its
signed study file. Review the study and data collection, provide consent, complete required access
setup, and explicitly Start.
Verification scope: this prerelease uses a locally built production-signed APK with version
code 39. Native Go race tests and vet, host unit tests, debug/release lint, and APK signing and
native-packaging verification passed. The remote API 34 complete functional gate and Web, receiver,
and analysis consumer checks also passed. Packet tests include a complete 256 KiB download through
the capped all-App VPN. The user reported restored browsing on a Pixel 10a running Android 16 after
an ADB update of the production-signed repair.
The remote API 37 x86_64 / 16 KiB gate was blocked before instrumentation by the existing
SurfaceFlinger / mapper.ranchu.so DMA-capability assertion on image revision 6 and emulator
37.1.11. Its three APK-install attempts failed with a package-service broken pipe, so the automated
publish job was skipped. Separate API 37 / 16 KiB ARM64 compatibility instrumentation passed on the
Play Store image revision 4; this does not establish a pass for the remote x86_64 lane or its full
host harness. See the RC12 workflow evidence.
v1.0.0-rc.9
- Added participant-relative study days and local-time windows. The five-day study examples run
for 120 hours from each participant's Start, apply aggregate 500 kbps upload and download limits
on local days 3–5 from 12:00 to 17:00, and invite one activity survey after each treatment window.
All-App shaping includes newly installed apps in the current Android user; the baseline keeps
the same VPN route with no rate cap. - Added screen power/lock state, notification metadata, passive device-throughput counters, and
independent VPN-state collectors. The existing default-network event contract remains unchanged.
Gyroscope collection keeps a partial wake lock while enabled; notification contents are not read
and throughput collection does not run active speed tests. - Each collector can select its own collection windows and profiles. A scheduled-off collector is
released, including its sensor registration and wake lock; selecting it again creates a new
verified generation. Required collectors fail closed when a selected profile cannot run. Required
actuators and collector sources used to trigger automations must remain active throughout the
running study. - Reduced repeated work while collecting: UI projections use one committed runtime snapshot,
admission waits suspend instead of polling, storage accounting reads file metadata, and encrypted
recovery snapshots are checkpointed by commit/byte thresholds. Every acknowledged event still
has a durable authenticated commit; lifecycle boundaries and recovery retain strict checks. - Web authoring, Kotlin execution, and Python replay agree on scheduled inactive collectors and
applied generations. Added a five-day example collecting gyroscope data only from 12:00 to 17:00
while the other collectors continue throughout the running study. - Both study examples include six questions covering off-phone activities, screen-free time,
other devices, device substitution, and substitution with activities without screens. These are
separately signed study configurations: installing the APK does not change an existing study's
questionnaire or schedule. - Added a configurable feature-level energy-estimation formula and a Pixel 10a scenario report.
The coefficients are explicit assumptions, not measurements or a validated device power model;
the estimates do not establish battery savings on participants' phones.
Timing and device limits: Android background wakeups can delay a window transition or survey
notification. Use recorded epochs, resource receipts, and event times to assess the actual exposure.
Process death or reboot requires participant Resume after normal fail-closed recovery. A complete
120-hour physical-device study and battery calibration have not been performed. The existing API 37
preview-emulator quarantine remains limited to the exact platform defect described in the
release process; it is not a full API 37 functional-pass claim.
Application update from v1.0.0-rc.8: export any research data that must be retained first,
then install the signed rc.9 APK over the existing app; do not uninstall first. The application ID
and production signing certificate are unchanged. Earlier releases retain the release-specific
Protocol/storage restrictions documented below.
Local studies and exported data: rc.9 introduces no local-store migration or mandatory reset
for rc.8 studies. Existing signed configurations are still checked against the current supported
contracts and access requirements; normal recovery and explicit Resume checks apply. Keep rc.8
analysis tooling for rc.8 export bundles: bundles bind the complete event-source registry digest,
which changes in rc.9. Use rc.9 analysis tooling for rc.9 exports. New collectors, schedules, and
questionnaires require a newly issued signed study configuration and participant setup.
Fresh install: install the signed rc.9 APK, then import a study configuration issued for rc.9.
The example configurations use public demonstration keys; researchers must supply their own study
information, consent text, and signing/export keys before recruitment.
v1.0.0-rc.11
- Added an in-app camera scanner as the primary way to join a study. Scanning uses the same
configuration verification, study/data review, consent, access setup, and explicit Start steps
as file import. File import remains available, including on devices without a camera. - Research QR codes contain an immutable HTTPS join link, the configuration's exact SHA-256,
and its signing fingerprint. The app downloads the signed configuration, so scanning requires
internet access. The code does not contain the complete configuration. Invalid codes, changed
artifacts, and mismatched signatures are rejected; scanning cannot replace an existing study. - The camera is requested only when opening the scanner and is released on backgrounding or
leaving it. Frames are decoded locally and are not stored. Added permission recovery, retry,
flashlight controls, and English/Traditional Chinese scanner screens. - Added downloadable SVG QR images to web study authoring for sharing or printing. Generation
stays in the researcher's browser, and changing or invalidating the link clears the old image. - Moved study-download body reads and temporary-file writes off the main thread, added an overall
download timeout, and prevented access refresh from competing with the initial import.
Application update from v1.0.0-rc.10: retain any required research exports, then install the
signed RC11 APK over the existing app without uninstalling. The application ID and production
signing certificate are unchanged, and the Android version code increases. Camera access is optional
and is not required to continue an existing study or import a file.
Local studies and exported data: RC11 introduces no local-store migration, mandatory reset,
or event-source-registry change from RC10. Existing studies retain their signed configuration and
remain subject to normal access, recovery, and explicit Resume checks. The RC10 restrictions for
older configurations selecting the removed notification collector still apply. Installing this
APK does not change a study's collectors, schedule, consent, or questionnaire.
Fresh install: install the signed RC11 APK, then scan a QR code issued by the research team
or choose its signed study file. Review the study and data collection, provide consent, complete
required access setup, and explicitly Start. Researchers must host the exact signed configuration
at the HTTPS address encoded in the QR; redirects and replacement bytes are rejected.
Verification scope: this prerelease uses a locally built production-signed APK. App unit tests,
targeted API 34 QR import/consent/camera-lifecycle instrumentation, web QR checks, debug/release lint,
and APK signing/native-packaging verification passed before release. This is not a claim that the
complete remote Android release gates or API 37 compatibility lane passed. Optical scanning on
physical devices and browser installation with Play Protect enabled remain to be verified.
Published artifact verification
- Version name:
1.0.0-rc.11; Android version code:38(RC10:37). - The published APK is the locally built, production-signed artifact. Its SHA-256 is supplied in the accompanying checksum file. The signing certificate matches the repository production identity.
- API 34 fresh installation and RC10-to-RC11 installation succeeded. The application UID and existing notification permission were preserved.
- Android Release run 34282054609: the complete API 34 gate and Web/receiver/analysis checks passed; the API 37 gate failed after three occurrences of the tracked
mapper.ranchu.so/SurfaceFlingerplatform assertion, and automated publication was skipped. Its evidence classifier reported no Particeps or test failure; this does not establish API 37 compatibility. The verified local APK is published with explicit maintainer authorization.
v1.0.0-rc.10
- Removed direct collection of other apps' notifications from the Android app, including the
notification listener service, its access setup, and the collector module. Particeps' own survey
reminders and ongoing research notification remain supported. - Removed the notification collector from web study authoring and both five-day study examples.
Each example now selects seven collectors; the 120-hour duration, collection schedules,
all-App speed-limit windows, and activity questionnaires retain their existing design. - Retained the published
notification_events.v1event contract for historical interpretation,
while marking the implementation unavailable and the source unselectable. Newly authored or
imported studies cannot select it; the complete event-source registry digest changes in RC10. - Hardened API 37 release checks to require an unlocked Android user and a successful
Application.onCreate()return, and to reject App crashes even when instrumentation reports success.
Release validation: The API 34 product-behaviour release gate and Web/receiver/analysis checks passed for commit b3326e2f3bf4e7a33a9083705e5cdea11b07e967. The signed APK passed release lint, production-certificate verification, four-ABI packaging and 16 KiB ELF alignment, and the merged-manifest check excluding notification-listener capabilities. Fresh installation and RC9 (versionCode 32) to RC10 (versionCode 37) upgrade and launch passed on the API 34 emulator, with the package UID and notification-posting grant preserved.
API 37 validation is incomplete: its emulator repeatedly failed during APK installation. The automated release workflow did not pass. This prerelease was instead signed and verified locally and published directly; it does not claim API 37 compatibility.
Installation: RC10 removes the notification-listener capability associated with the reported
RC9 Play Protect block and continues direct signed APK distribution. This does not establish that
Google Play Protect will accept it on every device. Browser download and installation with Play
Protect enabled on the affected physical phone remain to be verified; signing and emulator
installation do not establish that result.
Application update from v1.0.0-rc.9: export any research data that must be retained before
updating, then install the signed RC10 APK over the existing app; do not uninstall first. The
application ID and production signing certificate are unchanged. Android application identity and
local-study compatibility are separate checks.
Local studies and exported data: an RC9 study selecting notification_events.v1 cannot resume
in RC10. Complete or stop that study and retain its export while RC9 can still open it. After the
update, the incompatible study enters recovery; a participant-confirmed recovery reset deletes
local study data. Only reset after retaining the export, then import a newly issued and signed
configuration without the removed collector and repeat consent/access setup. Other studies remain
subject to the app's normal recovery and supported-contract checks. Keep the RC9 researcher and
analysis tools for all RC9 export bundles and use RC10 tools for RC10 bundles, because each bundle
binds its release's complete registry digest, even when it contains no notification data. Installing
an APK does not revise a signed study configuration.
Fresh install: install the signed RC10 APK and import a configuration issued for RC10. The
updated examples use public demonstration keys; researchers must supply their study information,
consent text, and signing/export keys before recruitment.
v1.0.0-rc.8
- Protocol v1 is replaced in place by a durable event-driven study runtime. The event-source
registry now defines both collector and system events; signed configurations define named
resource profiles, reusable one-shot actions, and closed-world automations. Lifecycle, timer,
action, resource, and condition-epoch records share one ordered event and commit history. - Encrypted storage now uses authenticated append-only
EngineCommitframes. A source observation,
reducer checkpoint, timer/action/resource mutation, generated audit event, and successor
projection either commit together or do not exist. Encrypted snapshots are recovery caches;
opening replays only complete commits after the newest authenticated snapshot, and export/upload
revalidate every complete commit they read. This preserves the cold-start performance work that
avoids reconstructing a long study one event at a time without weakening the commit-chain truth. - Collectors are stateful resources controlled by signed binding automations. Start and Resume do
not hard-code continuous collection: required resources must apply and verify before the first
condition epoch is committed and collector data admission opens. Any resource-vector change uses
one global flush/drain/apply/verify barrier. - Added source-built, fail-closed Android per-App traffic shaping. A local
VpnServiceforwards only
signed target packages through a gVisor userspace stack and applies aggregate uplink/downlink token
buckets. VPN ownership, TUN/native health, package identity, socket protection, and the exact
applied profile must all verify; loss closes admission and safely pauses the study. - The participant App keeps the existing five setup steps and compact running surface. Shaping
studies add one fixed high-level inline disclosure and Android's mandatory permission/consent
surfaces, but no trigger, treatment, profile, rate, timer, epoch, digest, or diagnostic dashboard.
Web authoring and encrypted analysis retain the complete signed and causal record. - The starting screen reports what startup is doing. After a short patience window it shows the
running activation stage — reading the study, checking authenticated storage, and restoring the
runtime — with an indeterminate bar. Participant UI remains generic; debug builds log stage
transitions with elapsed time so a development-device stall can be located. - Platform acknowledgements are bounded: durable timer/action wakeups, foreground-host acquisition,
and Play services location registration/removal cannot leave startup waiting indefinitely. A
timeout follows the same fail-closed resource path as an explicit platform failure. - API 37 compatibility remains a release blocker for compilation, installation, the revision 5+
16 KiB runtime, manifest/permission contracts, source-built native loading, non-snapshot
instrumentation, four packaged ABIs, and 16 KiB ELF alignment. The complete API 37 host harness
is temporarily quarantined only for the exact revision 5mapper.ranchu.so/SurfaceFlinger
readback assertion tracked in #33; App, VPN,
native, and test assertion failures still block. This release does not claim that the complete
API 37 host harness passed. API 34 continues to block on the complete functional, traffic,
throughput, lifecycle, process, package, permission, and competing-VPN harness.
This is a destructive pre-1.0 Protocol v1 cut. Signed configurations, encrypted storage,
bundles, receipts, readers, and scheduled-work state from every earlier build are invalid. There is
no migration, dual reader, or fallback. The app does not silently delete an incompatible local
study; the existing generic recovery/reset flow requires participant confirmation.
Coming from v1.0.0-rc.7: export any research data that must be retained before upgrading,
then install the signed rc.8 APK directly over rc.7; do not uninstall rc.7 first. The Android
application ID and production signing certificate remain unchanged, but an rc.7 study cannot resume
under this destructive Protocol/storage cut. After upgrading, use the participant-confirmed recovery
reset, import a newly issued rc.8-compatible signed configuration, and repeat consent/access setup.
Fresh install: install the signed rc.8 APK, then import an rc.8-compatible signed configuration.