Skip to content

Releases

v1.0.0-rc.22

v1.0.0-rc.22 Pre-release
Pre-release

Choose a tag to compare

@JacobLinCool JacobLinCool released this 12 Nov 22:09
2ca1254

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

v1.0.0-rc.21 Pre-release
Pre-release

Choose a tag to compare

@JacobLinCool JacobLinCool released this 12 Nov 20:44
ceee237

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 collector core, requested or optional, 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 former required: 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 as OPTIONAL_FAILED with reason
    PARTICIPANT_DISABLED; while paused, it takes effect at Resume. The choice is durable as a new
    PARTICIPANT_CHOICE runtime 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

v1.0.0-rc.19 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 26 Oct 19:11
df7506c

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

v1.0.0-rc.17 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 05 Oct 04:09

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

Read more

v1.0.0-rc.13

v1.0.0-rc.13 Pre-release
Pre-release

Choose a tag to compare

@JacobLinCool JacobLinCool released this 13 Sep 18:27
  • 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

v1.0.0-rc.12 Pre-release
Pre-release

Choose a tag to compare

@JacobLinCool JacobLinCool released this 10 Sep 17:42
  • 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

v1.0.0-rc.9 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 08 Sep 16:02
  • 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

v1.0.0-rc.11 Pre-release
Pre-release

Choose a tag to compare

@JacobLinCool JacobLinCool released this 09 Sep 05:15
  • 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 / SurfaceFlinger platform 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

v1.0.0-rc.10 Pre-release
Pre-release

Choose a tag to compare

@JacobLinCool JacobLinCool released this 08 Sep 20:50
  • 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.v1 event 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

v1.0.0-rc.8 Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 04 Sep 00:42
  • 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 EngineCommit frames. 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 VpnService forwards 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 5 mapper.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.