Is it somehow possible to create a "monitoring" app (assuming we have the appropriate permission level) which is notified when a specific app stops running ?
In other words, is there such an API that would allow to register on a third party app's lifecycle ?
The Android UsageStatsManager can be used to get stats on apps running on a device but requires a settings permission.
A work around could be to get all foreground apps running on a device periodically ... say every 20 mins using a library like jaredrummler-android-processes (which doesn't require any permissions but works on Android KitKat to Marshmallow). Then try to compare the set of apps between each period.
The set difference would reveal which foreground apps have stopped running.
Perhaps using a combination of the above two approaches would be best.
Related
I'm trying to speech recognize every 15 minutes for this I'm using PeriodicWorkRequest but I get the error saying java.util.concurrent.ExecutionException: java.lang.RuntimeException: SpeechRecognizer should be used only from the application's main thread. How do I go about doing this? Is PeriodicWorkRequest the wrong approach?
If you are trying to use Android Framework API to do speech recognition, that functionality is only available with the foreground activity. Based on the error it appears that you are trying to listen from background which isn't possible starting with Android 9.
Background services has gotten stricter in recent versions of Android in order to improve battery life. Previously you might be able to use a Foreground Service to maintain your process, however with features like Doze Mode, Google is restricting the use cases even further. Even if you follow the recommendations for exemption and your app had directed the user manually exempt your app from 'battery saving mode' in Settings, device manufacturers have added their own battery saving features such that a site like: https://dontkillmyapp.com/ is need to understand the current state in Android.
Most likely, any background voice activation or listening app you may have seen was with older versions of Android, or custom software by device manufacturers.
I am developing an application for a business entity. That application should run in the background in every employees' mobile phone. Employees are mostly salesman. The application basically detects location changes and suggest the salesman where they might visit. A kind of reminder application. It also lets other salesmen see where are their teammates.
Right now I am using a foreground activity and it works fine till the system forcefully doesn't kill the service or the phone doesn't reboot due to manual activity or battery discharge.
Ones the application is closed, as of now, the managers in the firm needs to call salespeople to turn on the application once, as on application start it automatically turn on its foreground service. But this is really an extra burden on the management team which can be automated.
I am ok to have any settings based or code based solution. One solution is to root the phones of salespeople and install some extra utility app or write the code based on root APIs, but this will be too much for this simple task.
THe permission RECEIVE_BOOT_COMPLETED was not added properly in the manifest. After adding the permission it worked calmly. In on receive method of the broadcast receiver, I am starting the foreground service.
At the moment, the best way is to use WorkManager https://developer.android.com/topic/libraries/architecture/workmanager/ Yes, it still alpha, but works very good.
From other side, you could work on automating the task "managers in the firm needs to call salespeople to turn on the application once". I mean, an app/backend could automatically call the salesman (with some pre-recorded message) or send SMS to them.
I have an open source gps tracking application that has been around for many years. Recently, I have been getting complaints that in android nougat, instead of getting updates once a minute, people are getting updates from the phone once every five minutes when the phone is unplugged.
There is something going on with the power saver mode even though we tried turning it off.
Is there a way to force a phone to get gps updates at a specified time when unplugged?
Here is the code if anyone wants to see it but I don't think it's a problem with the code. It has been very stable for years.
https://github.com/nickfox/GpsTracker/blob/master/phoneClients/android/app/src/main/java/com/websmithing/gpstracker/LocationService.java
thanks.
One change in Android 7/Nougat was that the Doze is now "more aggressive". In Android 6/Marshmallow the doze mode kicked in when the screen was off, the device was running on battery and it was stationary.
(This is documented in Optimizing for Doze and App Standby)
Now in Android 7 the conditions are just screen off and running on battery.
(This is documented in Android 7.0 Behavior Changes)
Apps can be white-listed to be exempt of the restrictions if they break the core functionalility of it. In your case they do as the GPS tracker needs to record coordinates in real time.
There's a list of Acceptable Use Cases for Whitelisting
This includes:
Task automation app | App's core function is scheduling automated
actions, such as for instant messaging, voice calling, new photo
management, or location actions.
Users can white list an app manually on their own in the device settings or whitelisting can be requested by the app and approved or rejected by the user.
This is covered in Support for Other Use Cases
Quoting:
An app can fire the ACTION_IGNORE_BATTERY_OPTIMIZATION_SETTINGS intent
to take the user directly to the Battery Optimization, where they can
add the app.
An app holding the REQUEST_IGNORE_BATTERY_OPTIMIZATIONS permission can
trigger a system dialog to let the user add the app to the whitelist
directly, without going to settings. The app fires a
ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS Intent to trigger the
dialog.
The user can manually remove apps from the whitelist as needed.
The last point is important of course, but luckily the whitelisting status can be checked programmatically:
An app can check whether it is currently on the exemption whitelist by
calling isIgnoringBatteryOptimizations().
So, dealing with the Doze mode is one thing to study at least.
Another issue is keeping the Service running in general. But the Service getting killed by the system might result in more random time intervals. There are of course the classic things like using START_STICKY or running as a foreground service.
I'm looking for technical input on Android User Profiles (both full & restricted). More specifically I would like to understand:
Whether it is possible to create an app which runs across all profiles, i.e. is not stopped, paused, restarted when switching user profile. My focus is NOT limited to activities, but I'm also interested in knowing whether a system-app/service could be created that does this and if so how.
What life-cycle is maintained for services of the non-active users. I get the impression that (at least some) services of APKs of a user get started the moment it gets activated in the lock screen (even without unlocking) and then are allowed to keep on running. But what will happen in low-memory conditions? Will a service of a non-active user also receive broadcast intents? Can such a service interact with the user and if so how?
In general: can someone point me to any technical information on the Android profiles features? There's a lot of articles on how it "looks" to the user, but I could find very little (apart from info on the pm and am command-line tools' options) on how it really works technically.
Thanks in advance!
Whether it is possible to create an app which runs across all profiles, i.e. is not stopped, paused, restarted when switching user profile. My focus is NOT limited to activities, but I'm also interested in knowing whether a system-app/service could be created that does this and if so how.
Default Android behaviors
By default, an Android application runs in a specific Android user workspace, it does not run for all Android users.
It means that when the user starts an application, it is started for the current Android user only.
When the application is launched from another Android user, Android will recreate a new instance of your application. As Android users can run in the background it means that you can have several instances of the same aplication running in parallel.
All the Android components of you application (ie. Services, Activities, BroadcastReceivers and ContentProviders) will be re-instantiated.
Most of the time it's the wanted behavior, but it can be a problem for some applications that do system-level handlings that have to be done once for the whole system, without
taking into account Android users (ex: a JobService doing some handling on Bluetooth events).
Define a singleton component/application
For each component of your app which is not an Activity, you have the possibility to specify that you want it to run as a singleton (ie. only one instance will be created for all Android users.).
To do so, the property android:singleUser=”true” must be added to the attributes of the component in the AndroidManifest.xml of the application.
<!-- Declare a singleUser service in the AndroidManifest.xml -->
<service
android:name=".MySingleUserService"
android:singleUser="true" />
Any singleUser component will always run under the system Android user (ie. the user 0) which can't be stopped by Android, even if you're application is currently running for another Android user.
To be able to use the property android:singleUser=”true”:
your app has to be a system application (either in system/app/ or system/priv-app/).
you app has to be signed by the platform certificate (by specifying LOCAL_CERTIFICATE := platform in its Android.mk).
your app must declare the use of the following permission in its AndroidManifest.xml.
<!-- Permission needed to use android:singleUser. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS"/>
Additional remarks
If your app only contains singleUser components, the entire app will become singleUser (ie. only one instance of your app will run for the entire system).
android:singleUser=”true” forces android:exported=”false” for your component (except if your app is privleged).
If a component of your application wants to communicate with a singleUser component of the same app via Intents, the default Android APIs can't be used because Intents do not cross Android users.
In that case, you have to use the multi-user Intent exchanges dedicated APIs which are suffixed by AsUser (ex: sendBroadcastAsUser(), startServiceAsUser(), etc.) and which allow to specify the destination Android user (UserHandle.SYSTEM in that case). Note that one of the following permissions must be used:
<!-- Permission needed to send intents to components of the SAME app running in another Android user. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS"/>
<!-- Permission needed to send intents to components of ANOTHER app running in another Android user. -->
<uses-permission android:name="android.permission.INTERACT_ACROSS_USERS_FULL"/>
What life-cycle is maintained for services of the non-active users. I get the impression that (at least some) services of APKs of a user get started the moment it gets activated in the lock screen (even without unlocking) and then are allowed to keep on running. But what will happen in low-memory conditions? Will a service of a non-active user also receive broadcast intents? Can such a service interact with the user and if so how?
As I've mentionned above, an Android user can continue to run in the background even if they are not the active one (at least until Android 10). If resources are low, Android can stop any Android user which is not the system user (ie. stop all their running applications). So a Service can continue to run on an Android user which is currently running in the background until the user is stopped.
As I've also mentioned above, Intents do not cross Android users. So if you have a BroadcastReceiver registered in the user 10 and that an Intent is sent from the user 11, it won't be received by your BroadcastReceiver. The only exception is if you use the AsUser Intent exchanges APIs to send it.
Also note that an Intent with the action BOOT_COMPLETED is sent whenever a new Android user is started. It is only sent to the components of the starting Android user.
Sources
Unfortunately, there is few Android online documentation about multi-user systems. Here are the only articles about it (if youd don't find answers there, I suggest you to directly look into the AOSP source code):
Building Multiuser-Aware Apps
Supporting Multiple Users
Manage multiple users
Before someone tells me this cannot be done, I have done plenty of research on why on process cannot interfere with one another and under what conditions this is possible. Our problem is that the Bluetooth support between devices is inconsistent and the solution on some devices is to stop the existing Bluetooth service and run a separate app (BlueFTP) which is then able to listen on the freed port and manage OPP communication.
android.permission.RESTART_PACKAGES permission plus ActivityManager.restartPackage() doesn't work as it simply restarts the offending package.
Process.killProcess does not work for the obvious reasons (read the API)
android.permission.KILL_BACKGROUND_PROCESSES permission plus ActivityManager.killBackgroundProcesses() is ignored because (I believe as per the API) the Bluetooth app is not considered a background app and therefore not eligible to be killed.
Currently if a client is having an issue with a specific phone, we get them to go to the running apps and force stop the offending OPP Service before refreshing BlueFTP so that the port listener starts. The offending service has more than one possible name depending on the phone and Android version.
So. The process is currently manual but I was hoping there would be a way to achieve this via code mirroring the force stop option in settings. A lighter option could be to assist in opening the settings for that service rather than needing to explain to clients how to get there, but I'd prefer a complete solution if one is available.
Note that while our the dev phones have root access, the client phones will not.
You can use implicit intents for your services in other apps to close them. It wouldn't need extra permissions as well, unless your service enforces a permission for it's access.
Oh, I overlooked the fact that it's a third party app. In that case, you can't really do much. Sorry.