In our Android Application - during app start we schedule threads to run every 8 hours for transmitting files. I have been observing inconsistent transmission behavior when the app is terminated after app start (i.e. the user kills the app). I am suspecting that the scheduled threads are somehow cancelled/destroyed/terminated with the app gets terminated. Does anyone know whether this is the case on Android?
Sample Code of how I am deploying scheduled background threads.
scheduledExecutor = new ScheduledThreadPoolExecutor(1, <this param is a class that Creates threads with the default priority set to background.>);
scheduledExecutor.setRejectedExecutionHandler(new ThreadPoolExecutor.DiscardPolicy());
scheduledExecutor.schedule(new Handler(), 28800000, TimeUnit.MILLISECONDS);
during app start we schedule threads to run every 8 hours for transmitting files
That will not work very well.
I have been observing inconsistent transmission behavior when the app is terminated after app start (i.e. the user kills the app)
You will have inconsistent transmission behavior if the app is in the background as well. The only scenario in which what you describe would work is some sort of kiosk mode app or other situation where your app UI is always in the foreground.
I am suspecting that the scheduled threads are somehow cancelled/destroyed/terminated with the app gets terminated
Android will terminate your app's process after a period of time, to free up system RAM for other apps. At that point, your threads and other CPU/RAM structures all go away. This is covered in the documentation, as well as many books and courses on Android app development.
And, for the purposes of transmitting files, your app's ability to use the Internet will be affected by Doze mode, app standby, and manufacturer-specific battery-conservation approaches. Doze mode is covered in the documentation.
The standard recommendation today is to use WorkManager, where you schedule the work with instructions that you need network access when the work is performed.
Related
I have an app that with CountDownTimer that executes a piece of code at the given timeframe.
I have been researching the service and it seems that this may get killed depending on wether android needs more resources and/or if my process gets killed. Furthermore, it seems services run on the Main thread. Wouldn't this affect performance of my app?
My service is also listening for other broadcast and updates codes based on the return on these broadcast.
So what is the best way to move forward to keep this alive for 24 hours and is the Service the right approach.
I am creating an application for device tracking for my company (own company devices)
I created a Background Service using the GooglePlay API to get the updates.
However, when my application is closed, it rarely sends the locations to the server. Rarely does it get update updates.
What should I do? Is there any special permission I can use?
Use WorkManager for this purpose. Even if your app is being killed process scheduled in WorkManager will be executed.
In your case, you can schedule to check location at a fixed interval and send it to server or wherever you want to send.
From official doc:
The WorkManager API makes it easy to specify deferrable, asynchronous
tasks and when they should run. These APIs let you create a task and
hand it off to WorkManager to run immediately or at an appropriate
time. For example, an app might need to download new resources from
the network from time to time. Using these classes, you can set up a
task, choose appropriate circumstances for it to run (like "only while
device is charging and online"), and hand it off to WorkManager to run
when the conditions are met. The task is still guaranteed to run, even
if your app is force-quit or the device is rebooted.
Your task will come under Recurring tasks
I am trying to create an Android app that shuts Spotify and thereby turning off music after you fall asleep.
The user gets to choose how long to keep the app running. My question is, can I kill background apps from my current app.
I tried looking on Android Studio's developer website and Google but could not find the answer I was looking for. Thank you.
Service runs in your app process. If your app is garbage collected, the service will stop until:
You start the service in new process via manifest file declaration
You make the service sticky (recommended).
go ahead and research above two and let me know if you would like more explanation or code
If you see official documentation of Service, Google clearly explains why and when service will be destroyed. What is useful in your scenario:
A started service can use the startForeground(int, Notification) API
to put the service in a foreground state, where the system considers
it to be something the user is actively aware of and thus not a
candidate for killing when low on memory. (It is still theoretically
possible for the service to be killed under extreme memory pressure
from the current foreground application, but in practice this should
not be a concern.)
using startForeground will ensure your service keeps running in the same process. some pointers:
A service with attached client will not be destroyed even on low memory scenarios
A service will be killed in low memory scenarios, regardless of the process. Running in a different process is better but does not guarantee it won't be destroyed by system.
Don't use system.exit(0) to end your app. call finish() on activity.
Starting sticky service just ensures that service is restarted when memory is freed.
hope it helps!
Our app extensively relies on backend instances. There is some logic that has to run every few seconds. The execution of this code cannot only be driven by requests arriving on the frontend because it needs to run regardless.
We only considered using task queues to solve this. But as far as we know, task queues only guarantee that tasks will be executed within 24 hours. I have not found a reference to back this up though.
Our app uses a fixed number of resident B1 backend instances. We assume that each instance stays alive 24/7 after the backend version is deployed and started.
Is this a valid assumption? If not, can our application be notified every time a backend instance will be shutdown?
What is the SLA on the availability of a backend instance?
Are backend instances restarted automatically after they are terminated? E.g. is an instance automatically restarted after it runs out of memory?
How quickly will instances be brought up again if they every are terminated?
We create a fixed size thread pool on each backend instance. Is there a maximum size for thread pools that we can have on a backend instance?
Are there any other conditions under which a backend instance might die?
Thanks!
UPDATES
Turns out a couple questions can be answered by reading the docs.
App Engine attempts to keep backends running indefinitely. However, at this time there is no guaranteed uptime for backends.
So what is the SLA for uptime? I am looking for a statement like: "The guaranteed uptime for backends is 99.99%"
The App Engine team will provide more guidance on expected backend uptime as statistics become available.
When will this statistics be available?
It's also important to recognize that the shutdown hook is not always able to run before a backend terminates. In rare cases, an outage can occur that prevents App Engine from providing 30 seconds of shutdown time.
When App Engine needs to turn down a backend instance, existing requests are given 30 seconds to complete, and new requests immediately return 404.
The following code sample demonstrates a basic shutdown hook:
LifecycleManager.getInstance().setShutdownHook(new ShutdownHook() {
public void shutdown() {
LifecycleManager.getInstance().interruptAllRequests();
}
});
I am running only one instance of a resident (non dynamic) Backend and my experience is that it is restarted at least once a day.
You application must be able to store its state and resume after restart.
I have a number of backend processes (java applications) which run 24/7. To monitor these backends (i.e. to check if a process is not responding and notify via SMS/EMAIL) I have written another application.
The old backends now log heartbeat at regular time interval and this new applications checks if they are doing it regularly and notifies if necessary.
Now, We have two options
either run it as a scheduled task, which will run after every (let say) 15 min and stop after doing its job or
Run it as another backend process with 15 min sleep time.
The issue we can foresee right now is that what if this monitor application goes into non-responding state? So, my question is Is there any difference between both the cases or both are same? What option would suit my case more?
Please note this is a specific case and is not same as this or this
Environment: Java, hosted on LINUX server
By scheduled task, do you mean triggered by the system scheduler, or as a scheduled thread in the existing backend processes?
To capture unexpected termination or unresponsive states you would be best running a separate process rather than a thread. However, a scheduled thread would give you closer interaction with the owning process with less IPC overhead.
I would implement both. Maintain a record of the local state in each backend process, with a scheduled task in each process triggering a thread to update the current state of that node. This update could be fairly frequent, since it will be less expensive than communicating with a separate process.
Use your separate "monitoring app" process to routinely gather the information about all the backend processes. This should occur less frequently - whether the process is running all the time, or scheduled by a cron job is immaterial since the state is held in each backend process. If one of the backends become unresponsive, this monitoring app will be able to determine the lack of response and perform some meaningful probes to determine what the problem is. It will be this component that will then notify your SMS/Email utility to send a report.
I would go for a backend process as it can maintain state
have a look at the quartz scheduler from terracotta
http://terracotta.org/products/quartz-scheduler
It will be resilient to transient conditions and you only need provide a simple wrap so the monitor app should be robust providing you get the threading stuff right in the quartz.properties file.
You can use nagios core as core and Naptor to monitoring your application. Its easy to setup and embed with your application development.
You can check at this link:
https://github.com/agunghakase/Naptor/tree/ver1.0.0