I'm currently facing a troublesome bug with some Android Devices. I'm checking up on KeyguardManager to see if I need to disable audio or not (I want the audio be disabled whenever the game is not active or screen is locked etc.)
I've been using isDeviceLocked method to see if the user has access or not.
But now I found a device that continuously reports that `isDeviceLocked' == true.
Android docs says
boolean isDeviceLocked ()
Returns whether the device is currently locked and requires a PIN, pattern or password to unlock.
boolean isKeyguardLocked ()
Return whether the keyguard is currently locked.
What's the difference between isDeviceLocked and isKeyguardLocked, except for that they were added in different SDK versions?
The isDeviceLocked() method returns true only when the device is locked and requires a PIN, pattern or password to unlock. The isKeyguardLocked() method is similar but it will also return true if the device is locked without any security.
Related
Im trying to develop an app which has a few security options, and for one of those options I need to able to know if the device is locked with any kind password(numbers,pattern,etc) so I started reading the android documentation and found two KeyguardManager methods, isDeivceLocked() and isDeviceSecured() however I don't really see much of a difference in the description, so what really is the difference between the two? thanks in advance
The official API states the difference, though it might be a bit confusing. The key difference is whether you want to know the general configuration of the device, or its current state.
So isDeviceLocked() returns true if the device is currently locked behind some kind of password or identification mechanism, which is required in order to unlock and use the device. It returns false in case that the device is currently open and in use, or that it just doesn't require any password/identification in order to open it. (reference and more details may be found here)
On the other hand, isDeviceSecure() returns true if the device has been configured to use any kind of password or identification mechanism - even if it's not currently required in order to use the device.
In case you wonder what scenario might cause isDeviceSecure to return true, while isDeviceLocked returns false: it might happen whenever the device in in use (after the lock password has already been entered). Another scenario might be when the device has Smart Unlock (or trusted devices) configured, so that currently it wouldn't ask for a password or any other kind of identification in order to open/unlock itself.
How do we retain the seamless fingerprint unlocking effect after using DevicePolicyManager to perform lockNow() in Android 6.0?
Assuming on devices with fingerprint scanner and the app calling lockNow() has "USES_POLICY_FORCE_LOCK" and had been granted Device Administrator status.
This is the documentation for the lockNow() function:
public void lockNow ()
Make the device lock immediately, as if the lock screen timeout has expired at the point of this call.
The calling device admin must have requested USES_POLICY_FORCE_LOCK to be able to call this method; if it has not, a security exception will be thrown.
Gaining Device Administrator status and performing lock just fine. For sake of reference, see this SO question for the approach I used.
The problem is after the phone locks, the fingerprint scanner no longer smoothly unlocks the phone. Instead, the fingerprint scanner prompts me to input the fallback PIN code. Is there something new I have to do in Android 6.0 in order to retain the fingerprint unlocking effect after performing a lockNow() call?
I have looked at all the DevicePolicyManager flags (in the documentation) and it seems to be offering disabling of things rather than enabling of things.
Thanks!
Looks like Google has marked it Working as Intended without any proper explanation.
https://code.google.com/p/android/issues/detail?id=79735#c110
and also here
https://code.google.com/p/android/issues/detail?id=191955#c23
So we currently we have no way of locking the screen programmatically while keeping smart lock working. They also say that "developers are using it incorrectly". Not sure if they are joking or serious.
EDIT : some unsatisfactory explanation here https://code.google.com/p/android/issues/detail?id=79735#c115
As mentioned in this link: https://code.google.com/p/android/issues/detail?id=79735, this seems to be a problem with smart lock, and not just the google imprint (fingerprint scanner).
If you can rely on root privileges you can probably use: PowerManager.goToSleep(0);
Without root privileges it looks like there is no better solution as of today.
version: android 4.4.2
I use keyguardLock.disableKeyguard() unlock the screen, then use keyguardManager.inKeyguardRestrictedInputMode() print screen lock state, it always return true,but the powerManager.isScreenOn() return true,and i can use my phone normally.
ps: I do lock and unlock in a android service.
Is there any thing wrong when use disableKeyguard()?
The keyguardLock is deprecated starting from API 13. Please use the FLAG_DISMISS_KEYGUARD and/or FLAG_SHOW_WHEN_LOCKED. See here
I am making a Utility app for my galaxy nexus. I want to reboot my tablet in safe mode.
I tried to look in PowerManager
PowerManager p = (PowerManager) getSystemService(POWER_SERVICE);
p.reboot(reason);
It seems this will not reboot the device in safe mode. Is it possible to reboot the device programmatically? How?
Basically there are two known ways to enter Safe Mode:
Android detects a problem with a newly installed app and force-closes it while entering into Safe Mode.
A combination of key presses at power application;
I doubt there's yet another way of doing it. If there was, most recoveries and power menus of Custom ROMS would have included that.
The string passed to reboot() is a kernel param, and would have effect only if device's kernel has that option. You can try some options here.
UPDATE:
Safe Mode is toggle is inside PackageManagerService of Android's system server ("package" service):
public void enterSafeMode() {
enforceSystemOrRoot("Only the system can request entering safe mode");
if (!mSystemReady) {
mSafeMode = true;
}
}
and here are some points about using it from any APP :
Process executing this code must be System or have Root previleges
This is an internal service and off-limits to any outside code. Though, some system classes indeed get implementation stubs (IPackageManager) of this service.
The mode change can only be useful when system is yet to be ready.
Let's suppose your app does turn on safe mode some how, due to safe mode being enabled, it won't be around to turn it off. Unless its a system app, built into ROM.
A third way to enter safe mode (available sometime after GingerBread 2.3.5)
With device fully powered up, Press power button, and the LONG press on the power off menu item. An option appears to go into safe mode. Because of this, there may now be a way to programmaticaly enter safe mode. Sure hope so to help troubleshoot. i am going from memory on a lifehacker article which referenced yet another source.
I'm trying to lock/unlock the screen using Keyguard and everything works as expected when using the KeyguardManager.KeyguardLock disableKeyguard() and reenableKeyguard() functions.
I've tried it with "regular" slider lock, pattern, PIN and password lock and
they are all disabled and enabled when the appropriate functions are called.
The only thing that worries me is that the documentation of these functions has the following statement:
This call has no effect while any DevicePolicyManager is enabled that requires a password
I'm not sure I understand exactly in which cases this might not work and wouldn't like to find out after I release my application...
I tried reading a bit more on DevicePolicyManager but couldn't find any way to find out if there is an active DevicePolicyManager that will prevent the enable/disable screen lock functions to work.
Can you please describe a scenario that this will not work, and how I can identify these cases ?
The most common form of this "in the wild" is the user having a corporate Exchange device admin that requires they have a password. I believe the DeviceAdmin in the APIDemos is sufficient to test against this.