I write an android app for athletic examinations in my corporation.
Specifically, in one mile run examination, examiner person needs no interruptions at all, because he will loose 400m checkpoint passes of examinees.
No phone calls, SMS, messages, alarms, calendar notifications, nothing, nothing, nothing.
Until now, I think the easy way: a dialog which informs examiner to go to flight mode. It doesn't cover all these interruptions, but it is the best solution so far.
Is something better out there?
That kind of interruption is simply unavoidable and out of your app reach. Android system receive and emit all kind of interruptions (events) from notification to low battery. Every event has its own app which respond events using intent-filter, broadcast listener, etc. so you can't really have access to all apps that wasn't yours.
Simply put, no you can't. Your Airplane mode solution + No disruption mode might be the best option.
Sounds like you could use the Android Service feature.
Related
I would like to run predefined service in my app if I do two short volume up pushes (or one long hold).
It should works also if phone has locked screen or another app is in foreground.
Thanks for any advice or example how can i do it.
The official Broadcast Receiver for volume changes only gets triggered when the state changes from volume to/from silent to/from vibrate. So perhaps, it could detect a long volume up hold under some circumstances, but I don't know. That Broadcast Receiver is not granular at all.
I've seen non-rooted apps on Google Play that detect the volume keys at a more granular level, but I believe those apps are making use of undocumented functionality (of which I do not know about).
If you're making your own rom as your username might imply, detecting those keys would be much easier to do. Is that the case? Are you making your own rom? Will the app you're making have root access?
I've seen some "app locking" solutions in the Google Play store and I was wondering how those apps work. I'd like to build something similar.
I realize that this might require some special permission or maybe request the app to be added as device administrator.
Is there some broadcast that is triggered just before an app is launched that I can intercept and do some action (e.g. launch an activity that will request the user to fill a password)? I've read some lengthy discussions how this is not a good idea and the only idea is to have a background service that will continuously poll the running processes and check for changes, but I think retrieving this list every second and checking it for chances is not good for the battery and I think other app locking apps out there must be using a different approch.
If possible, without the need for a rooted phone.
I'm developing and Android application on CodenameOne that needs to send a web request every 5 minutes even when minimized. How can I achieve this behavior in order to prevent that the request get stopped or paused by the OS?
You cant do that from the activity, you'll need to create background service.
http://developer.android.com/training/run-background-service/create-service.html
Use AlarmManager to set up your every-five-minute operation. Have it trigger a BroadcastReceiver, which in turn passes control to my WakefulIntentService (or your own IntentService that handles the WakeLock, that you will need so that the device stays awake while you do your work). Have the service do the "web request".
This is still not 100% guaranteed:
The user can Force Stop you from Settings, in which case your alarms are gone and nothing will happen until the user manually runs your app again
The user might block alarms from firing on certain devices, like various SONY Xperia models, that offer "stamina mode" or the equivalent
However, it is the best that you are going to get, short of rolling your own Android OS version.
The other guys answers are correct that you need to create a service but they somehow ignored the mention of Codename One.
Under Codename One you need to create a native directory for android and just place the service source code there (just use a blank service class that doesn't really do anything). Then you need to add to the build arguments the option android.xapplication where you would state the service XML attributes.
Having said that what you are trying to do is VERY wrong and you shouldn't do it in Android! You will drain the battery life from the device in no time and the service will be killed by the OS eventually (since it will be a battery drain). The solution is to send a push notification to the device to wake up the application.
In Android 9 and newer you can prevent your App falling asleep with a battery setting.
Long click on your App -> App info -> battery -> optimize battery consumption
Here add your App from the list.Hint: maybe the menu entries have a different name, depending on your phone.
I am writing a metronome app, I have the sound running from a service which I would like to keep running when the user is outside the app (browsing etc) and hasn't made a conscious effort to press the stop button.
It seems I should be using startForeground() as it's not the kind of thing you want in the background without paying attention to, and I really don't want the service to be killed at any time. Ideally I wouldn't be showing the notification while the app is in focus though. I notice that the Google Play Music app works this way, it only shows the notification when outside the app. Is anyone able to tell me how they have done this, I would find it hard to believe they wouldn't be using startForeground() after reading all the documentation stating you should be using it for this sort of app?
On the other hand, is this really desired behavior? It seems good to me, but I noticed that pretty much every other app I use with a long running service (HTC's music app, Navigation, few others) shows the notification icon at all times, whether in the app or not. I am interested in what is considered correct behavior. Any help much appreciated, thanks.
Is anyone able to tell me how they have done this
They probably call stopForeground() when one of their activities returns to the foreground, and startForeground() when they think the user has left (e.g., onUserLeaveHint()).
I am interested in what is considered correct behavior.
I do not think there is a definitive "correct behavior" in this area. It is easier to do what the other apps do and leave the Notification around, until the user indicates that they no longer want the background work to run.
Note that while you may want "to keep running when the user is outside the app", the user might not. Certain types of apps (e.g., music players) can safely assume that the user wants the audio to keep going; a metronome, IMHO, does not rise to that level. Please allow the user to configure this behavior, such as through a SharedPreference.
I have a request on developing enterprice tracking application. The application should be able to get current postion of the phone and send it to server every 5 minutes. Even if application is running on background - user can easily shut it down. I need to create some sort of restriction for that, maybe password based. In order to shut down this application user must enter a password. And if he is rebooting, application should autorun after rebooting.
Is it possible to do this?
No it is not!
But... I know a trick that can do the work, it's name is AlarmManager
You can set alarm for your application that will alert every 1 sec, and if the application been shut down it will rebuild it self.
At this point you can set a password to shut down the alarmManager.
But just to let you know, I been trying this once, Google told me nothing, but users left me a comment that the application is hacking they device ;)
From ICS onwards, any app implementing Device Administration cannot be stopped. But the only drawback is the user can remove the Devvice Administrator.
You could restrict your app to work only when Administrator is On.
One more way is if the user removes the administrator you can lock the whole device with a custom password using resetpassword.
If the devices were rooted you could implement that but you probbaly wouldn't be able to distribute the app as an APK due to the required modification of system files. Maybe as a Zip that is flashed via Clockwork mod. Beware of voiding the devices' warranty though.
Babibu's suggestion regarding Alarms is a novel approach, but be cautious of waking the system constantly as that will drain the battery much faster.
Actually a big problem you'll face is that the user can disable GPS and then you can't programatically turn it back on again - unless you try to use an exploit which is obviously not ideal and won't work on all devices.
A better idea might simply be to report to your server whenever the user disables the application or GPS. You'll know which user disabled it so your organisation can punish that user appropriately.
What you are looking for is Device Administration
http://developer.android.com/guide/topics/admin/device-admin.html
This page explains how it works and how you can change all sort of policies about passwords and disable camera.. et cetera
What they barely talk about is as soon as an application is enabled as device administrator you can't kill it or uninstall it without disabling this feature first. It's up to you to implement enable/disable buttons the proper way.
To be sure the service always restart even if killed by system (in low ressources cases) you need to override this method of your Service :
public int onStartCommand (Intent intent, int flags, int startId)
{
return START_STICKY;
}
Finally to make your service start at boot you need to catch ACTION_BOOT_COMPLETED broadcast.
The main issue is you can't prevent user from disabling GPS or using mock locations but you can detect it and log it.
It is a good practice (actually it is mandatory in my country) to notice users they are watched so you can explain them at the same time that you'll know if they mess up with the GPS.
Rooting the phone is another solution but you will likely open more doors than you close ;)