I'm nearing the end of creating an app that alters images for colour blind users. I'm now wondering how I can collect usage info from all users of the app.
In the app, the user chooses settings based on their specific level and type of colour vision deficiency. The only data I would need to collect is these two values (type and strength), the data would then of course need to be sent to me somehow for analysis.
Google analytics is good; either that or you have the app post data back to a web server you've set up somewhere.
IF you want to ship into Europe, you'll have to present users with a privacy policy that describes what data you capture and what you do with it, and allow them to opt in or opt out. That's a legal requirement. Probably also a moral requirement I think.
American companies used to bury these kinds of notices about 14 pages deep in an End User License Agreement, and gather all kinds of data. THe European Union now requires a separate Privacy Policy document.
Nothing wrong with collecting the data, as long as you allow users to opt in. Lots of apps gather lots of data for all kinds of purposes. But all the decent and respectable ones provide an opt-in/opt-out option.
have you looked at google analytics ? https://www.google.co.za/analytics/
Related
I've implemented in-app purchases in my app by using the Google Play billing library. I've implemented it as per the guidance here. This just a basic one-time purchases, and I don't store the purchase tokens or pass them to backend server or anything like that.
Looking at the data safety form in the Play store, there's a few questions around this area:
Does your app collect or share any of the required user data types? Yes/No
Is all of the user data collected by your app encrypted in transit? Yes/No
Under the: Financial Info > Other Financial info section: Is this data collected, shared or both?
Collected This data is transmitted off the user's device, either to you (the developer) or a third party. This includes data that is processed ephemerally, or stored for longer.
...AND/OR... Shared
This data is transferred to a third party, either on or off the user's device
My initial thoughts were the answers to the questions are:
Yes
Yes
Collected+Shared
But I'm not sure if this is correct. Thinking about it, what information is my app actually collecting/sharing? I'm just using the billing library to say "Does this user own sku X" or listen out when the library says "Hey, this person just purchased sku X". I'm not capturing or storing any kind of payment details or transaction history etc.
Can anyone offer their thoughts?
First off - I definitely recommend going through this doc - https://support.google.com/googleplay/android-developer/answer/10787469
Especially the What developers need to declare across data types section.
To a certain amount these are still murky waters, as this feature is new and Google is still figuring out which services go where. If you are not sure and want to be correct I would contact google support directly.
As to points:
Does your app collect or share any of the required user data types?
Definitely yes. There is an option later - Ephemeral processing - that says that it is being only used real-time and is not collected for a longer.
Is all of the user data collected by your app encrypted in transit?
Depends on the library. Haven't gone through it and hopefully someone will fill in the blanks here. My first guess would be yes, as google probably encrypts it.
Is this data collected, shared or both?
I would pick only collected, yet again for Ephemeral processing and also following lines stated in the documentation I mentioned earlier
The following types of data transfers do not need to be disclosed as
'sharing':
Service providers. Transferring user data to a 'service provider' that processes it on behalf of the developer.
'Service provider' means an entity that processes user data on behalf of the developer and based on the developer’s instructions.
I think you are correct, it is:
1.Yes
2.Yes
3.Collected+Shared
I've got an app which shows user's contacts inside device and allows him to make a call.
I want to show my user the last calls he has made. I was using READ_CALL_LOG permission (and was reading call log) until Google restricted access to it, then I switched to ContactsProvider to retrieve contacts and sort them by LAST_TIME_CONTACTED but now Google says this column is deprecated and effectively it will have 0 value for new versions of Android OS (see https://developer.android.com/guide/topics/providers/contacts-provider#ObsoleteData)
My app is not a default dialer (only default dialers apps are allowed to access call log) so I was wondering how I can achieve what I want in Google Policy compliant way.
I tought about storing the last contacts selected inside my own database (I know it won't be a full call log, as I will only have access to calls made from my app but that's fine for me), but don't know whether it's compliant with G Policy. I wrote an email to Google, however the person who replied said he can't help me with my question and I have to create new version of my app and ask them for review.
Does anyone know if my idea about saving contacts in my own database is compliant with G policy (please provide links from official sites). From my link (which I've provided above) I can only see that Google says
If your apps are accessing or updating these fields or APIs, use
alternative methods. For example, you can fulfill certain use cases by
using private content providers or other data stored within your app
or backend systems.
However it doesn't convince me to whether my idea is compliant
Thanks for help!
I believe you may store and use any user actions that had happened within your app.
The purpose of the policy (as stated here: https://support.google.com/googleplay/android-developer/answer/9047303?hl=en) is to prevent apps from getting access to the call-log in order to make use of it for purposes other then what users' expect, that's why the emphasis on critical core functionality of the app.
In my experience, different Google reviewers tend to review the same app very differently, and while one may reject a certain use-case based on this policy, another might approve it.
I would suggest phrasing the screen you want to create in a way that will help the reviewer understand that this data was not acquired from the call-log but some app specific actions, so for example instead of title "Call Log" which might confuse some reviewers with the risk of rejecting this update, you should title it "Recent app actions" or something like that.
I have seen that Play Store Developers received a mail to inform users about the usage of their personal data and to state why and how app's make use of certain features (like writing to the external storage/SD Card). I have to admit, I am new to Android Development and helping out here.
In our existing Play Store App we plan to release a new feature to take photos and thus access the camera for this purpose.
I now wanted to ask how the following requirement has to be implemented:
"Post a privacy policy in both the designated field in the Play Developer Console and from within the Play distributed app itself."
Is it some kind of Readme file, we have to upload or (like Apple does) have to provide a website with those information for the Play Store?
(see http://www.iubenda.com/blog/privacy-policy-for-android-app/ first abstract), whereas other sources just talk about active URLs. Basically, a URL is not always available in an application (consider the case where a user got no internet connection)
How does it have to be presented in the App? Simple Toast, when accessing the Camera the first time or rather a new menu item "Privacy Policy" for the user and display the information in a website with formatted HTML, which we could also use for the PlayStore?
For the overal requirements see:
https://play.google.com/about/privacy-security/personal-sensitive/
This question does not ONLY cover the Google PlayStore but also the best practises for embedding a such IN an Android Application.
I would look at how other Google apps do this to see their (Google's) preferred way of handling this. Most Google apps have a privacy policy menu item in the navigation drawer for basic privacy information, and show a full-screen popup where you have to tap "I agree" for more sensitive topics like location history, for example. This seems like a good approach to me, but you'll have to consult with a lawyer regarding privacy laws/requirements within your home country.
For our implementation it was only concerning two aspects:
1) Camera Access
2) Storing data
I think the reason for Google to request a license Post was and still is to
Developers more aware of how they use possible resources
Users more aware of the usage of THEIR resources
Camera Access
We came up with the solution to not include the camera on our own, but instead performing "the Android way of delegating actions to other applications" and let someone else perform this for us. with the MediaStore.ACTION_IMAGE_CAPTURE. Bit unlucky it is that we had to write a FileProvider to support Androids new Sandboxing feature, as we come to step 2 "Storing Data"
Storing Data
We don't use the external storage anymore for this, instead we use the app's personal storage, as the data is tightly coupled to the rest of the application anyway. Of course, we had to ensure the app is still working if:
1. The user wants to delete specific files
2. The user deletes the app's data in settings
That's it: No Privacy Policy required anymore, as we don't use anything that would require certain permissions :-)
I am currently developing an Android app, and am now approaching the ads part of development.
I am using Firebase for my app, and I need to know what the best approaches are for implementing the following advertising requirements for the respective scenarios (I have never done this before and the wealth of information and approaches is a little overwhelming) :
Scenario 1: Initial release
Initially, the app will be used by students of a single university, and as such we want the adverts to be arranged personally with local businesses, for adverts that will actually be of interest to the students.
What do I have to do in Firebase/AdMob to provide this?
What do the businesses have to do to utilize this after we have made an agreement with them?
Scenario 2: Progressed release
The end-goal is to have this app, in personalized form, for every university that is interested in using it for its students. Each university's app users would receive ads that are relevant to them (ie. a user at MIT wouldn't receive ads about a 20%-off restaurant deal in a South African town)
Again:
What do I have to do in Firebase/AdMob to provide this?
What do the businesses have to do to utilize this after we have made an agreement with them?
And how would I make certain users get certain ads?
Thanks!
Sounds like there are two concerns here.
For the first, if your app already uses location information for its intended functions (and has the location permission turned on), the Mobile Ads SDK will use that info to fetch geographically relevant ads. That happens automatically. Not every ad will be for a local business though--if a national advertiser is the highest bidder for your impression, that's the ad that will be served.
For the second concern (how to do direct deals with local businesses), I'd recommend AdMob's direct-sold campaigns. Once you have regular AdMob ads serving, you can mix in your own campaigns that you directly negotiate with businesses (e.g. "We'll give you 100,000 impressions for XXX dollars" or 10% of traffic, or whatever). Your business would be in charge of entering campaign details and uploading the creatives sent to you by those whom you're advertising.
I ask this question expecting the answer to be 'not possible', as I have attempted to research this already and found no fruit! I thought that I would give the community a chance to weigh in however.
I have a working in-app billing system, but what I want is to be able to provide a little extra bit of infomation with the billing request. Something that would show up in my market place stats.
My users have the option of buying several different levels of product (sort of a Base, Premium and Gold-Star sort of thing). When they purchase the product they provide me with a string that represents the specific thing they want the product about (such as the house number and postcode if the product was about a house).
What I want is to be able to see that extra bit of information in my market place reports, so when I see someone who has requested a refund I can see on what exact item they purchased the product. I have looked at the DEVELOPER_PAYLOAD but I don't think that it will do what I want.
If I can't find a solution this way then I will end up performing a service call and storing the data myself, but I thought I would ask you guys first!
Sorry for being vague about my app and the products it returns but I don't want to expose my app yet (plus it holds no bearing on the question!).
EDIT
Now that I have added a bounty I would like to limit the answers. As I mentioned in my original question my backup plan will me a service call to my system registering the google reference and "data packet" for the purchase.
What I am most interested in is a way to do this where my information would end up in the my market place reports. For instance, if you were to offer a physical item with your in app purchase, how would a user record shipping instructions/etc. There is a place for this in the market reports, so surely there is a way to add the data?
You can certainly use DEVELOPER_PAYLOAD for this. However, Google doesn't process it in anyway and it won't show up in reports (not sure if they store it at all). So what you need to do is send transaction info (the JSON string you receive) to your own sever, parse it and store/process/whatever the developerPayload. You can combine this with signature verification and transaction reporting if you want to. One thing to beware of is that the size is limited to 512 bytes. If you send a request with a longer string, the whole transaction will fail, and the error message is not friendly at all ('IAB-DPTL' or some such).
Of course if you need more that this, you can simply build your own webservice and send whatever data you want. If it includes personal info, etc. make sure you let people know about it and/or they can turn it off.
In order to see this in the report, assuming you have a limited set of "dynamic" data, you would probably have to create a different set of in-app items per each "item" in your game.
Then, of course, you let the game handle which list the user sees according to the "dynamic" data.
That's the only way you would see it in the reports without your own web service handling it.
For those that may find this question via Google!
It seems that the easy answer to my question is NO. You can not add extra information to your market stats with regards to in app purchases.
As I mentioned in my question (and some answers said) the work around would be to upload the transaction string to your server and then compare it to market stats yourself (using the export function from the market perhaps).
I now intend to write a system to extract market stats (likely from the csv download feature) and match it up to the strings from the IAPs. If I ever get around to writing it I will share it with the community.