Develop Reference

What happens in Android if you run code that requires a permission but fail to have it?

I am talking about the quality issue (bug) that an Android app needs a permission that is declared in the Manifest, but fails to request it from the user at the appropriate time and executes the code without the necessary permission. This was not possible in older Android versions (user accepts all permissions in bulk), but seems to be possible when using newer versions that copy Apple in most regards.
At least during testing one can start background services and use bluetooth without any alert by Google popping up. Is that different for apps in production?
Does the app crash with an Exception?
Does the code get executed?
Does the app get rejected in review? (Always?)
Does the app get delisted from the store?
Does it depend on Android's Version?
I deal with an age old app that has bluetooth discovery code to find and connect to dedicated hardware, that is rarely used via a cordova plugin triggered by content. There is old altbeacon code potentially activated that may even need access background location (https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions). It will take some time to get this dead code up to quality. Definitely more time than the week we have.

Does the app crash with an Exception?
yes if you try to have operations depends on returned date witch is null
Does the code get executed?
code will execute with exceptions because data access denied you can check if permission granted or not and add scenario for each state
Does the app get rejected in review? (Always?) not sure but with crashes there is high potential to get rejected
Does the app get delisted from the store?
depends on why and how you are using data
Does it depend on Android's Version?
yes access data and permissions changing point is android oreo

