Issue found: Invalid Data safety form
We reviewed your app’s Data safety form in Play Console and found discrepancies between it and how the app collects and shares user data. All apps are required to complete an accurate Data safety form that discloses their data collection and sharing practices - this is required even if your app does not collect any user data.
We detected user data transmitted off device that you have not disclosed in your app’s Data safety form as user data collected.
You must ensure that your app’s Data safety section accurately reflects your app’s data collection, sharing, and handling practices. This includes data collected and handled through any third-party libraries or SDKs used in your app. When available, we’ve included details on SDKs that contain code similar to the code in your APK that may be sending user data off device. You can check if your app uses any of these SDKs, but note that this list of SDKs may not be exhaustive. You must review and account for all data collected and shared by your app.
Issue details
We found an issue in the following area(s):
SPLIT_BUNDLE 3: Policy Declaration - Data Safety Section: Device Or Other IDs Data Type - Device Or Other IDs (some common examples may include Advertising ID, Android ID, IMEI, BSSID, MAC address)
I tried to update the information in Data safety but still, have the same error.
SPLIT_BUNDLE 3: Policy Declaration - Data Safety Section: Device Or Other IDs Data Type - Device Or Other IDs (some common examples may include Advertising ID, Android ID, IMEI, BSSID, MAC address)
Related
We are developing an emm console.
Currently we are facing one issue with device data. How to get the unique id from the device provisioned via enrollment token using Android management api.
A is an enterprise, we enrolled the mobile device to the enterprise A.
After that some policies are updated and it works fine. Later we factory resetting the device.
Now the same device is enrolled to enterprise B. The mobile device state is active in both enterprise A and enterprise B. We don't know how to overcome this issue?
My suggestion:
In our local database we planned to keep the id for device and enrollment time. To form the unique id of the device which field we want to compare or do we have any other options to compare and get the unique id
I may have misinterpreted the question(s), but what I did is pass extra data whenever enrolling a device - in my case, we are using devices as kiosk apps and they are tied to database 'terminal' entries that are already recorded in our server database. Whenever a device is enrolled, you can use an identifier system that you pass as the additional data. In my case, it was the id field of the database entry. Since the database was tied to unique fields, we could always query for the specific device ID based on the DB. So in my case, some facility would have 5 devices with unique id fields and names, even, so I could query devices.list and parse for the additional data where === my DB ids, and then update the database with the current, linked device ID.
For creating enrollment tokens: https://developers.google.com/android/management/reference/rest/v1/enterprises.enrollmentTokens
You set the 'additionalData' field when enrolling, then when calling devices.list or possibly devices.get, you can look for that ID field - it's under 'enrollmentTokenData' if using 'additionalData.' You could also set an account identifier tied to a user and use that as an ID. So during enrollment, you set 'user.accountIdentifier,' and then look for the same when doing devices.list/get.
API instructions on devices:
https://developers.google.com/android/management/reference/rest/v1/enterprises.devices
Again, this may not have been your issue, but it's how I personally kept up with the device IDs that are currently tied to my DB 'terminals.'
The main caveat to this is making sure I don't have duplicate devices enrolled (possibly like you have mentioned with Enterprise A/B, apologize if misinterpreted). What I've done is setup my admin console so that you can call devices.delete. This does a factory reset AND deletes the device item from the Mgmt. API. If you manually do a factory reset on the device, then the device record STILL RESIDES in the Mgmt. API, which doesn't seem ideal. So we just make sure to always use the Mgmt API to delete devices, so as not to have duplicates.
I'm getting app events through Firebase analytics on Android, and when I query the data in BigQuery I find that many (not all) of the devices don't have a "resettable_device_id" (which is the IDFA according to:
https://support.google.com/firebase/answer/7029846?hl=en).
When I look in the app's database I do see identifiers that don't appear in BigQuery, but I know these are IDFAs because they match some of the BigQuery identifiers.
The app developer says that he gets the identifiers I see in the database from Play services, and he can't help with the Firebase side because the identifier is sent automatically by the SDK.
Why can't I get the identifiers? Can I change something in order to get them?
I am developing an app that sends user-created data to a server.
Is it possible to recognise the same user when he is using the app on different devices without my app having to request access to his Google account, requiring additional permissions or asking him to create custom login credentials? (This is important as my app needs to work for 'anonymous' users.)
My app uses push notifications and, for any given user, I understand that the token ID generated by FireBase may be the same for each of his device installations of the app. So I am considering using these token IDs to identify the same user across multiple devices. However, I'm not sure how reliable that approach would be - or if there is a better way?
NB - I found Best Practices for Unique Identifiers (the Handling Multiple Installations section in particular), but it hasn't helped.
We can manage multiple installation with same account,
Generate device token using firebase
store token locally and on server also
on splash screen always check token stored locally with token stored on serever
if it shows differences ask user to keep only one device active to receive notification ,
if user selected current device store that token to server.
I'm trying to come up with an app in which I need to access user's emails for some functionality. I'm getting the normal "View and manage emails" permission from the user for the Gmail access.
I'll be storing the email on the user's device. But is it a problem if I store the details on my own web server too? Is that a data policy violation? Has anyone tried that here?
There are also a few apps which actually do something like this - Swingmail, Tripit, Boomerang. I know they store data on the device, but there is no way of knowing if they even store data on their web servers.
Initial research:
I went through the Google API TOS and below are the 3 things that seem to point that we can store data on the web server:
Security: You will use commercially reasonable efforts to protect
user information collected by your API Client, including personally
identifiable information ("PII"), from unauthorized access or use and
will promptly report to your users any unauthorized access or use of
such information to the extent required by applicable law.
Retrieval of content: When a user's non-public content is
obtained through the APIs, you may not expose that content to other
users or to third parties without explicit opt-in consent from that
user.
Prohibitions on Content: Unless expressly permitted by the
content owner or by applicable law, you will not, and will not
permit your end users or others acting on your behalf to, do the
following with content returned from the APIs:
Scrape, build databases, or otherwise create permanent copies of such content, or
keep cached copies longer than permitted by the cache header;
I think we can still store the data for a user provided user grants permmission for that and the devs takes sufficient measures to protect the data obtained from Google APIs.
I'm not sure it's a stackoverflow question, but as I've been thinking about this:
What does Google say about it?
This is in the terms of service, which you have found.
What is your relevant data protection laws say about it
For example in the UK, you need to consider if you are a data controller, and have taken reasonable measures to secure the data, amongst other things.
What is the process you take if you lose the data for instance. There can be financial penalties if you get this wrong.
Are your users informed (this is linked to 2)
Your users need to have agreed to this, in some acceptable form. How do they remove their data, how long is it held, how is it used.
Now, IANAL, but you have to be careful, you will likely be putting things in a Terms & Conditions, which is a basis of a contract, and there be dragons. For example reasonable in UK law can have a host of pitfalls http://www.linklaters.com/Insights/Publication1403Newsletter/PublicationIssue20070605/Pages/PublicationIssueItem2385.aspx
Bottom line? I'd get a lawyer.
I'm attempting to implement a system for upgrading/unlocking various features of my app using "managed" purchases with in-app billing, and I'm getting bogged down by the lack of in-depth documentation or examples.
My app's purpose is to retrieve/parse and display data from my own server, and the documentation on http://developer.android.com/guide/market/billing/billing_best_practices.html states:
If you are using a remote server to deliver or manage content, have your application verify the purchase state of the unlocked content whenever a user accesses the content.
My question is, what is the best way to go about this in terms of actual workflow?
As far as I can tell, on successful purchase I would store the purchase information on my server as well as locally in the app. When the app runs, I would send the order ID to my server and the server would check to see if the order is valid (firstly checking that the order exists in my server's database, and secondly checking if I have not manually revoked the order for whatever reason).
If that is verified, the server would send a response to the app that the requested features are "licensed", and the app would provide the unlocked features/content to the user.
The obvious problems I can see with this are:
A rooted user could easily just alter the local app's SQLITE database (or whatever other method I use to store order information) to inject a valid order ID.
If network access is down, or my server is down, I still want the app to be able to run (with cached data) with all the user's purchased features.
Potential ways around the first problem that I can see involve sending some sort of device identifier with the verification request, and monitoring that at my server's end - revoking the order if a large number of devices are accessing the order in a short period of time.
For the second problem, I can't figure out an adequate solution. I initially thought that each time the verification is successful, the time this verification took place would be stored. Then, the app would continue to run with the unlocked features for say, 48 hours after the last successful verification. The issue with that is, how can I securely store this time value? Again, rooted users could simply alter the value and the app would be none-the-wiser.
Has anyone designed a server-based system for managing in-app billing purchases and can offer some suggestions?
Google Licensing provides a way to allow a cached 'You're license is valid' response to stay alive.
Application Licensing
You can also encrypt the data your are storing. If they have paid for it, they get to decrypt it. If no network access available, then implement a similar caching scheme as Application Licensing (currently licensed under the Apache License, Version 2.0).