developerpact SDK

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

INTERNET is a normal permission this plugin adds (Flutter’s release manifest does not carry it). BIND_GET_INSTALL_REFERRER_SERVICE comes from Google’s installreferrer 2.2 AAR, not from this plugin’s manifest. Nothing else is merged. The dependency set is frozen at exactly one artifact, com.android.installreferrer:installreferrer:2.2; tool/check-merged-manifest.sh in the package fails the build if any other permission appears.

One line you will also see in a merged manifest is not ours: <applicationId>.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION. It is an app-private, signature-level permission that androidx.core — a dependency of the Flutter embedding itself — declares in every Flutter app, with or without this plugin. The check script tolerates it only under your own package name.

Not used: WorkManager, foreground services, push, ACCESS_NETWORK_STATE, OkHttp, androidx.lifecycle, the Kotlin stdlib.consumer-rules.pro is merged automatically and keeps only PairActivity and the Install Referrer AIDL stubs.

The whole public API, for completeness — there is deliberately no track(), no setUser(), no properties, so there is no function an integration could leak app data through:

enum DeveloperPactStatus { paired, notPaired, unsupported }

class DeveloperPact {
  static Future<DeveloperPactStatus> start({Uri? endpoint}); // endpoint is for SDK testing only
  static bool get isSupported;
}

<activity
    android:name="com.developerpact.sdk.PairActivity"
    android:exported="true"
    android:excludeFromRecents="true"
    android:noHistory="true"
    android:theme="@android:style/Theme.NoDisplay">
    <intent-filter>
        <action android:name="android.intent.action.VIEW" />
        <category android:name="android.intent.category.DEFAULT" />
        <category android:name="android.intent.category.BROWSABLE" />
        <data android:host="${applicationId}" android:scheme="devpact" />
    </intent-filter>
</activity>

${applicationId} resolves to your app’s ID at merge time — the same mechanism the Facebook, Stripe and Braintree SDKs use — so devpact://com.your.app/pair reaches this activity and nothing else. Your MainActivity and Flutter’s deep-link handling are untouched; the activity is invisible (Theme.NoDisplay), out of recents, and finished before it is drawn.

It is exported because a browser has to be able to open it. Any app on the device can send that intent, but a token only pairs with the testing it was minted for, and an install id stays with the first testing it paired with: the server answers a token for any other testing with a plain 404 — never with the kill switch — so a foreign intent can neither move your install onto someone else’s testing nor silence it. The token is validated for format (22 characters of base64url) before it is stored, and the activity itself carries no data, only the tap.

Every heartbeat carries the day’s cumulative seconds; the server keeps the max and never sums, so a re-sent day is harmless. On the device: session cap 4 h, day cap 8 h, at most 7 unsent days kept, a checkpoint to SharedPreferences every 20 s while visible. “Foreground” means the app window is STARTED — split-screen and picture-in-picture count, a screen that turns off does not. The bucket day is the local calendar day the session started on.

Not sent, ever: device model, locale, IP geolocation, advertising or App Set ID, account information, app content.

Android only, and only ever Android. There is no iOS implementation and there will not be one: Apple has no closed-testing prerequisite and no Install Referrer, and iOS code would enlarge the audit surface of the claim that this plugin can do nothing else.

On every other platform only the Dart stub compiles. DeveloperPact.start() returns unsupported at once, stores nothing, sends nothing, registers nothing and never throws — an app that targets both stores can leave the call unguarded. There is nothing to add to the App Store privacy form.

The platform is evidence for a person choosing whom to keep, not a proof system; the rows marked ✓ are open by design in v1 and say so.

A published SDK version keeps reporting for at least 6 months after the next version ships. The server can retire versions below a minimum; such a build gets 410 {stop: true} and goes silent until the app updates and re-pairs. Removing the dependency is the local kill switch — nothing on the device survives it: no service, no receiver, no scheduled work, no file outside the app’s own SharedPreferences.

Once Google grants production access:

1. Delete the developerpact line from pubspec.yaml and the start() call.
2. Ship an update. The merged permission, the PairActivity and the devpact:// scheme disappear with it.
3. Remove the two Data safety rows and the privacy-policy sentence.

If you would rather keep it in the app for the next closed-testing round, the declaration stays honest as written: installs that were never paired with the platform do not touch the network, and paired installs stop the moment the testing ends. Details on the Data safety page.

