Declaring Data Safety

Fill in your app's Data safety form in Google Play Console for the data the Wemap SDKs send to Wemap.

Overview

Google Play asks you to declare the data your app collects, including data collected by third-party SDKs such as Wemap's. Android has no manifest that declares it for you, so use the tables below to answer the questions under App content › Data safety yourself.

Wemap does not use any of this data for tracking, advertising or marketing, and sells it to no one. It does not pass the data on to third parties or data brokers. Wemap processes itinerary and VPS data on your behalf to provide the service, and uses analytics data only for its own product measurement. You remain responsible for informing your users in your own privacy policy.

What to declare

Which rows apply depends on which features you use.

Feature	Data type	Purpose	Shared
Usage analytics (on by default)	App activity › App interactions	Analytics	Yes
Usage analytics (on by default)	Location › Precise location	Analytics	Yes
Itineraries and navigation	Location › Precise location	App functionality, Analytics	No
Itineraries and navigation	App info and performance › Diagnostics	App functionality	No
VPS positioning	Photos and videos › Photos	App functionality	No
VPS positioning	Location › Precise location	App functionality	No
VPS positioning	App info and performance › Diagnostics	App functionality	No

Every row is collected: the data leaves the device and Wemap keeps it, so the ephemeral-processing exception does not apply. Wemap acts as your service provider for the rows marked No under Shared, which Google does not count as sharing. The analytics rows are shared: Google exempts only a transfer to a service provider acting on your behalf, and Wemap uses analytics data for its own purposes.

The other questions have the same answer for every row:

• Is all of the user data collected by your app encrypted in transit? Yes. The SDKs reach Wemap over HTTPS only, and a map whose VPS endpoint is not HTTPS cannot start VPS positioning.
• Do you provide a way for users to request that their data is deleted? Not for the data sent to Wemap. None of it is linked to a user: itinerary requests carry no identifier of the user or the device, the analytics identifier is random and changes every hour, and the VPS session identifier is random for each location source. Wemap therefore cannot find one user's data, and cannot delete it on request. Answer for the data your app collects itself, and don't promise your users that a deletion request reaches Wemap.
• Is this data required or optional? It depends on your app — see each feature below.

Usage analytics

The SDKs report how the map is used, such as a session starting, a navigation starting, recalculating, stopping or arriving, a VPS scan, or a point of interest being opened. A navigation event carries the coordinates of its destination, which is why analytics also declares Precise location. Every event also carries your app's package name and the map id. Events are grouped by a random identifier that changes every hour. It is not derived from the device and is not kept across sessions.

Analytics is on by default, and the SDKs don't ask your users for consent. To turn it off, set SessionConfig.isAnalyticsEnabled to false when you create the session. The session then sends no analytics at all, and the analytics rows no longer apply. If your own privacy policy gives users a choice, create the session once you know their answer: a session created with analytics on reports its creation straight away. Declare the rows optional only if every user of your app can make that choice; otherwise declare them required.

Itineraries and navigation

To compute an itinerary, the SDK sends its origin and destination to Wemap's routing service. During navigation, the origin is the user's current position. Wemap keeps these coordinates to provide routing and to measure routing quality. Each request also names your app, its package name and version, and the SDK version, which Wemap keeps with the request — hence the Diagnostics row. No request carries an identifier of the user or the device. Declare the rows optional if users can use your app without requesting an itinerary.

VPS positioning

Each scan attempt uploads one photo of the user's surroundings to Wemap's positioning service, along with the device manufacturer and model, the Android version, and your app's name, package name and version. People in the photos are blurred automatically. Wemap keeps each photo with the position it computes from it, which is why VPS also declares Precise location. The upload happens only while VpsARCoreLocationSource is started — a scan the user starts, or a background scan the source runs to keep the position accurate — and only once the user has granted camera access. Wemap uses the photos only to locate the user and to troubleshoot positioning problems. Declare the rows optional if users can use your app without VPS.

The offline VpsLocalLocationSource runs entirely on the device and sends nothing.

ARCore

VpsARCoreLocationSource runs on Google Play Services for AR (ARCore), which collects data of its own, sent to Google rather than to Wemap. If you use it, declare ARCore's data as Google lists it in Data safety form in Google Play Console, and show the notice that ARCore's privacy requirements ask for. The GeoAR SDK does not use ARCore.

Nothing else to declare

The map, the AR view, the GPS and fused location sources, and the map widgets send nothing to Wemap beyond what is listed above. The device's position stays on the device, and reaches Wemap only as an itinerary origin. Map tiles are loaded through MapLibre, which sends no telemetry.

Permissions are separate

The Data safety form doesn't replace the runtime permissions that unlock camera and location access. Request them as described in VPS Location Source (CAMERA) and GPS Location Source.

Keeping your declarations current

This page describes the SDK version it ships with. Review it, and your answers in Play Console, whenever you update the Wemap SDKs.