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.
Your app may face additional enforcement actions, if you do not resolve this issue by February 21, 2023.
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)
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)
Open Google Play Console
App content
Data safety => Manage
Overview click next
Answer the questions (then next):
Does your app collect or share any of the required user data types?
= yes
Is all of the user data collected by your app encrypted in transit? = yes
Do you provide a way for users to request that their data is deleted? = yes
go to Device or other IDs and check it then next
check Device or other IDs and manage it
answer the questions:
Is this data collected, shared, or both? = Collected
Is this data processed ephemerally? = yes
Is this data required for your app, or can users choose whether it's collected? = Users can choose whether this data is collected
Why is this user data collected? = check App functionality
then save
click next and save and app will review and approved by play store
team
I solved my own problem in this way. You also can try this. it should be work if your is:
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
I am planning to make a locator app in android java language. What I want to know is, how can I connect multiple accounts to the main/admin account so that I can track them? I want to have the options of adding the other accounts through sending digit codes to the email address and phone number.
I want to know what specific classes, libraries or any other ways needed for that.
Thank you....
If you're using Firebase's Firestore then simply add the user's Uid to admins document in a String array considering that you have a structure like Users (collection) > Uid (document).
Similarly, every user should have a unique code that can be sent from admin to the user that has to be added and a mechanism to prevent unknown users from getting added to admins location array.
Background
In the "Phone" app of Google, there is an option "Caller ID & spam" :
So, if you get a call from someone or some organization that isn't on the address book, yet it is identified somehow, you get a name for it, as such (called "+972-035283487") :
Ever since Android M (6.0 - API 23) , apps can replace the default phone app, and then also providing alternative UI when you call someone or get a phone call, by extending InCallService class, as demonstrated here which is based on here.
The problem
I want to try to show the same information as on the Phone app, meaning the name of the person/company in case it identified it (and it's not on the address book).
What I've tried
I tried to dig over the various things that I get via the API of the dialer, but failed:
Various fields and functions of: android.telecom.Call class
There is getDetails inside of the Call class, so I tried to get what's inside there, and there is also statusHints and "label" inside the "statusHints" . None of those had any information (returned null). The reason I tried to look at "statusHints" is because that's what I see on the docs :
Contains status label and icon displayed in the in-call UI.
On the "Phone" app, pressing "Learn more" goes to a website (here) full of links that I think might be sources of the data, but I don't think the app itself uses this. Instead I think it uses something of Google.
The questions
Is it possible to get this CallerId information? If so, how?
How does the Phone app do it? It's supposed to be open sourced, so there has to be something that gives it this information, right? Would cloning it somehow get this information? Maybe Google has its own service for CallerID?
What are the "callDetails" and "statusHints" used for? What do they provide?
I believe Android's native phone app is using Google's place search API. As you can easily search for a place by its phone number and get place details like name, place id, formatted_address and many other fields that you can find in the documentation
Request URL:
https://maps.googleapis.com/maps/api/place/findplacefromtext/json
Request method: GET
Request query parameters:
key: Your application's API key.
input: The text input specifying which place to search for (for example a name or phone number).
inputtype: The type of input. This can be
one of either textquery or phonenumber. Phone numbers must be in
international format (prefixed by a plus sign ("+"), followed by the
country code, then the phone number itself).
Example request:
https://maps.googleapis.com/maps/api/place/findplacefromtext/json?input=%2B972035283487&inputtype=phonenumber&fields=place_id,name&key=API_KEY_HERE
Example response:
{
"candidates" : [
{
"name" : "מלך העופות",
"place_id" : "ChIJ78ko1zBKHRURpwbgUdWc4nU"
},
{
"name" : "Of Yaakov",
"place_id" : "ChIJv3myn4FMHRURUGffcXgxKuw"
}
],
"status" : "OK"
}
Note:
Such an API is not available at the current moment in Google places SDK for Android, but you can use the HTTP API directly in your app or you can make an API in the backend as a proxy to the places API. I prefer the later version as in the first solution the API key is deployed in the application code and hackers could decompile the APK and use it for malicious reasons. For security reasons you have to restrict the usage of the API key to the IP address of the server in case you are using the backend solution!
I tried to decompile the Dialer app, couldn't find the specific info about how the app is doing it.
But this info could be useful. Please check it.
In Dialer app, there are classes SpamCallDatabase_Impl.smali SpamCallDatabase.smali
and there is service running in package com.google.android.gms app, which provides spam lists
com.google.android.gms/.telephonyspam.sync.SpamListSyncTaskService
and for caller id check this commit
https://gitlab.e.foundation/e/os/android_packages_apps_Dialer/commit/420eb901ed1d64fdaf055cde4cc46d7a5c0b42fc
This looks dialer app of lineage os
and it uses different services for phone num lookup like
https://auskunft.at/
https://www.dastelefonbuch.de/
I believe Google has its own database of spam callers, and the Phone app sends the number to its server, and if there is a match, it shows the name.
Maybe, if your app can read notifications, there is a possibility to retrieve that name. Try this example out and modify it according to your needs
You could check the working of apps like Truecaller for this. Truecaller acts on a give and take scenario... You want those unknown numbers then you have to part with your phone book contacts.. Now apparently everyone who has installed the app has surrendered his phone book. The data is crowd-sourced from the millions of users who have downloaded the truecaller app on their smart phones. As part of the end user agreement, the truecaller app asks the user to allow access to the user's address book/contacts on the smart phone. This data is then uploaded by the app to the company's servers. After going through several data matching/refining algorithms, this data is made available to all truecaller users to search upon.
Google Phone app is provided a feature of Use caller ID & spam protection by default. Some of these steps work only on Android 6.0 and up.
When you make or get a call with caller ID and spam protection on, you can see information about callers or businesses not in your contacts or warnings about potential spam callers.
To use caller ID and spam protection, your phone may need to send information about your calls to Google.
Turn caller ID & spam protection off or back on
Caller ID and spam protection is on by default. You can choose to turn it off.
To use caller ID and spam protection, your phone may need to send information about your calls to Google. It doesn’t control whether your number shows when you make calls.
Caller ID by Google shows the names of companies and services with a Google My Business listing. It also looks for matches in any directory that shows caller information for work or school accounts.
As per your solution, Google does not provide this kind of support as you want. you need to create your own function and save spam and other contact detail at your side.
I have been working on this project for months and I am getting desperate.
I have done research and relied on papers that talked about the user-provider-uddi architecture, so my purpose was the following:
through a mobile app, the user would write a keyword of needed web services, the query and the user's and device profile would both be sent to a middleware. Now the middleware is supposed to get a list of services of the same category as the keyword and compare the web services information to the user and device profile.
For example: it will check the required cpu, memory, screen size, language, location where it works and type of display (graphic/text) and compare it to the device specifications and user's preferences to select the best services.
Now my problem is:
I can't find any public repository (all those mentioned in other posts do not exist anymore)
assuming that I can use an interface (such as JAXR) to get services by category, how can I get the context-related information about services (cpu/memory requirements, language, location, display etc...). would that be possible through JAXR ? Is there a document that describes this about Web services (just like wsdl describe functions?)
what is the common was used to search for web services from a mobile nowadays ?
I know the question is somehow general, but I really worked a lot on this and I'm stuck. If there are people who specialize in the domain, please let me know your opinion. I would like some practical answers that can be implemented.
There are still a few public repositories out there (e.g., Service Repository). It is true that most of the web services you will find are not available anymore, but you can create your own service repository and deploy it either locally or somewhere in the cloud. It is basically just a hash map (service id mapped to a service uri?) and you can use any database to store the data.
Context information usually comes in different types. You have user context, service context, system context, environment context. Usually this information is embedded in the service response messages to the service consumer. Anything that can store data can be used to store this context. It's basically just data. Also, it can be collected when the request comes, but it will introduce a certain delay when serving the request. A proactive approach should be considered here.
This is very general. Depends on the type of service you're interested in. I believe the common approach to query a cloud based registry is the standard.
I have inherited an app which comes as a free version, and Pro monthly subscription is bought via in-app items. The Pro status (a simple string "pro_status") is saved inside the AccountManager (package android.accounts).
//AccountManager initiated
AccountManager mAccountManager = AccountManager.get(this);
//fetch accounts which correspond to our package name
Account[] accounts = mAccountManager.getAccountsByType(getString(R.string.account_type));
//save Pro status inside the AccountManager
mAccountManager.setUserData(mAccount, "is_pro", "" + info.isPro());
The app suffers from a strange bug that it forgets the Pro state randomly, either when you close the app or during the work.
Is this a good way to store Pro status? Could AccountManager be the reason why the app loses the idea of a Pro status?
I usually use either a database or SharedPreferences to store such data (besides storing it on the remote API), so I need a help from someone who used his app in the same way.
Usually the people playing with the setting "pro" status will be the one with rooted devices. Anyways the data stored in the account manager is visible to such users.
So, for such a use case, even account manager is not safe. Though other apps (with different UID) cannot access this data.
Also keep in mind that the user can delete the account from the settings which might be the reason for your settings going away.
My advice would be save this info in shared pref in encrypted form??
In all phones,there is a specific User Database which stores information regarding your accounts.
Is this a good way to store Pro status?
I cannot answer that however I can give you answer to related questions
Is it modifiable?
There are 2 ways of accessing this data, viz
The user explicitly gives permission to an application to read
account details for that particular account. This list of apps
which can access the details for this account are stored based on
PIDs,which cannot be same for different apps. check setUserData
and AUTHENTICATE_ACCOUNTS permission
This database can be accessed(and modified ) on a rooted device.
Can a user manually delete this data?
-Yes,He can delete the account from the device itself.It is his device and he can modify any account details on it too.
In my experiece,the Acccount Manager API is very temperamental, and prone to change which can break your code if it is not used in the way that it was intended to be i.e. store User Account details in centralised database.
You should look into the approach and comments(but not the answer) of this question
.
I agree with the shared preferences approach too.
In one of my App, I would like to give a feature as a trial for only 20 attempts. Once the user wants to access the feature for the 21st attempt, he/she will be prompted for in-App purchase.
My question is how can I make this variable persistent so that even if the user uninstalls the app and re-installs, the counter does not reset and takes the last value before the uninstall.
Please help.
The easiest way is to use Backup API and backup your data online. It is very easy to use and here is tutorial:
http://developer.android.com/training/cloudsync/backupapi.html
The disadvantage of this method is that user can disable backups in phone's settings.
Another method requires you to send data to server. I would suggest to use parse.com since it does not require you to write any server code, they have very easy-to-use library for Android and their free plan is very generous. Here is a little tutorial:
https://parse.com/tutorials/get-started-with-android
You can send some sort of unique id (device or account specific) and counter to the cloud every time user triggers your trial feature. Also you can query your counter from the cloud when application launches the first time.
To create that unique id you can approach with few methods:
Try to obtain 64-bit unique number, which is generated when device first boots:
String androidID = Secure.getString(getContext().getContentResolver(), Secure.ANDROID_ID);
Note that it was reported that for some device this value might be null. You can verify your androidID variable and if it is null, you can try another method that will allow you to access user's primary e-mail (you probably want to hash it prior to sending it your server).
Also make sure to add android.permission.GET_ACCOUNTS permissions to your manifest file:
final Account[] accounts = AccountManager.get(context).getAccounts();
for (final Account account : accounts) {
if (Patterns.EMAIL_ADDRESS.matcher(account.name).matches()) {
final String email = account.name;
// hash email and use it
}
}
if email cannot be obtained - you might also want to try to get device id from telephony manager:
// For CDMA phone getDeviceId() is equal to value request for Secure.ANDROID_ID
final TelephonyManager telMgr = (TelephonyManager)getBaseContext().getSystemService(Context.TELEPHONY_SERVICE);
final String deviceId = telMgr.getDeviceId();
(don't forget to add android.permission.READ_PHONE_STATE permission to your manifest)
Hope that it gave you enough information to add trial functionality into your code.
Also if your in-app purchase is actually a subscription, then Google already implemented trial functionality for you:
http://developer.android.com/google/play/billing/billing_subscriptions.html
(search for free trial)
You have no way of maintaining anything locally for the user if they uninstall or reinstall the application.
If you need the uninstall/re-install requirement, this is counter that will need to be logged on your back-end rather than on the device. You can do this by storing the device's id on your server and incrementing your ticker when appropriate.
I simply define a serializable Expiration object that I store to SD with a dot in front of it to make it hidden.
The object contains time of creation and other metadata.
When the app starts, it checks whether Expiration exists, if not it is create. This way I always know the exact time when the app was installed, despite uninstall/reinstalls.
The downside to this method is that it requires some sort of external storage as we want to go outside of the standard app folder of the internal storage, which is wiped upon uninstall.
To circumvent this, you could look for some way of getting/giving a device a unique id, that remains the same after reinstall, and upload the data to a server. This has the benefit that the user cannot reset the expiration by wiping the SD either.