Data safety
Play Data safety answers
Your answers for the AdHedge SDK in Play Console's Data safety form. Combine them with your own app's answers.
Does the SDK collect or share user data?
Yes.
Data types
| Play category and data type | Collected | Shared | Ephemeral | Required | Purposes |
|---|---|---|---|---|---|
| Device or other IDs: Device or other IDs | Yes | No | No | Yes | Fraud prevention, security, and compliance; Analytics |
| App activity: App interactions (touch counts and timing) | Yes | No | No | Yes | Fraud prevention, security, and compliance; Analytics |
| App info and performance: Diagnostics | Yes | No | No | Yes | Fraud prevention, security, and compliance; Analytics |
| Location: Approximate location (country, derived on our server from the request IP; the SDK reads no location) | Yes | No | No | Yes | Fraud prevention, security, and compliance; Analytics |
- Device or other IDs: yes, for an install record that uses no Android ID. The SDK sends a client-generated install UUID and, when your app already includes Google's App Set library, the Play App Set ID. Our server combines device facts (build values, chip, screen resolution, stable density, memory rounded down to 256 MiB, core count, sensor types, API level, installer, network transport, battery, uptime, sensor count) into a per-install record. Google treats a server-side device fingerprint as a device identifier regardless of which fields compose it, and fraud prevention is a purpose, never an exemption. Declare it.
- The build fingerprint names a firmware build, not a device: every device of one model on one firmware version reports the same one. On a device whose system was built by its owner it can be rare, and it can hold the name of the account that built it. AdHedge keeps these values with the install's signals for 90 days. Like everything else in the install record, they are not combined across apps into a device identity.
- App activity: yes. For a new install the SDK observes touches in the app's activities on the day it first runs and the day after, by the device's clock in UTC. Every field is under Behavior.
- App info and performance: yes. Installer package, install and update times, version code, debuggable, ADB and test-keys flags, emulator and root heuristics, and the Play Integrity token are diagnostics about the app binary and its environment. Every field is under Fields the SDK sends.
- Install referrer: attribution data. Answer it under App info and performance. It needs no other answer unless your own referral or invite links put a user identifier in it; if they do, also declare Personal info, User IDs.
- Approximate location: the country our server derives from the IP address of each request, kept with the install. The SDK reads no location API.
- Advertising ID: the SDK does not read or send the advertising ID. Server-sent delivery, a design that is no part of the SDK, is the one designed exception: the advertising ID would be sent only in blocking mode, only when the app already declares it, and only for delivery to the developer's own AppsFlyer or Adjust account.
Fields the SDK sends
Once per install, after a configuration answer, the SDK builds one signals request and sends it. The request is collected again only when it has gone unanswered for seven days. While a Play Integrity token is still to be asked for, the SDK sends the same bytes again before each ask. Behavior is the one group sent apart from it; its own table says when.
A value the device's API level cannot provide, or whose read fails, is sent as null. None of these fields needs a runtime permission.
App and install
| Field | What it is | Android source |
|---|---|---|
| Install ID | A random UUID the SDK creates once. Built from no device identifier. | UUID in the SDK's preferences |
| Play App Set ID | In the developer scope. Read only when your app already includes Google's App Set library; the SDK ships none of it. Null otherwise. Our server hashes it on receipt and never stores it raw. | AppSetIdClient |
| Package name | Your app's package. | Context.getPackageName |
| Signing certificate hash | SHA-256 of your app's signing certificate. | PackageInfo.signingInfo |
| First install time | When your app was first installed on the device. | PackageInfo.firstInstallTime |
| Last update time | When your app was last updated. | PackageInfo.lastUpdateTime |
| App version code | The running build. | PackageInfo.longVersionCode |
| SDK version | The AdHedge SDK version. | SDK constant |
| Android API level | The device's Android version. | Build.VERSION.SDK_INT |
| Config version | The version number of the configuration the service sent. | SDK config |
| Attestation sample flag | Whether the install falls within the share of installs the configuration's sampling rate selects for a Play Integrity token, by a number the SDK draws at random once per install. | SDK config |
| Existing-user flag | Whether the app had been updated since its install and more than 48 hours had passed since that install when the SDK first recorded this. | Install and update times |
| Request hash | A SHA-256 digest of the request, which the SDK repeats to Play Integrity so that the token is bound to the request. | Computed by the SDK |
Install facts
| Field | What it is | Android source |
|---|---|---|
| Installer package | The package that installed your app. | installingPackageName |
| Package that started the install | Android 11 and up. | initiatingPackageName |
| Install source type | The install's source as the system classifies it. Android 13 and up. | packageSource |
| Play Install Referrer string | The referral text of the store link the install came from, cut to 1,024 bytes: whatever the link's author put in it, which can name a campaign and an ad click, and, for your own referral or invite links, whatever those carry. The only free-text field. | installReferrer |
| Referrer click time | The time of that click. | referrerClickTimestampSeconds |
| Install start time | The time of the install's start. | installBeginTimestampSeconds |
| App version at install | The version installed. | installVersion |
| Referrer availability | Whether the Play Store could answer. | InstallReferrerClient response |
| Debuggable build flag | Whether the app is debuggable. | FLAG_DEBUGGABLE |
| USB debugging setting | Whether USB debugging (ADB) is enabled. | Settings.Global.ADB_ENABLED |
| Test-keys build | Whether the system was built with test keys. | Build.TAGS |
| Work profile | Whether the app runs in a work profile. Android 11 and up. | isManagedProfile |
Device checks
| Field | What it is | Android source |
|---|---|---|
| Emulator build markers | Which of a fixed list of patterns the build values match. | Build.* |
| Root markers | Whether a path of a fixed list exists, checked for existence and never opened, and whether the file system holding /system is mounted writable. No app lookups. | File and mount checks |
| Network transport type | The active network's transport. No SSID, BSSID or IP address. | NetworkCapabilities |
| VPN active | Whether the active network is a VPN. | TRANSPORT_VPN |
| Proxy set | Whether a proxy is set, never its address. | http.proxyHost |
| Battery level | Percent. | BatteryManager |
| Charging state | Whether the device is charging. | BatteryManager |
| Time since boot | The time since the device started. | SystemClock.elapsedRealtime |
| Sensor count | The number of sensors. No sensor readings. | SensorManager.getSensorList |
SIM state and phone type are fields of the request that are always null: the SDK reads no telephony.
Build values
The device's build values as Android gives them to any app. Each string goes out only as 1 to 64 characters of printable ASCII, 256 for the fingerprint. One that is empty, longer or holds another character is sent as null, never cut and never changed.
| Field | What it is | Android source |
|---|---|---|
| Device brand | The brand name. | Build.BRAND |
| Device manufacturer | The manufacturer name. | Build.MANUFACTURER |
| Device model | The model name. | Build.MODEL |
| Device name | The device name of the build. | Build.DEVICE |
| Product name | The product name of the build. | Build.PRODUCT |
| Hardware name | The hardware name. | Build.HARDWARE |
| Board name | The board name. | Build.BOARD |
| Chip maker | The maker of the chip. Android 12 and later. | Build.SOC_MANUFACTURER |
| Chip model | The model of the chip. Android 12 and later. | Build.SOC_MODEL |
| Build fingerprint | Names a firmware build. See the note under Data types. | Build.FINGERPRINT |
| Build type | The build type. | Build.TYPE |
| Android release | The Android release. | Build.VERSION.RELEASE |
| Security patch date | The security patch date. | Build.VERSION.SECURITY_PATCH |
| Processor ABIs | The list of processor ABIs. A name outside the contract's list is sent as OTHER, and a list of more than eight is sent as null. | Build.SUPPORTED_ABIS |
Hardware figures
| Field | What it is | Android source |
|---|---|---|
| Screen short side | The smaller figure of the default display's active mode, in pixels: the display's own, never the app's window. | Display.Mode |
| Screen long side | The larger figure of that resolution. On a folding device it is the display in use. | Display.Mode |
| Stable density | The screen's density as built: the platform's stable density, read in place of the current one, which the display-size setting changes. Null below Android 7. | DENSITY_DEVICE_STABLE |
| Memory rounded down to 256 MiB | The device's memory, never the exact figure. | ActivityManager.MemoryInfo |
| Processor cores | The number of processor cores. | Runtime.availableProcessors |
| Sensor type numbers | The type number of each sensor, never a sensor's name or readings. Null when a device lists more than 128 sensors. | SensorManager.getSensorList |
A screen, density, memory or core figure outside the contract's bound is sent as null.
Behavior
This is the App activity group. For a new install the SDK observes touches on the day it first runs and the day after, by the device's clock in UTC, and at no other time. Installs the SDK first met through an app update are not observed. What is observed is the same for every observed install, whatever its verdict.
| Field | What it is | Sent |
|---|---|---|
| Touches in a session | The number of touches, for each session from the first activity shown to the last one hidden. | Per session |
| Session length | The session's length. | Per session |
| Interval sums | Two sums over the times between one touch and the next: their total and the total of their squares. The service computes from them how much those times vary. | Per session |
| First-touch delay | The delay from the SDK's start to the first touch, with the time of that touch. | Once per install |
| Day-after return | Whether a session began on the day after the first run. | Once per install |
| Event time | The device's clock at the event. Our server also records when it arrived. | Per event |
It never records coordinates, which view or screen was touched, screen names, content, or the time of any other touch.
One request follows each observed session, sent in batches of at most 20 events. An unsent batch is removed at the first launch that starts the SDK after seven days by the device's clock, or with the app's data. At most 20 sessions are reported per app process. Nothing counted is stored or sent unless the app's configuration has behavior on and the SDK is not paused. Kept 90 days from when each arrives.
How touches are observed: one Application.ActivityLifecycleCallbacks registration, and a wrapper around the Window.Callback of each Activity created after the SDK starts. Touches in a dialog's or a popup's own window are not seen. No View.OnTouchListener on your views, no accessibility service, no input injection. On the dispatch path the wrapper reads the event's action and nothing else of it; when a touch begins it reads a clock and adds to a count and two sums; then it calls the callback that was there before. It allocates nothing per event, keeps no reference to the event, takes no lock and does no I/O. More in the docs.
Seen by our server
The SDK doesn't send these. Our server reads them from each request.
| Field | What it is | Kept |
|---|---|---|
| IP address | The address each request comes from. Never stored with install data; our proxy's access log holds it, for operations. | 14 days |
| Network prefix | The IP address with its host part removed. | 13 months |
| Network operator | The network the request came from and whether it is a hosting provider. Derived from the IP address. | 13 months |
| Country | Derived from the IP address and kept with the install. | 13 months |
Purposes
Fraud prevention, security, and compliance. Analytics. Never advertising or marketing, personalization, account management or developer communications.
Shared
No. AdHedge processes the data on your behalf as a service provider, and Google's Data safety guidance does not count transfers to a service provider as sharing. AdHedge does not sell the data, does not combine it across apps into a device identity, and does not join it to advertising identifiers or personal information.
Handling
- Encrypted in transit: yes. TLS only; the SDK has no plaintext transport.
- Deletion: you ask for an install's data to be deleted with its install ID, through the form. The ID is on the install's page in the console. Your users ask you, and you hold the mapping from a user to an install. We delete signals, attestation records and events within 30 days of a request.
- Retention without a request: signals, attestations and events 90 days. IP address 14 days, in our proxy's access log only; network prefix and operator 13 months. Installs, their country and their verdict history 13 months.
- Optional collection: none. Every signal is nullable by API level, but a user cannot opt out of the SDK inside your app. You decide whether to include it.
Tell your users
Your app's privacy policy covers what your app collects, the SDK's part included. Say that the app uses Install Trust to verify installs, and link the SDK privacy policy. Your Data safety answers for the SDK are the table under Data types and the notes below it; combine them with your own app's. This is guidance for filling in the form and no legal advice.
Never collected
- Android ID, Firebase installation ID
- Advertising ID
- IMEI, device ID, serial number, MAC address, SSID or BSSID
- Phone number, phone state, SIM state, phone type, SIM operator, SIM country
- Contacts, calendar, SMS, call logs
- Precise location. The SDK reads no location API; the only location is the country our server derives from the IP address
- Lists of installed apps
- The full IP address with install data. Our server keeps a prefix only
- Touch coordinates, screen contents, screen names, text input
- Accounts, email addresses, names. The build fingerprint of a device whose system was built by its owner can hold that builder's account name
- The name a user gave the device, its Bluetooth or host name, any sensor reading, and the display-size, font or language settings a user chose
Permissions
The SDK declares no runtime permission. Three permissions merge into your manifest: INTERNET and ACCESS_NETWORK_STATE, which most apps already declare, and com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE, which Google's Install Referrer library merges so that the app can ask the Play Store for its own install referrer. Everything else the manifest gains is listed in the docs.
Play Integrity
The SDK sends at most one Play Integrity token per install, requested under a Google Cloud project linked to your app in Play Console. It is requested on the device, bound to the signals request's SHA-256 digest, and sent with the install ID, that digest and how long the request took. Our server decodes it, keeps the decoded fields and the token's hash, and drops the token.
Play is asked at most three times for an install, inside seven days. Each time there is no token the SDK sends a report: the install ID, the time by the device's clock, and Play's error code or one of timed out, no Cloud project configured, the Play Integrity library missing from the app, interrupted, other.
Play Integrity Terms prohibit using the API to fingerprint or track individual users or devices. AdHedge keeps no cross-app device identity and uses a verdict for the single app that requested it.