So I have an app generated with GeneXus in the Play Store and I received the following e-mail from the store:
[...] Policy issue: Google Play requires developers to provide a valid privacy policy when the app requests or handles sensitive user or device information. Your app requests sensitive permissions (e.g. camera, microphone, accounts, contacts, or phone) or user data, but does not include a valid privacy policy. [...]
So I went to the Developer Console and found this in the privacy police section (translated from portuguese):
Your app have an APK with the version code 40 thar require these permissions: android.permission.READ_PHONE_STATE. Using these permissions in an APK require a privacy police.
So my question is: What am I using in GeneXus that needs this permission? I get the NetworkId from the ClientInformation object, is it?
Yes, that is precisely the reason. The Android method that obtains the IMEI number (and that GeneXus applications call to obtain it) needs the READ_PHONE_STATE permission to execute. This is understandable, as it's considered private information.
Following Android's Best Practices for Unique Identifiers I would suggest using the ClientInformation.Id property instead. As a bonus, it doesn't persist over device wipes, which in 99% of cases is the intended behavior (unless the app is only installed in controlled devices, which doesn't seem to be the case if it's published in the Play Store).
If you decide to go this route, just remember to reset the Send Device Information on Requests property to false.
(Note: the property name has been/will be changed to Include Network Id in Client Information as of GeneXus 15 U3, since the old name was prone to confusion).
Related
Apps requesting access to the All files access permission without a permitted use will be removed from Google Play, and you won't be able to publish updates.
This is the bit that's unclear, at least to me. So if an app is currently in the Play Store but targets API 29 and has requestLegacyExternalStorage=true, will that app be removed from the Play Store in the future? If so, that's bad. I get that after November for any updates the target API must be 30.
We received this warning what does it means, we use requestLegacyExternalStorage flag and targetsdk 29, so my app will be removed from play? And what changes i need to do for this?
No, your app is not get removed from playstore...
but your app not might work if you targeted API 30 above. "requestLegacyExternalStorage=true" is a temporary solution provided by google to allow developer to smooth transition to new Secure Storage Model.
Many apps that had no legitimate need to read all the files stored on the device’s storage were requesting this permission, causing Google to narrow storage access permissions with Android 11’s “Scoped Storage” changes.
You have two option:
If your app require little to moderate use of storage > Use “Scoped Storage”
If your app is such as File Manager,Anti-virus,etc in which required all storage file access to work effectively and efficiently > Use "All files access"
Further query link_1 , link_2
As per Google Assistant documentation for Smart Home, the agentUserId used in action.devices.QUERY is defined to 'Reflects the unique (and immutable) user ID on the agent's platform. The string is opaque to Google, so if there's an immutable form vs a mutable form on the agent side, use the immutable form (e.g. an account number rather than email)'
However there can be cases where the same device (with same agent user id) is attached to multiple Google Assistant accounts and in such cases a DISCONNECT request may result is ceasing report state for all accounts. The solution will be to add some unique ID corresponding to the Google Assistant account, however such information is not available in any request.
Has anyone seen similar issue and is my understanding incorrect?
The agentUserId is meant to be the user account on the smart home platform. SHP user '1234' may have a vacuum and two lights, but could be linked to multiple Google accounts.
During the account linking process, you would be expected to give a refresh and access tokens to allow for Google to have authorized control over these devices. If you assign unique access tokens for each Google account that signs in, you'd be able to determine which Google account the request is coming from.
At that point, once the user disconnects, you can use the access token in the request header to associate that with a specific Google account and only disable reporting for that account while not affecting other accounts.
So, yes the solution is to have a unique ID connecting to the account. While this is not passed in the agent ID, there is already a mechanism to make this association through the authorization system.
Alternatively, you could append a key in the agentUserId, ie. '1234-user#gmail.com'. However, this may have unintended impacts in the Home Graph. In a multi-user home, you may end up seeing the devices duplicated because Google doesn't have the right information to deduplicate.
I need to know how configure my Xamarin.ios application to acquire a user access permission to send SMS, and where can i find the complete permission list.
There is no way you can send an SMS, the only thing you can do is compose a message is to create a URI like Device.OpenUrl("sms:123456789&body=sometext"); or use the MFMessageComposeViewController.
As far as I know there is no special permission needed for it.
For a complete list of permission and the how and why on iOS 10, read this.
iOS helps prevent apps from accessing a user’s personal information without permission. Additionally, in Settings, users can see which apps they have permitted to access certain information, as well as grant or revoke any future access. This includes access to:
Contacts
Microphone
Calendars
Camera
Reminders
HomeKit
Photos
Health
Motion activity and fitness
Speech recognition
Location Services
Bluetooth sharing
Media Library
Social media accounts, such as Twitter and Facebook
If the user signs in to iCloud, apps are granted access by default to iCloud Drive. Users may control each app’s access under iCloud in Settings. Additionally, iOS provides restrictions that prevent data movement between apps and accounts installed by MDM and those installed by the user.
I want to request the permissions that I need for my android wear app upfront as per this. So Programmatically where exactly I should put my permission request code. Also is the protocol to ask for Permission the same as the mobile app like this.
All of the permissions are controlled in the Androidmanifest. Here is an example of some permissions being declared in the Androidmanifest:
These permissions are used to get the weather from the device and relay the information to an Android Wear device. Google offers documentation for developers to use to determine what permissions should be used. Declaring permissions should happen in the Androidmanifest in the format provided in the image. In the sample code posted, it is not necessary to include watch permissions, they are only required if the app works with Android Wear.
Way back in the day Google added a feature in Android 4.3 that let the user control what permissions apps could access on a per app basis known as App Ops. This was a great feature that cut down on privacy issues and gave users the piece of mind knowing that random apps installed could not access the device’s location. When Google introduced Android 6.0 Marshmallow, This time when an app needs to use a permission a dialog box pops up on the screen and asks the user if it is OK that the app uses a certain permission. This may get a little annoying, but at least every permission used by an app has to go through the user first.
If your app doesn't already have the permission it needs, the app must call one of the [requestPermissions()](https://developer.android.com/reference/android/support/v4/app/ActivityCompat.html#requestPermissions(android.app.Activity, java.lang.String[], int)) methods to request the appropriate permissions. Your app passes the permissions it wants, and also an integer request code that you specify to identify this permission request. This method functions asynchronously: it returns
right away, and after the user responds to the dialog box, the system calls the app's callback method with the results, passing the same request code that the app passed to requestPermissions().
You should dynamically request the permissions from user on wearable devices just the same way you do on the phone side.
I have submitted a windows phone app of PNR status.It failed and error in report says this:
The application cannot be tested for compliance for Windows Phone Application Certification Requirements due to geographic, hardware, and/or software limitation(s).Please provide valid test PNR numbers with resubmission
What should be done for resubmission?
Only PNR numbers should be sent or any other thing to be done?
There is a specific section at .xap submission page, where you can add data for testers, like logins, passwords, etc. The message in your report shows, that testers need additional data to test your app properly (so you don't need to replace your xap file). When you'll add this info, submit app once again.
Also note, that if your app failed submission, there's a button for contacting market tech support, so you can always ask them, what was wrong, if you're not sure.
You can read about different tech.certification requirements here at MSDN
5.1.4 – App testability The app must be testable when it is submitted to Windows Phone Store. If it is not possible to test your app for any
reason, including, but not limited to, the items below, your app may
fail this requirement.
If your app requires credentials, you must include them in the Test
notes or instructions field when submitting your app on the Windows
Phone Dev Center. The credentials must be valid.
Examples of credentials include:
Login credentials. For example, if your app requires a username and
password to access part of the app.
Testing credentials. For example, if your app allows a user to add to
a gift card balance, you must include both login credentials and a
gift card number that can be tested.
If your app accesses a web service, the web service must be functional
and your app must run properly.
If your app interacts with third-party hardware, for example a media
streaming device, you must file a technical exception. For more
information on how to file a technical exception, see the Technical
Exception Request form.
Your app must not require that it is run on a single, specific
cellular network.
Your app must launch.