I have an application and I would like to block the exit of it to the people that doesn't know the application,
how can i do it?
I only found a function to block back button...
Thank you so much...
The closest thing I could find is called task locking or screen pinning on Android. It is only supported on Android Lollipop (5.0) or higher. The documentation has the following to say about this feature:
Android 5.0 introduces a new screen pinning API that lets you
temporarily restrict users from leaving your task or being interrupted
by notifications. This could be used, for example, if you are
developing an education app to support high stakes assessment
requirements on Android, or a single-purpose or kiosk application.
Once your app activates screen pinning, users cannot see
notifications, access other apps, or return to the home screen, until
your app exits the mode.
There are some other questions asked regarding task locking, which you can find here and here.
I have been able to find a Cordova plugin for this here, however it doesn't seem to be very active at this moment in time.
Unfortunately, I don't think that this will actually solve your problem. From what I have been able (or unable) to find, this just doesn't seem to be possible. I think it is similar to closing an app on iOS with code, it is simply not allowed by the developers of the operating system.
Related
If I have a suite of Android tablets, is it possible that I can have Chrome be the only app that is used on the tablet whilst also locking Chrome to access 1 URL?
We're building a web app for school kids and we want to lock down its use for everything else.
I understand there's a kiosk mode that will lock down to a single app, just can't see anything about disabling the ability to navigate to another website.
I guess you're better going with building an webview app.
That way, you can use android's native kiosk mode to lock the device into that app, that's actually just a webview to your web app.
Edit: Also, I found out something that could be interesting for your case: Android's Lock Task Mode
From documentation:
Android can run tasks in an immersive, kiosk-like fashion called lock task mode. You might use lock task mode if you’re developing a kiosk application or a launcher to present a collection of apps. When the system runs in lock task mode, device users typically can’t see notifications, access non-allowlisted apps, or return to the home screen (unless the home screen is allowlisted).
Adding another answer because I actually found what you're looking for.
You can setup an application to change the device's policies to lock-on on the Chrome app and then lock Chrome to a single website.
Here is the full reference of the answer you're looking for.
I am learning about Kiosk devices. I am going through the docs but stumbled across this thing.
As per docs-
Kiosk Apps are Chrome Apps that are designed to always run fullscreen using Single App Kiosk Mode on Chrome OS and do not allow the user to exit the app. They're great for a purpose-built Chrome device, such as a guest registration desk, a library catalog station, or a point-of-sale system in a store.
There is also a mention of Kiosk Mode
It is an Android kiosk app that replaces the default Home Screen or Launcher and restricts user to accessonly one application or a few allowed applications. ... It has become common to use off-the-shelf mobile devices to run business applications or self-service kiosks.
Though I am unable to understand as to how to develop a Kiosk app for Android.
Yes, you can build kiosk apps in android.
In addition to Morrison Chang's link in their comment I suggest you to read this article for more practical approach.
Note: This article has a point on making layer that catches user drag events and such. On newer Android versions(8.0) this no longer works.
You can create Kiosk application. From Lolipop 5.0 google is providing api for that.
https://developer.android.com/work/cosu
You can use Pinning or LockTask to achieve the Kiosk application feature.
Some like of sample git application
Git Link
Git Link2
You can make kiosk device by making your application owner of the device and then pinning the app on the device.
Please follow the below link it gives the detailed concept of making an application an owner device and then you can pin it using the code for pinning
https://medium.com/#ashubansal.ashishbansal/make-your-android-device-a-kiosk-device-so-that-no-one-can-open-anything-in-your-device-except-the-3bb42a0db8ea
If you are using a dedicated device for your kiosk app you can use the Android For Work APIs to have a single application or multi application kiosk.
Lock task mode API from the android allows you to lock the specific app to run on the device and always on the foreground. This will disable the Home button and Overview button as well making a true kiosk mode experience.
In order to use the API, you need to use the DevicePolicyManager and run your application as Device owner.
You can also refer here for details on how to create a Kiosk app
https://blog.esper.io/best-way-to-build-android-apps-in-kiosk-mode
I have a requirement to create an app that should run 24/7. I don't care about battery drain, becoz app will not be submitted to PlayStore and its only for the selected user.I also understand app will only last for one day, that is acceptable in my case.
The application functionality mainly dependent on network and Bluetooth functionality and the most of the code written in pre marshmallow and changing the whole implementation is not a right option for me now.
So is there any way to create the app without any restriction? Also, As observed some of the Device manufacturers put an extra layer of battery optimization to make this worse.
I tried to create a dummy foreground service with partial wakelock, but this not seems to be working. and even whitelisting the app didn't solve the issue.
There is no proper documentation from Google about what are the functionalities will be affected from doze/standby. According to Google doc the background task will not be suspended, it only deferred until the next maintenance window. If that is the case, App should be able to print all the app that is missed during doze period. But as observed app will print the log only during the maintenance window. The is will break the expected behavior.
Whitelisting is a good option but app will be still be affected by the doze mode. What is the reason to restrict the app behavior even when the user explicitly chose not to? It very frustrating when the app behaves differently in different device OS, Manufacturer etc.
Sorry for the story. I would like to understand is there any way to completely disable Doze and standby mode without changing the existing implementation? I have gone through the various document, but there is NO WAY to achieve this 100%. Please share your thoughts
I have a requirement to create an app that should run 24/7
Write a program for a desktop operating system. Or, perhaps find a mobile device that runs Linux and write a program for it. Or, create a custom version of Android that disables Doze/app standby. Or, see if there is some Android hardware that meets your requirements and does not apply Doze/app standby (e.g., devices that naturally are always plugged in, such as Android TV or a Chromebox).
So is there any way to create the app without any restriction?
No, sorry.
I would like to understand is there any way to completely disable Doze and standby mode without changing the existing implementation?
No, sorry.
AFAIK there is absolutely no way to detect the moment when app gets uninstalled.
I am currently writing an app which should among else toggle on/off 3G data. It went ok before 2.3 with ITelephony reflection calls, but from Android 2.3 this is not possible.
So I had to resort to APNDroid-style way of adding suffixes to APNs in content://telephony/carriers. This seems to work, but I stumble on the same problem as APNDroid has: since we can't detect when the app is removed, all the suffixes will remain if the user first turns off 3G with the app and then uninstalls the app.
This is an ugly and dangerous solution, because the end user may be left with all APNs broken.
It's possible to detect uninstallation from another application, but how would one force the user to install another application to just monitor the first one? It seems there is no way from 2.3 on to write a 3G-managing app.
Any ideas?
AFAIK there is absolutely no way to detect the moment when app gets uninstalled.
Correct.
I am currently writing an app which should among else toggle on/off 3G data. It went ok before 2.3 with ITelephony reflection calls, but from Android 2.3 this is not possible.
Which means that you should not be implementing the app as an SDK application. You should have not implemented the app using "ITelephony reflection calls", either.
This is an ugly and dangerous solution, because the end user may be left with all APNs broken.
Which means that you should not be implementing the app as an SDK application.
how would one force the user to install another application to just monitor the first one?
You can't.
It seems there is no way from 2.3 on to write a 3G-managing app.
Correct.
You are welcome to try to contribute changes to the AOSP Settings application, or create a new firmware application, that offers the features you seek.
why cant android os be more like apple os on the the ituch/iphone? where the app doesn't run until it is selected. it is also closed; stays closed until it is opened again.
i think this would make the android phones run faster and more efficiently(battery would last longer).
A lot of Android apps (I think most of them) run exactly as you describe it - they have an activity that is closed or suspended as soon as you leave it - a suspended Activity only consumes memory and can be discarded in an instant. (iOS does nearly the same)
Even on the iPhone there are applications that run in the background, the most prominent example being Mobile Safari. The difference is that only Apple can write applications that run in the background without restriction, and that a regular user has no way of monitoring these background apps. (this has led to massive overcharging issues in the case of users leaving Mobile Safari on a page where streaming content was loaded.)
There are legitimate use cases where you need an app to continue running in the background (downloading, uploading, playing music, waiting for a VoIP call) - none of it was possible for a third-party to do it on the iPhone until iOS4, making applications such as Pandora or Skype nearly useless.
For good or ill, Apple consistently restricts what third-party developers are allowed to do on iOS devices (App Store policy, private APIs, specialized APIs for background tasks mentioned in point 3). On the other hand, Google seems to prefer that third-party Android developers have access to the same APIs as Google's Android app developers.
The biggest Android performance problem IMO is responsiveness, the fixing of which is a lot more involved than saying "no Apps in Background thx". (See http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html for more information)
An Android developer's blog explains the reasoning behind Android multitasking.
We did not want to require that users close applications when "done" with them.
Mobile devices … have fairly hard limits on memory use.
These competing constraints were a key motivation for Android's design.
The fact that you can see an application's process "running" does not mean the application is running or doing anything.
The articles linked from there also have interesting things to say on the subject
The RadioActive Yak:
When should your app include an exit button? The Short Answer: Never.
Wickenden:
One of the first things the naive but technically inquisitive new android user does is begin to wonder how all the things they are running should be “shut down”.
Google’s android system has been designed for multi-tasking in ways that allow programs to be ready to respond to a changed environmental condition instantly (an alarm to wake you, a notification that you have arrived at your destination and so forth) as well as actually “running” and consuming resources when needed. Additionally the android system itself is smart about how it deals with low memory conditions and is capable of completely blowing away applications in such a way that their state is remembered and can be restored when there is more memory.
Task Killers (whose behavior is radically clipped in Android 2.2 “Froyo”) actually can cause harm by destroying a process that other apps need to function correctly.