Obsolete
Status Update
No update yet.
Comments
qu...@gmail.com
Here is some other weird problem that I encountered after playing around with this bug, (Note, this issue seems to affect the APIDemos app as well)
I preformed the testing on the Honeycomb 3.0 and 3.1 emulator as well as my Galaxy Tab 10.1 from I/O
After encountering the problem I swapped my Device_Admin.xml to include <limit-password />
I then set a minimum password requirement of 0 before manually setting the password through mDPM.resetPassword("1234", 0);
I then encountered no issue and device reset the password to 1234 and relocked.
The problem with this 'workaround' is that my current users would need to download the update, disable the current device administrator, and then reenable device administrator with the new set of rules. This obviously will not work.
Going back to my testing...
I then set my Device_Admin.xml back to the original shown in the first post.
As well as removing the workaround code of limiting the password to 0 length
I continued by disabling the current device administrator for my app
uninstalling the app
rebooting the device
and finally reinstalled the app
Now all of a sudden I can run the mDPM.resetPassword("1234", 0) without the any errors.
This is a weird issue and the only way to further investigate the problem on my galaxy tab is to reset it (i believe) but I can still work on it with the honeycomb emulator (painfully slow)
Thanks again for any help!
I preformed the testing on the Honeycomb 3.0 and 3.1 emulator as well as my Galaxy Tab 10.1 from I/O
After encountering the problem I swapped my Device_Admin.xml to include <limit-password />
I then set a minimum password requirement of 0 before manually setting the password through mDPM.resetPassword("1234", 0);
I then encountered no issue and device reset the password to 1234 and relocked.
The problem with this 'workaround' is that my current users would need to download the update, disable the current device administrator, and then reenable device administrator with the new set of rules. This obviously will not work.
Going back to my testing...
I then set my Device_Admin.xml back to the original shown in the first post.
As well as removing the workaround code of limiting the password to 0 length
I continued by disabling the current device administrator for my app
uninstalling the app
rebooting the device
and finally reinstalled the app
Now all of a sudden I can run the mDPM.resetPassword("1234", 0) without the any errors.
This is a weird issue and the only way to further investigate the problem on my galaxy tab is to reset it (i believe) but I can still work on it with the honeycomb emulator (painfully slow)
Thanks again for any help!
st...@android.com
Hello.
Regarding the first problem, I have examined the code path and I don't believe that the WRITE_SETTINGS permission should be required at all by the resetPassword operation.
Here's a clue: In the log line you provided, it refers to your own code:
>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
By any chance are you trying to do something in your implementation of DeviceAdminReceiver.onPasswordChanged() and it's throwing the exception there?
That's just a guess; What is really needed here (to find the true cause of the bug) would be a complete stack trace showing the source of your exception.
Regarding your 2nd problem: It's difficult to know how to reproduce this since it includes steps involving your app. You mentioned "this issue seems to affect the APIDemos app as well". It would be really helpful if you could provide steps to reproduce the bug requiring *only* ApiDemos.
Thanks!
Regarding the first problem, I have examined the code path and I don't believe that the WRITE_SETTINGS permission should be required at all by the resetPassword operation.
Here's a clue: In the log line you provided, it refers to your own code:
>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
By any chance are you trying to do something in your implementation of DeviceAdminReceiver.onPasswordChanged() and it's throwing the exception there?
That's just a guess; What is really needed here (to find the true cause of the bug) would be a complete stack trace showing the source of your exception.
Regarding your 2nd problem: It's difficult to know how to reproduce this since it includes steps involving your app. You mentioned "this issue seems to affect the APIDemos app as well". It would be really helpful if you could provide steps to reproduce the bug requiring *only* ApiDemos.
Thanks!
qu...@gmail.com
By any chance are you trying to do something in your implementation of DeviceAdminReceiver.onPasswordChanged() and it's throwing the exception there?
No, I am not doing anything special in my implementation of onPasswordChanged()
It is throwing the exception resetPassword(); I figure telling you the steps for the APIDemos app will be the most helpful as I am using pretty much the same implementation in the Demos app.
Here are the steps for the APIDemos app.
First start off with a clean install of android 3.0 or 3.1. I am using my galaxy tab 10.1
Install the API Demos app
Open API Demos
App -> Device Admin -> Enable Admin -> Accept ->
In the Edit Text box that says Password type something. I am typing "1234" (without quotes)
Click on reset password.
You should now see a force close. Attached is my lolcat while preforming these steps.
No, I am not doing anything special in my implementation of onPasswordChanged()
It is throwing the exception resetPassword(); I figure telling you the steps for the APIDemos app will be the most helpful as I am using pretty much the same implementation in the Demos app.
Here are the steps for the APIDemos app.
First start off with a clean install of android 3.0 or 3.1. I am using my galaxy tab 10.1
Install the API Demos app
Open API Demos
App -> Device Admin -> Enable Admin -> Accept ->
In the Edit Text box that says Password type something. I am typing "1234" (without quotes)
Click on reset password.
You should now see a force close. Attached is my lolcat while preforming these steps.
qu...@gmail.com
The clean install is a big deal because of what I found out.
If you have previously set a Pin (i have only tested the pin) for the lockscreen then this problem does not occur.
Example.
After you see the force close from the previous post
Go into the settings app -> Location & Security -> Configure Lock screen -> PIN -> Set pin to "1234" (no quotes)
Now try the steps from the previous post using APIDemos app again.
The app should not crash now.
If you have previously set a Pin (i have only tested the pin) for the lockscreen then this problem does not occur.
Example.
After you see the force close from the previous post
Go into the settings app -> Location & Security -> Configure Lock screen -> PIN -> Set pin to "1234" (no quotes)
Now try the steps from the previous post using APIDemos app again.
The app should not crash now.
qu...@gmail.com
Hello, I was wondering if you had a chance to look at this.
nn...@google.com
ze...@gmail.com
Any news regarding this issue ?
We have encountered it to, and it's exactly as mentioned above.
We have encountered it to, and it's exactly as mentioned above.
qu...@gmail.com
I have not heard of any updates.
I am hoping this issue is fixed in ICS. Actually going to test that right now. --Will report back.
I am hoping this issue is fixed in ICS. Actually going to test that right now. --Will report back.
qu...@gmail.com
It seems like this issue does not exist in the ICS emulator, which is a good thing =).
so...@gmail.com
[Comment deleted]
so...@gmail.com
[Comment deleted]
so...@gmail.com
[Comment deleted]
so...@gmail.com
On Android Honeycomb 3.0 platform, the DevicePolicyServiceManager is *very* different from Gingerbread, the whole flow of resetPassword() in DevicePolicyManager is:
DevicePolicyServiceManager.resetPassword() -->
LockPatternUtils.checkPasswordHistory() -->
LockPatternUtils.passwordToHash() -->
LockPatternUtils.getSalt() -->
LockPatternUtils.putLong(LOCK_PASSWORD_SALT_KEY, salt) -->
Settings.Secure.putLong(LOCK_PASSWORD_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.checkPasswordHistory()* method in Binder.clearCallingIndentity() block.** One more thing, even you add WRITE_SETTINGS permission in you AndroidManifest.xml file, it will tell you that WRTITE_SECURE_SETTINGS permission is also required.
Hope Google can fix this issue ASAP.
DevicePolicyServiceManager.resetPassword() -->
LockPatternUtils.checkPasswordHistory() -->
LockPatternUtils.passwordToHash() -->
LockPatternUtils.getSalt() -->
LockPatternUtils.putLong(LOCK_PASSWORD_SALT_KEY, salt) -->
Settings.Secure.putLong(LOCK_PASSWORD_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.checkPasswordHistory()* method in Binder.clearCallingIndentity() block.** One more thing, even you add WRITE_SETTINGS permission in you AndroidManifest.xml file, it will tell you that WRTITE_SECURE_SETTINGS permission is also required.
Hope Google can fix this issue ASAP.
ze...@gmail.com
Tested on ICS 4.0.3 and it does not occur anymore. Can anyone confirm this ?
m....@gmail.com
Tested on Honeycomb 3.2, also works.
mb...@google.com
sa...@gmail.com
[Comment deleted]
sa...@gmail.com
For me also same problem. But what i did is one time i set the password manually and from there on-wards the code is working fine without asking any permissions.
Can any one tell me how to solve this for first time.
Can any one tell me how to solve this for first time.
cs...@gmail.com
Hi, Am developing a sample application for some administration activities. I need to know how to make password visible ( Visible password option in security settings ) using Device Policy Manager. Give me a sample code or else suggest me any ways to handle it.
an...@gmail.com
I also noticed an issue regarding this. On versions below 4.0, resetPassword will only take effect after the timeout selecteed in the setting "Lock phone after x minutes",or after a restart. If I set that setting to 'Immediatelly' then it works right away.
This is not ok. For example, I call resetPassword("1234", 0); and then lockNow();
After waking the phone, the new password has not taken effect necessarily, depeding on the "lock after x mins" setting.
This is not ok. For example, I call resetPassword("1234", 0); and then lockNow();
After waking the phone, the new password has not taken effect necessarily, depeding on the "lock after x mins" setting.
mb...@google.com
an...@gmail.com
I finally went with mDPM.setMaximumTimeToLock(devAdminCompName, 3000); just before lockNow(); and it works.
sa...@google.com
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
Description
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="
<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.