All the past answers to this question seem to be redundant.
I've managed to successfully load a test device with android kiosk mode, which runs a single use app upon booting up and it stays there full screen the whole time the device is on however because the device is in an inclosed cabinet for the public it should not need any user intervention when booting up. currently after booting up it shows the lockscreen (no password). a person must swipe UP before the kiosk mode is revealed with the single use app running. its very important to find a way to completely remove the lockscreen so the device just boots up without any user intervention and continues performing its task as per normal.
your feedback will be greatly appreciated!
thanks
siz
Related
I am trying to make my feedback app to support fully kiosk, I have tried a lot of solutions but Nothing is completely satisfying my need. Here are the things that I found yet.
1. Make my app as Device Admin/Owner App(Lock Task) -
If we follow this link/procedure https://developer.android.com/work/dpc/dedicated-devices/lock-task-mode, some limitations are there as follows -
a. We have to factory reset all the devices where Feedback app is installed, follow some steps to make it as admin app(launcher app).
b. Installation of the app will be possible using the command line, each installation will take some line of code through cmd, which means for installing a person has to go there with the computer and connect the device with USB and then install the app using commands.
c. Update on an app will also follow the same procedure (Couldn't be performed using google play store)
d. In this case, end-user will never be able to exit from our app, restart the device would also launch the same feedback app every single time.
2. Programmatically screen pinning + programmatically volume and power button controlling. (https://github.com/mrugacz95/kiosk)
a. In this, we will make the app in screen pinning mode where all the three bottom buttons(Overview, home, recent) will be hidden/disabled. and same with the power key and volume keys.
b. So As soon user clicks on kiosk mode, a screen pinning system generated prompt would be shown to user But the biggest disadvantage of it is that app would be unpinned/unlocked as soon as the user presses overview+recent buttons together.
3. The third Case is, where all the keys are controlled including power+voulme+back+overview etc.
Only pressing home will make the app to go on the background and within seconds it will again come foreground.
So all I found up until now, is not very satisfiable.
One more Question-
Is this something to be fully controlled by MDM(Mobile Device Management)?
Any help is appreciated.
1. Make my app as Device Admin/Owner App
a. A device owner can only be installed on a newly initialized device (before an account is added). I believe this is by design : A device owner can completely lock the device down, you don't want a malicious app to be able to seize the phone of an unsuspecting user after a few "I agree" popups.
b. You don't need to install it using adb. The simplest provisioning method is via NFC : While the device shows the very first screen of the setup wizard, touch it with a tag (or another device) containing the provisioning configuration, most importantly an URL where the apk can be downloaded and a WiFi config.
Another method is via QR code (Android 7+) : tap 6 times the first setup screen. It is a bit less convenient than NFC because you usually have to provision the WiFi manually.
c. A device owner can be updated like any other app. As it can itself install or update applications without asking the user, you can implement a fully automatized self update mechanism : check for update / download / update.
2. Lock task / screen pinning
Any application can programatically enter lock task mode. How it happens depends on whether the application is white listed by a device owner app (possibly itself) :
If not, the user is prompted and must accept, they can also exit at any time. This is basically the same thing as screen pinning.
If yes, there is no popup : the user can not decline to enter, nor exit, the lock task mode.
Additionally a kiosk application can act as a launcher. A device owner (again, possibly itself) can set it without user intervention
Is this something to be fully controlled by MDM(Mobile Device Management)?
While device owner apps are usually DPC connected to a MDM console of some sort, this is not a technical requirement. How you control it is completely up to you. (I hope I understood correctly the question)
Overall, I think that the only reliable way a device can be locked in kiosk mode is to use a device owner app (separately or included in the kiosk application). The setup via NFC or QR code is actually faster than a normal device setup. It can also protect against safe mode reboot or factory reset. The only real constraint is that you can not deploy this kind of application on existing devices without wiping them first.
Make my app as Device Admin/Owner App(Lock Task) -
a. If you are making it an 'admin app' this means you have signed the device image correct? Therefore you control the full flashing of the device - you can do anything in this scenario.
b. You can actually also do ADB over WiFi after you set it up the first time
c. You can update your apps from the playstore - even launcher applications
d. This fact is the whole point of Kiosk mode. Users should not ever be able to exit the application. Only you can exit, either with a remote command or with a invisible touch combination (for example touching each of the corners of the screen in sequence twice, or other 'secret unlock code')
Programmatically screen pinning + programmatically volume and power button controlling. (https://github.com/mrugacz95/kiosk)
b. This is the opposite of 1d, it is not clear what you want if you want neither.
The third Case is, where all the keys are controlled including power+voulme+back+overview etc.
This is also the opposite of 1d, it is not clear what you want if you want neither.
We need a few more details on your deployment scenario for this app to help you out further.
I installed an app on my android phone to safe lock certain apps with a password. Since I installed it, sometimes, regardless what i'm doing on the phone/which app i'm using, a full size screen with advertising appears and I have to click an "X" to close it or press back/home button.
(Can be that this screen appears randomly only when I digited a password to unlock an app therefore the safe lock app was active let's say, not sure.)
I was anyway wondering what sort of code is used for this? Anyone?
I'd need it for a less despicable cause: in order to show a transparent view with alertdialog when my timer is up and the app is closed, to imitate the original builtin countdown timer.
I am searching for a way to unlock the device permanently from an app launch. The concept is that I plug in a device via usb to the tablet/phone and the screen unlocks (this is working) and after I exit the app I want the device to return to them home screen. But the thing is that it returns to the lock screen instead of the home screen. Is there a way to do this?
The main idea behind this is to keep the user away from inserting the unlock code multiple times, for no apparent reason.
I'm trying to start an app upon the first boot of the device before the keyguard appears. I need to ensure the first thing the user sees after the boot animation (which I've also changed) is this app. My app is just three screens of text in fullscreen mode with a next button in between them.
I realize that for most cases, this would be a terrible user experience. However, the phones we're shipping have a very specific purpose and because of this I need to meet the following criteria:
my app needs to be the first thing the user sees (after the boot animation of course) when they take the phone out of the box and power it on for the first time.
after the first boot, the phone should function as normal (i.e the keyguard should appear upon bootup instead of my app).
this only needs to work for lollipop since that's the android version we're shipping.
I can modify the Android framework if needed, but a solution where I don't have to is preferred.
My (Failed) Approach
Create an app that starts upon boot. Have the app dismiss the keyguard as the first thing it does.
The problem I found with this approach is the keyguard code is called before the app initialization code so the user sees the keyguard briefly and then sees my app.
A Possible Solution
I think the best way to do this is to add code in the framework to call my app before calling the keyguard. I'm imagining having a boolean that's used to keep track of whether it's the first time the device is powered on. If that boolean is true, open the app. If not, open the keyguard.
The problem is there's a lot of code in the android userspace boot process and I have a quickly-approaching deadline (don't we all?). How can I modify the framework code to show my app before the keyguard?
If there's a better way, please let me know that too!
I'm writing an anti theft app, and I want when sim card is changed a dialog opens on boot and tell the finder to bring back the phone. This activity must be unleavable, so he can't leave it unless the correct code is entered.
Other situation is when user send a lock SMS to the phone.
I know how a device admin can lock the phone, but lock don't tell the message and the password can't be entered. And lock may not have a password or pattern so the finder can pass it easily.
Maybe a combination of device lock and a full screen activity which disable the keyguard do the job?
In my research, without being installed at the OEM level, you can't make it 100% un-leavable, just really annoying.
In an app I wrote for businesses which use a kiosk, since we weren't at the OEM level, we just kept the menu bar hidden and set the app to be loaded whenever Home was hit. Keeping the menu bar hidden was a pain, but was achieved by making it invisible and then when re-triggered, making it go away after 1 second. It's still able to be exited by hitting the clock in that 1 second, though. :(