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.
Related
I have developed an app that synchronises our users' Google contacts with the School's database. When I submitted the consent screen for verification I was asked to change the display name, as it violated branding policies by including GMail in the title. However when I try to update the consent screen in the API Console, after changing the app name the Save button remains greyed out, so I can't change it. How do proceed now?
Note the app is currently in use with an unverified consent screen, but new users are now unable to sign up since Google appear to have tightened their policies.
Also the app is only used by members of our organisation, so it should really be an internal app. However the Make Internal link is deactivated, apparently because I am not a G Suite User. However we have a G Suite for Education account, so does this not make me a G Suite user?
As no-one has provided a solution it looks like there is none. Therefore I’ve resorted to my plan B, which is to create a new API Project and consent screen, This time I created it as an internal project, which avoids any complications of validation. The previous project was created public as it was envisaged that parents with private Gmail accounts might also use it. However with the constraints of GDPR it has been decided to restrict it to employees only. Fortunately I have found a way for existing users to continue using the old version, while new users have to register using the new consent screen.
It appears that the message about not being able to change to a local project if you’re not a G Suite user is a red herring. I suspect you just can’t change project type once it’s in use, because of the possible implications for existing users,
I am using the Android Management API to get runtime permission android.permission.SYSTEM_ALERT_WINDOW. The app is going to be installed on fully managed devices. The policy has the below permissions defined:-
defaultPermissionPolicy: "GRANT"
I have added this to the application section of the policy as well. However, the app does not obtain these permissions and the user has to manually go to the settings and enable this permission. I understand that this permission is rated as advanced level permission, but this is a fully managed device.
Android Management API defaultPermissionPolicy can only grant/deny runtime permission requests. For example, READ_CONTACTS, WRITE_CONTACTS, ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION and etc.
SYSTEM_ALERT_WINDOW is a special permission. This permission doesn't behave like a dangerous or normal permission. This is a sensitive permission that needs user authorization.
For more information you may refer to this link.
I had the same problem with AE. The solution was set targetSdkVersion to 19 in your app.
To fully benefit from android.permission.SYSTEM_ALERT_WINDOW, it's usually necessary to request also Draw over other apps which is special permission that the user must grant manually per app. It's nicely described here.
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).
We've migrated our app from the old marketplace to the new one. After a few days we've received an email that we don't comply with an SSO policy - the user is not recognized after he installs the application.
In the old app we had a specific setup link, that was opened for the user after he installed the app - thus making him recognizable. Is there such a function in the market? Is there some sort of a callback for the installation event in the new marketplace?
P.S. the guy from Google told me to post technical questions on Stackoverflow and that "Our developer relations team monitors that forum and will be able to assist you."
EDIT:
There's the Additional app setup link in this after-installation popup (which clearly no user will click):
Is there a way to call the URL that of the Additional app setup in the background, without needing the user to click an obscure link?
That was an intentional design change which is different than how it used to work in v1 of the marketplace.
If you need interactive setup, best thing to do is put in a check on login to see if the domain has been configured. You can use the licensing API to check for a marketplace install record or directory API to check user permissions if those matter for your use case.
If you just need to run a background task, you can periodically poll the licensing API to detect new installations of the app. This shouldn't be done too often, so if you need to do things before a user logs you're still better off going with a check on login to route them to the setup flow as needed.
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.