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.
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.
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 have written an application that locks android phone remotely. That is when a special code is sent from server then application locks the phone based on the special code. This is the code I am using.
if (!mDPM.isAdminActive(mDeviceAdminSample)) {
// try to become active – must happen here in this activity, to get result
Intent intent = new Intent(DevicePolicyManager.ACTION_ADD_DEVICE_ADMIN);
intent.putExtra(DevicePolicyManager.EXTRA_DEVICE_ADMIN,mDeviceAdminSample);
intent.putExtra(DevicePolicyManager.EXTRA_ADD_EXPLANATION,"Admin is added to do security operation.");
startActivityForResult(intent, 0);
} else {
// Already is a device administrator, can do security operations now.
mDPM.lockNow();
}
The above code is working and it's locking the phone.
I am able to unlock the phone by entering password from soft keypad. Is there any way to unlock it through code?
My question is how to unlock the phone through code.(This unlocking should be done remotely in the manner I explained for locking)
I believe you cannot override the built-in screen-lock unless you make your own device like Samsung and HTC do. However, by having your customers use your own screen-lock-like app you probably can achieve what you are trying to do.
I do not think your remote unlock goal is achievable.
The way Android is set up, is that many apps may have Device Administrator privilege, and any Device Administrator can issue a lock command, but the unlock has to come from the user.
I can suggest one thing you to simplify this: Your app could try to remove the key lock password, and then the user can use the device without a code simply by sliding a finger on the screen.
Now there is a snag in what I suggested, if your app is not the only device administrator. In that case, some other administrator app could set a minimum password length (or some other password restriction) which would prevent your app from clearing the screen lock password.
If your goal is to help a user that forgot his/her screen lock password, then your server could invent a new password, inform the user what the new password is, and also send the new password to your app and your app could apply the password. The user can then unlock the phone. Do not worry, it is not as complicated as it sounds.
Sorry to write that - There is no way to unlock phone from code. If you find any way to do that - no warranty to work. So there is no way to remote unlock, writing custom lock screens, etc.
You need to use mDPM.resetPassword("", 0)
http://developer.android.com/reference/android/app/admin/DevicePolicyManager.html#resetPassword(java.lang.String, int)
When set password string as "", current password is replaced with empty values & screen lock disappears.
try this
KeyguardManager manager = (KeyguardManager)context.getSystemService(KEYGUARD_SERVICE);
kl = manager.newKeyguardLock("my-remote-app");
kl.disableKeyguard();
//for reenabling keyguard on exit (if you need)
onDestroy() {
kl.reenableKeyguard();
}
this works <=ICS.
This is a deprecated api, they suggested you to use the flags from WindowManager for similar effect. Although I failed to generate the similar effect using the WindowManger.
Hope this helps,
Please note that I'm not an Android developer, but:
If you look at this, it looks like you can ask the WindowManager to dismiss the key guard if you have the right permission, even if you're in "secure lock" mode.
As per my knowledge, we cant unlock password protected phone programatically.
One solution would be to write a "custom lockscreen".
Sure, it's not the easiest way, but it would work as you can do everything you want with your own lockscreen.
If you are considering that solution, feel free to contact me, I'll give you some useful links.
Cheers!
This question already has answers here:
Is it possible to detect Android app uninstall?
(8 answers)
Perform a task on uninstall in android [duplicate]
(4 answers)
Closed 7 years ago.
I though it was not possible but I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called.
I would like to replicate this behavior in my App.
I tried with an Activity listening to "android.intent.action.DELETE" Intent, as suggested here:
How to know my app is uninstalled from the device...?
But as I'm about to uninstall my app, the chooser pops up asking to pick my application or the package uninstaller. How can I avoid this?
Is there a different way to intercept your application UNINSTALL event? (before answering that it is not possible, please try to uninstall NQ Mobile Security and see what happens. On my Android 2.3.4 it shows a nice screen saying that is not safe to go without a security app).
I noticed that NQ Mobile Security is able to show a message after I click on Uninstall and before the PackageUninstaller is called
They must be exploiting some security flaw in Android. I will research it and see if I can get it fixed. Apps are not supposed to get control at uninstall time.
Thanks for pointing this out!
Is there a different way to intercept your application UNINSTALL event?
I sure hope not.
Opera Max is an app that does something similar - after being uninstalled opens a webpage.
How do they do this?
By using libevent, from native code, they watch /data/data/com.opera.max directory to be removed and then post good old action.VIEW broadcast when it happens.
Install their app, run it, and on rooted device from adb shell remove /data/data/com.opera.max directory
UPDATE: I created a sample app that shows how it works. BTW it doesn't work with recent (KitKat+ I think) Android versions: https://github.com/pelotasplus/ActionAfterUninstall
I'm pretty sure that they are monitoring the LogCat to intercept when the Activity Manager calls the PackageUninstaller. I think they kill the task and start their own Activity.
It's pretty clever but it's definitely exploiting a security hole in Android.
They are likely asking for a very critical permission that the user is granting them unknowingly. Look at the "Permissions" tab for this app (as of 6/15/2012): https://play.google.com/store/apps/details?id=com.nqmobile.antivirus20&hl=en.
The list of permissions this app gets is downright chilling. Among other things:
SYSTEM TOOLS RETRIEVE RUNNING APPS Allows the app to retrieve
information about currently and recently running tasks. Malicious apps
may discover private information about other apps.
CHANGE/INTERCEPT NETWORK SETTINGS AND TRAFFIC Allows the app to change network settings
and to intercept and inspect all network traffic, for example to
change the proxy and port of any APN. Malicious apps may monitor,
redirect, or modify network packets without your knowledge.
PREVENT TABLET FROM SLEEPING PREVENT PHONE FROM SLEEPING Allows the app to
prevent the tablet from going to sleep. Allows the app to prevent the
phone from going to sleep.
CHANGE YOUR UI SETTINGS Allows the app to
change the current configuration, such as the locale or overall font
size.
MODIFY GLOBAL SYSTEM SETTINGS Allows the app to modify the
system's settings data. Malicious apps may corrupt your system's
configuration.
DISPLAY SYSTEM-LEVEL ALERTS Allows the app to show
system alert windows. Malicious apps may take over the entire screen.
MOUNT AND UNMOUNT FILESYSTEMS Allows the app to mount and unmount
filesystems for removable storage.
CHANGE NETWORK CONNECTIVITY Allows
the app to change the state of network connectivity.
CHANGE WI-FI STATE Allows the app to connect to and disconnect from Wi-Fi access
points, and to make changes to configured Wi-Fi networks.
-- Update --
I also found that the Android Package Manager pretty much just deletes a package if it is asked to do so. The only check it performs prior to doing so is whether the package being deleted is currently registered as having an active device admin:
try {
if (dpm != null && dpm.packageHasActiveAdmins(packageName)) {
Slog.w(TAG, "Not removing package " + packageName + ": has active device admin");
return PackageManager.DELETE_FAILED_DEVICE_POLICY_MANAGER;
}
} catch (RemoteException e) {
}
See line 6900 in PackageManagerService in the AOSP source here.
For this, the application must be explicitly registered as a device admin by the user. See notes on device administration here: http://developer.android.com/training/enterprise/device-management-policy.html.
As per https://stackoverflow.com/a/26829978/1317564, here is some example code that does it: https://github.com/zzljob/android-uninstall-feedback/blob/master/library/jni/feedback-uninstall.c. This won't actually stop the uninstall from taking place, but does provide a way to catch it and take some action. I'm honestly surprised that this works in Android and the team may have plugged the gap in recent releases.
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.