My tests with Bluetooth permissions revealed the following: Required permissions are BLUETOOTH_ADMIN, BLUETOOTH and for VERSION_CODES.Q additionally Manifest.permission.ACCESS_BACKGROUND_LOCATION (see: https://developer.android.com/guide/topics/connectivity/bluetooth#Permissions).
BLUETOOTH_ADMIN, BLUETOOTH do not show any system alert-dialogue to the user. In Android Q+ if you fail to check for the required ACCESS_BACKGROUND_LOCATION permission, nothing happens and your code executes without exception (mine did execute an UART command on hardware with Samsung tablet). The app passed review although the check is missing (of course I will fix that ASAP).
Note: the doc is ambiguous and states: "Services running on Android 10 and higher cannot discover Bluetooth devices unless they have the ACCESS_BACKGROUND_LOCATION permission." Probably general scanning while the app is active could be allowed. In that case missing exception would be explained.

Missing Google Services permissions in logcat

We have a weather app for Android that also provides a widget.
The widget displays the current time and weather for the current user location.
We update the widget clock every minute (via AlarmManager) if the display is active, the weather data at longer intervals. Sometimes the widget "freezes". We were able to track that down to the alarm for the next check not being set but don't have a clue why, yet.
Now we noticed the following warning in the device logs of an affected device:
03-12 10:15:44.803 771 4958 W ActivityManager: Permission Denial: opening provider com.google.android.gsf.gservices.GservicesProvider from ProcessRecord{41a4d028 25012:com.my.app/u0a88} (pid=25012, uid=10088) requires com.google.android.providers.gsf.permission.READ_GSERVICES or com.google.android.providers.gsf.permission.WRITE_GSERVICES
This starts to appear exactly at the time where the clock should have been updated. The message is then repeated several times until the ActivityManager terminates the process.
We use the Google Play Location Services to get the current (or last known) location of the user. I found references to a bug in version 4.2 of the services (here and https://stackoverflow.com/questions/22682538/when-to-use-read-gservices-permission) that could cause this error, but the device has version 6.7.76 installed.
One more thing to consider is that the device is running Cyanogenmod, though the stuck widget problem also happens on devices with "regular" Android.
Any hints what could cause this permission error are very much appreciated. Thanks!
Edit: The widget and app work fine on that and many other devices until the warning appears. Also the Google documentation is not mentioning that you need to get those permissions. In fact the only mention of those is here in this document according to the on site search, but no mention of READ_GSERVICES on the page itself.

The two permissions it is asking for:
<uses-permission android:name="com.google.android.providers.gsf.permisson.READ_GSERVICES"/>
<uses-permission android:name="com.google.android.providers.gsf.permission.WRITE_GSERVICES"/>
Something to remember just because this issue was reported in Google Play Location Services in 4.2 does not mean it has been fixed. It may be worth looking through the Google bug reported to see if anyone has any issues. I found a few issues raised running much newer Google Play Services.
Upon doing a quick Google search myself it seems like the major problem phones are the Moto X and the Nexus 5. Which is rather interesting as they are both Android Open Source Project bugs (i.e phones running stock Android with no skin!)
Just a few questions:
Can you confirm what phone you have and which version of Android you
are running please?
Also what is your target SDK?
What version of play services are included in your APK?

Android Call Blocker Code for Android 3.0 and above

I googled for an example source code for blocking calls and came across this EXAMPLE, But later I came to know that Google has updated their policy and
android.permission.MODIFY_PHONE_STATE
is an system level permission from android version 2.3, I have very important module placed on blocking a specific call.
How do I get a system level permission?
Please let me know if there is any way I can do this in my application. Its very important for the product and cannot be released without this functionality.
Please Help!
Thanks in advance

At least as of Android 5.0, MODIFY_PHONE_STATE has the following definition:
<permission android:name="android.permission.MODIFY_PHONE_STATE"
android:permissionGroup="android.permission-group.PHONE_CALLS"
android:protectionLevel="signature|system"
android:label="#string/permlab_modifyPhoneState"
android:description="#string/permdesc_modifyPhoneState" />
Your app can only hold this permission and use it to modify the phone state if it is signed by the firmware's signing key (the "your own custom ROM" scenario from Marcin's comment) or if your app is installed on the system partition. The latter can be accomplished by having your app pre-installed on the device (or having a rooted device user move your app to the system partition, as I understand it).

Device Policy Manager - Reset Password - Android 3.0 Problems

I am using Device Policy Manager in my Android App and I have a problem with Honeycomb devices. When attempting to call resetPassword I get an exception thrown. This is not the case in Froyo or Gingerbread, as both of those work fine.
The error is:
java.lang.RuntimeException: Unable to start receiver Package.Name.Test: java.lang.SecurityException: Permission Denial: writing com.android.providers.settings.SettingsProvider uri content://settings/secure from pid=x, uid=y requires android.permission.WRITE_SETTINGS
My Android Code is as follows:
DevicePolicyManager mDPM = (DevicePolicyManager) context.getSystemService(Context.DEVICE_POLICY_SERVICE);
if ((mDPM.getActiveAdmins() != null) && (mDPM.isAdminActive(new ComponentName(context, DeviceAdmin.class)))) {
mDPM.resetPassword(extra, DevicePolicyManager.RESET_PASSWORD_REQUIRE_ENTRY);
mDPM.lockNow();
} else {
Log.d(TAG, "Could not lock because device admin not enabled");
}
The problem occurs at:
mDPM.resetPassword(extra, DevicePolicyManager.RESET_PASSWORD_REQUIRE_ENTRY);
My Device_Admin.xml is:
<device-admin xmlns:android="http://schemas.android.com/apk/res/android">
<uses-policies>
<force-lock />
<wipe-data />
<reset-password />
</uses-policies>
</device-admin>
Like I said the device admin works great on Froyo and Gingerbread devices, although I do have some problems with users using different keyguards, an example is the Droid X and HTC Sense. This problem is with timing. When I call lockNow the device will turn off the screen but HTC Sense or MotoBlur will not actually lock the keyguard until the time that was set in Settings, Security, Lock Phone After.
Any help would be awesome! I just recently got a honeycomb tablet at I/O and haven't tested the app out on this device yet, but I see the errors on the market website with users with the Xoom running 3.0. Have not seen any 3.1 devices yet.

I struggled with this also. The solution is also listed on one of your links, but I'll mention it here also in case it helps someone else.
If the device is brand new (or factory reset) the code fails as you describe.
If the user enters a password using the settings menu just once, somehow the same code starts working and keeps on working.
A very weird bug indeed!!

On Android Honeycomb 3.0 platform, the DevicePolicyServiceManager is very different from Gingerbread, the whole flow of resetPassword() is:
DevicePolicyServiceManager.resetPassword() -->
LockPatternUtils.checkPasswordInHistory() -->
LockPatternUtils.passwordToHash() -->
LockPatternUtils.getSalt() -->
LockPatternUtils.putLong(SALT_KEY, salt) -->
Settings.Secure.putLong(SALT_KEY, salt)
Here you should know why WRITE_SETTINGS is required, it seems that this is Google's mistake, they did not put the LockPatternUtils.checkPasswordInHistory() method in Binder.clearCallingIndentity() block.
One more thing, even if you add WRITE_SETTINGS permission in your AndroidManifest.xml file, it will tell you that WRTITE_SECURE_SETTINGS permission is also required.
Hope Google can fix this issue ASAP.
P.S. It seems that this issue has been fixed on ICS platform, Google has removed the checkPasswordInHistory() from resetPassword() block. I do not think this is a good solutoin and i don't know why? Maybe they wanna release ICS as soon as possible?

I also faced this problem, what i can tell is if you didn't set the password manually even single time, the it will give force close asking for write_settings permission but if you try once by setting password manually from there on-wards it will work like charm.

I was looking at this problem (which is readily reproducible on 3.1 as well, btw), but it appears that you already figured it out, based upon the issue you filed. I just wanted to note that here in case anyone else tried to research the answer.

Android permissions: Phone Calls: read phone state and identity

My android app has nothing to do with phone calls, but I'm seeing that when I install a debug build on my test device it requires "Phone Calls: read phone state and identity" permissions. (I make no mention of this in AndroidManifest.xml).
I'd like to have the minimum possible permissions, and wondered if anyone knew how to get rid of this? I commented out the part where I was logging some stuff from Build.MODEL, Build.VERSION.*, etc. I also commented out the part where I was detecting the landscape/portrait orientation thinking that that might be the "phone state". But neither of those seemed to remove that permission required.
I found this bug report: http://code.google.com/p/android/issues/detail?id=4101 but it's marked working-as-intended with a note about permissions being correct from the market but not otherwise. Is this other people's experience? (I'd hate to have to publish to the market just to test that out.) Otherwise, does anyone know if there's an API I can avoid calling that will make it so my app doesn't need this permission?
Thanks!

(Answering my own question in case anyone else runs into this problem and searches for it.)
Digging around in PackageParser.java in the android source, I found out that the system will automatically assign
android.permission.WRITE_EXTERNAL_STORAGE and
android.permission.READ_PHONE_STATE
to any app that declares a targetSdk version of less than 4 (donut). There must be a compatibility reason for this, maybe apps targeting older versions could assume they had these permissions without declaring them explicitly. So, if you don't want these permissions added to your app implicitly, add a section like the following in AndroidManifest.xml
<uses-sdk android:minSdkVersion="4" android:targetSdkVersion="4" />
That is all.
Have fun, -Mike

Android 1.6 changelog: http://developer.android.com/sdk/android-1.6.html#api
WRITE_EXTERNAL_STORAGE: Allows an
application to write to external
storage. Applications using API Level
3 and lower will be implicitly granted
this permission (and this will be
visible to the user); Applications
using API Level 4 or higher must
explicitly request this permission.
But that is only one of them. For some reason the official change log is missing the info about READ_PHONE_STATE. The full story is cleared up here: http://blogs.zdnet.com/Burnette/?p=1369&page=3
New permissions. 1.6 programs must
explicitly request the
WRITE_EXTERNAL_STORAGE permission to
be able to modify the contents of the
SD card, and they must explicitly
request the READ_PHONE_STATE
permission to be able to be able to
retrieve phone state info. Apps
targeting earlier versions will always
request these permissions implicitly.
So as you can see, there is no way to publish an app targeted at 1.5 or earlier without requesting those permissions when installed on phones running 1.6 or higher.