The published archive is what the numbers describe, the line counts are measured, the hash is reproducible from a download, and this site’s test suite fails whenever any of it drifts from the package files.

Package

https://pub.dev/packages/developerpact — version 0.1.1, MIT

Source

https://github.com/cns-studio/developerpact

a repository that holds this package and nothing else; the same files as the archive, for reading rather than hashing.

Wire string

every request carries sdk: "flutter/0.1.0"

it names the code build, not the release: 0.1.1 changed package metadata only and ships the same code as 0.1.0.

Size

1,469 lines of plain Java, comments included, and 60 lines of Dart — small enough to read in one sitting, which is the point

Archive SHA-256

3f4897cdbde9934808b8aeb4827125328280cf35b2b713c6b7a2623a468a3a2e

48 files, 174,080 bytes; ustar; entries sorted by path; mtime 0; uid/gid 0; mode 644; no compression. The same file set pub uploads, rebuilt in a form anyone can reproduce bit for bit — pub’s own gzipped archive is not byte-stable, so its hash is not the one to compare.

Merged permissions

• android.permission.INTERNET
• com.developerpact.developerpact_example.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION
• com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE

read from the example app’s merged debug manifest; the third one is androidx.core’s app-private permission, present in every Flutter app. PairActivity merged: yes.

Support

a published version keeps reporting for at least 6 months after the next one ships; a retired build hears 410 {stop:true} and goes silent

Measured by tool/trust.sh inside the package and checked in as trust.json; this site's test suite re-runs the script against the package files and fails when a number here has drifted.

Reproduce the hash

From pub.dev, which needs no repository, no git and no account — the archive for a version never changes. tool/trust.sh is inside it; python3 is all it needs.

mkdir developerpact-0.1.1 && curl -sL https://pub.dev/api/archives/developerpact-0.1.1.tar.gz | tar xz -C developerpact-0.1.1
cd developerpact-0.1.1 && bash tool/trust.sh | grep sha256

Or from the source repository, which is the same files with their history. Its branch moves with each release, so read it there and hash the published archive above.

git clone https://github.com/cns-studio/developerpact && cd developerpact
bash tool/trust.sh | grep sha256

The plugin is a convenience, not a gatekeeper: everything it does is two POSTs to https://developerpact.com/api/sdk/v1/… with content-type: application/json, and the heartbeat’s Authorization: Bearer <installSecret>. Any stack that can read the Install Referrer (or accept a devpact:// deep link) and count foreground seconds can report the same numbers. The full contract, the status codes and the generated JSON schemas are on the REST API page. The bodies below are parsed through the server’s own schemas in the test suite, so they are what the server accepts, not an approximation.

{
  "v": 1,
  "pkg": "com.example.myapp",
  "token": "Qm9yaW5nVG9rZW4xMjM0NQ",
  "installId": "5f0c2a1e-9b3d-4c7a-8e21-6d4f1b2a9c03",
  "pairedVia": "referrer",
  "installer": "com.android.vending",
  "initiatingInstaller": "com.android.vending",
  "appVersionCode": 42,
  "sdk": "flutter/0.1.0",
  "osApi": 34,
  "tzOffsetMin": 180
}

{
  "installSecret": "K3q9ZbQ2xW8vL5nR7tY1uC4eH6jM0pA8sD2fG5hJ9kL",
  "serverDay": "2026-09-06",
  "rules": {
    "thresholdSeconds": 60
  }
}

{
  "v": 1,
  "pkg": "com.example.myapp",
  "installId": "5f0c2a1e-9b3d-4c7a-8e21-6d4f1b2a9c03",
  "day": "2026-09-06",
  "tzOffsetMin": 180,
  "fgSeconds": 97,
  "sessions": 2,
  "appVersionCode": 42,
  "sdk": "flutter/0.1.0",
  "osApi": 34,
  "installer": "com.android.vending",
  "sentAt": "2026-09-06T11:02:13.000Z"
}

{
  "ok": true,
  "activeToday": true,
  "serverDay": "2026-09-06"
}

Native Android, React Native, Unity or Kotlin Multiplatform wrappers are not published yet — they arrive when a member needs one. Say so in the box at the bottom of this page.