Data safety

developerpact SDK — data disclosure. Collected: (1) Device or other IDs — a random install identifier generated by the SDK; (2) App activity → App interactions — daily foreground time in seconds. Collection is automatic (required, no in-app toggle) and occurs only for installs paired with a developerpact.com testing account (via a testing link or a pairing link); ordinary users generate no traffic. Purpose: Analytics; App functionality. Shared: Yes, with developerpact.com — it uses the data for its own purposes (a cross-developer ledger), so Google’s service-provider exemption does not apply. Encrypted in transit: Yes. Deletion: Yes — testers delete their data at developerpact.com/me. Not collected: names, emails, location, device identifiers, advertising ID, contacts, app content. Merged Android permissions: android.permission.INTERNET, com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE.

Why “Shared: Yes”. Google exempts a “service provider” that processes data only on the developer’s behalf. developerpact.com does more than that: the same numbers feed a ledger every other member reads, and the reliability counters that follow a tester from app to app. That is a purpose of its own, so the exemption does not apply and the honest answer is Yes.

Everything else in the form is No. Encryption in transit: Yes (TLS only; the SDK refuses plain http). Deletion: Yes — a tester deletes their account and its installs and days at developerpact.com/me. The merged permissions, for the permissions section of the same form:

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE" />

“During closed testing this app uses the developerpact SDK, which reports a random install identifier and daily foreground usage time to developerpact.com for testers who joined through that platform; see developerpact.com/privacy.”

A more conservative reading adds Personal info → User IDs, because the pairing token is tied to an account on the platform. The default here is not to add it, and the reason is in what the SDK can see: it never receives the account, the e-mail or any name — only a random 22-character token that the server maps to a testing, and later a random install id. The mapping lives on developerpact.com, which declares it in its own policy. If your reviewer, your lawyer or your own reading says otherwise, adding the row costs nothing and contradicts nothing on this page.

After production is granted: delete the pubspec block and the start() call, ship an update, and take the two rows and the sentence back out. The merged permission, the PairActivity and the devpact:// scheme leave with the dependency.

Keeping it for the next closed-testing round is fine, and the declaration above stays honest as written. Two properties make that true: an install that was never paired with the platform never touches the network — the referrer is read once, the flag is written, and that is the end of it for that install — and a paired install stops the moment its testing ends (410 {stop: true}). So “occurs only for installs paired with a developerpact.com testing account” is not a promise about your intentions; it is what the code does, and the code is short enough to check.

If your app already reads the Install Referrer — Firebase, AppsFlyer, Branch, Adjust — multiple readers are fine; the value is not consumed by reading it. Installs through the platform show up in those tools as utm_source=developerpact with the token in utm_content, which is why the link uses the utm_ format rather than something opaque: your analytics sees a named source, not garbage. Nothing about those tools’ own declarations changes.