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?
Related
I have an application that is a device administrator. First, a little disclaimer, our app has an MDM intention (Mobile Device Management), so it is not supposed to be used by end-users.
Since our app is mostly used as a background device manager, I'm testing the new flag that allows your app to not have all permissions reset. I noticed a strange behavior when the device admin is on, and I can't find any documentation about it in Android 11 changes, nor in sdk reference documentation. When your app is device admin, you can't toggle this flag anymore since it's disabled.
If, when I first open my app, asks for device administration and then test the result of context.packageManager.isAutoRevokeWhitelisted (ref) it returns false. But the toggle button in the app settings is disabled, so I can't turn it on.
If I, before asking my app to be device admin, go to app settings and toggle the flag to whitelist our app, then after admin is granted, the toggle is disabled, and this method returns true, which is what I'm looking for.
So my question is: if I turn on device admin for my app, does this means that it will automatically be whitelisted, so I don't need to worry about this (what would explain the toggle disabled, but not explain why the method returns false) or I should first ask for the app to be whitelisted (changing the toggle button in settings) and then ask for device admin?
We have our own rooted hardware device with android OS 7.0
We are building an app for that device. We have to restrict the users to performing some of the actions who will purchase that device. Here are the list of actions We want user to be restricted to perform on the device through the app.
Stop installing/uninstalling any other apps from OS.
On/off wifi
Pair Bluetooth
Change wallpaper
Basic idea behind is to make an app which will be the system app and will restrict user from the things mentioned above.
Is this possible to make such app? Looking for help in any of the above tasks. Thanks
Shor answer: NO.
Here is why;
The Android operation System is based on permissions, and no app can restrict that actions even with the users' permission. The reason for this is because of the Android App Layer that provides all the capabilities you described above.
The only way you can do such thing is to Customize the ROM of the CellPhone. In this case, you can override the functions that allow the user to use such services.
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 am devoloping an app which uses background scanning also. See Using AltBeacon: start and stop scanning from app settings
I have observed a strange behavior. When I am stopping the Bluetooth from the device settings, the app keeps scanning and calling didEnterRegion and didExitRegion. The Bluetooth symbol in the notification bar is gone.
I can also see in logcat the D/BluetoothLeScanner: onScanResult() ... entrys.
How can this be?
We have received a few other reports of this behavior on some devices. The exact cause is unknown, but I suspect that some devices are not accurately reflecting the Bluetooth status in the Android settings UI. It is possible that even when the user disables Bluetooth, if certain apps are already using it, then it remains on despite what the settings UI says.
EDIT: Based on the feedback in comments, it sounds like some Samsung S3 models preserve app-specific access to Bluetooth if it was enabled before or during the time the app was active. Even if you turn Bluetooth off in the system UI, it remains on for all running apps using it, despite what the UI says. Other apps launched after Bluetooth was turned off behave as though it is indeed off.
One way to confirm this would be to put your device into this state, then newly launch the Locate app for Android. This app will present the user with a dialog telling them to turn on Bluetooth if it is off on app launch. This test would give an independent confirmation of whether Bluetooth is really off regardless of what the settings UI is reporting.
In addition to commenting on the results of the above test, it would be very useful to know the device's Modelnumber, Android version, and Build number, all of which are available under Settings -> About Phone.
Full disclosure: I am lead developer on the Android Beacon Library project.
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?