I'm in the middle of building a Wear App for an existing phone app.
We plan on targeting API 23 and modifying our phone app's location permissions to work with Android new runtime permission model (https://developer.android.com/training/permissions/index.html)
I was trying to figure out how the Wearable device running Android 5.0 is going to work once we do that. From what I've learnt when asking for locations for the Wearable from https://developer.android.com/training/articles/wear-location-detection.html:
The wearable may or may not have a GPS radio present. For wearables that do not have a radio, the location data comes from the tethered device.
We don’t need to worry about the source of location data – FusedLocationProvider (as part of the Google Play Service) handles this for you behind the scene.
We are responsible for handling the edge case where the wearable does not have GPS hardware (can be checked via hasSystemFeature()) and if the tethering is interrupted (can be detected via WearableListenerService). An example of this would be when the user goes for a run without the phone. In this case, we are expected to degrade the functionality gracefully.
What’s puzzling me is how this will work when we migrate to the new Marshmallow permission model.
Android Wear is not affected if the hardware has on board GPS since no wear devices run Android 6.0 and the old permission model applies. The problem would come about if a wear device with no GPS hardware is tethered to a device running Android 6.0. In this case, if the wear device requests for the location, it would passed on to the phone and the user has not been asked permission/or has disabled the permission, how will this work at all?
I'm imagining that need to hack around this:
On wearable app start, first check if the hardware has a GPS radio
If no, send a message to the phone to ask if holds the permission for requesting location (use the data sync APIs for this)
If the answer comes back false, then show a message to the user on the wearable and ask if they want to resolve it on the phone.
If the user answers “yes”, push a message to the phone to show an activity where it would just prompt for permission.
Is there a better way to do this?
Related
Some surveys and analytics showed that users very often turn down Location Permission request appearing in the mobile app even if this permission is crucial for the app, e.g. the app performs automatic scan for devices in a venue that handle business logic and exchange data with the mobile app. The permission request turn down rate is so high that it becomes problematic for business. Is there any way in Android to avoid this, e.g. to declare some verified devices that can be scanned without permission request? I thought of https://developer.android.com/guide/topics/connectivity/companion-device-pairing but it also means popping up requests for manual work for the user. Is there any way today to do it behind the scenes?
Unfortunately this is not possible for privacy and security reasons. Enabling BLE on Android devices goes hand in hand with the location permission. The only possible workaround for this is potentially if you use classic Bluetooth instead of BLE. I am not 100% sure about this one, but it is mentioned in this article:-
No one can use BLE scan API without having Location Permissions, and,
on most devices, it is useless without active Location Services.
However, Bluetooth Low Energy is an extension to so-called Bluetooth
Classic and interestingly enough Google decided this API does not need
location permissions to be called.
This is an OS requirement which cannot be overcome. You might've already seen this on the Android developer page for BLE:-
In order to use Bluetooth features in your application, you must
declare two permissions. The first of these is BLUETOOTH. You need
this permission to perform any Bluetooth communication, such as
requesting a connection, accepting a connection, and transferring
data.
The other permission that you must declare is ACCESS_FINE_LOCATION.
Your app needs this permission because a Bluetooth scan can be used to
gather information about the location of the user. This information
may come from the user's own devices, as well as Bluetooth beacons in
use at locations such as shops and transit facilities.
You can find more info about this here:-
The Ultimate Guide to Android BLE Development
Location needs to be enabled for BLE on Android
Bluetooth versus Location Permission
I have developed a Referee Watch (https://play.google.com/store/apps/details?id=com.pipperpublishing.soccerrefpro) which tracks referees field coverage and other fitness stats using the watch GPS. This is NOT a question about ACCESS_FINE_LOCATION permissions which I am handling just fine.
I understand I can use getPackageManager().hasSystemFeature(PackageManager.FEATURE_LOCATION_GPSto determine if the Watch has GPS. However, if a user accidentally turns OFF Settings>Location on the Watch, is there a way of detecting it? I suspect the watch will report TRUE for the above call, but then attempt to deliver location using the Fused Location Provider from the phone wifi/gps/cell. That of course is useless once you are running on the field with the phone in the bag.
I have tried looking at the Fitness Sensor sources and determining whether the source is Local or not, but that doesn't seem to work.
If you've already determined whether your Android Wear device has a built-in GPS sensor using the hasSystemFeature() method, then you can proceed with handling disconnection events.
You may want to implement onPeerDisconnected() method so that your app should be able to handle loss of location data in case the wear device loses connection with its paired device.
Also, check this SO post for additonal insights on how to trigger a system UI to get that permission to enable location dialog.
As I got notification from google about the ACCESS_FINE_LOCATION permissions. As I understand if we don't add "android.hardware.location.gps" uses-feature to your manifest it will visible to non GPS hardware device also.
If I add that my application wont display to them and I don't want to do that.
I want to check that how app is reacting on device that not having GPS Hardware. How can I create simulator for this?
Actual message from Google Play Store
Action required: If your app requires GPS hardware to operate properly, you will need to explicitly add the "android.hardware.location.gps" uses-feature to your manifest.
What’s changing
We’re making a change on October 15th, 2016 that will affect apps targeting API version 21 (Android 5.0, Lollipop) or higher that use ACCESS_FINE_LOCATION but don't explicitly have the "android.hardware.location.gps" uses-feature. Going forward, these apps will be available to install on devices that don't have GPS hardware. In most cases this won't be an issue since Wi-Fi and Cell-ID based location provides high enough fidelity for the typical operation of these apps. However, any apps that require GPS hardware, such as GPS navigators, should explicitly add the "android.hardware.location.gps" uses-feature to their manifest.
If your app requires GPS to function properly and you do not include android.hardware.location.gps in your manifest declaration, your users may have a poor app experience.
Read More about this change here
You can try this on the real device. For example, Lenovo A369i doesn't have GPS Hardware. If you don't have real device without GPS you can create corresponding virtual device. Go to Android Virtual Device Manager -> Create Virtual Device -> New Hardware Profile. There you can find GPS checkbox, so you should switch off it and you will create device without GPS.
I have noticed in Android 6.0 that if you try to disable the permission for PHONE on the stock Phone app, the Settings app informs you that you are disabling a critical function. If this is disabled, "the basic features of your device may no longer function as intended". But, If you try to disable the permission for LOCATION on the phone app, the Settings app does nothing. What is the mechanism that the phone app uses to distinguish a critical function from a non-critical function?
I am asking a follow up question to my previously asked question -> http://stackoverflow.com/questions/33607410/background-monitoring-of-eddystone-beacon-using-altbeacon-library-on-android-pla/33613116?noredirect=1#comment55139316_33613116.
Where i was able to successfully detect beacons both in the foreground and background until I found out that the same code was unable to detect the beacon when i try to run it on nexus 5 device running android 6.0.
Can anyone provide a explanation to why this is happening? Thanks.
Android 6.0 imposes two new requirements in order for apps to detect BLE Beacons:
Location Services must be turned on in settings. Settings -> Location -> On. The specific mode may be either "High Accuracy" or "Device Saving". This is a new requirement that appears to be being rolled out to all firmware builds from Google. Without this on, BLE scans discover no devices.
The app must be given runtime permissions by the user to ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. You must code your app to present one of these permission requests to the user. If not granted, the app will not be able to detect BLE Beacons.
A detailed explanation of this process is in my blog post here: Is Your Beacon App Ready For Android 6.0?
With Android 6.0, you now need to request location permissions at runtime in order to be able to discover beacons.
From our initial tests: if your app targets SDK < 23 (i.e., pre-Android 6.0), you will only need these permissions to detect beacons in the background. If your app targets SDK >= 23 (i.e., Android 6.0 or later), you will need these permissions to detect beacons both in the background and in the foreground. You also need to have Location enabled on your Android 6.0 device for both cases.
Google has a detailed guide on how to implement checking for and requesting runtime permissions:
http://developer.android.com/training/permissions/requesting.html
Specifically, you need either ACCESS_FINE_LOCATION or ACCESS_COARSE_LOCATION. They both actually display the same message ("Allow APP_NAME to access your location?") to the user.