I would like to upload large files (~10 - 100Mb wifi or mobile network), but in background, because the user maybe will leave the app and later the system will close the app (if not enoguh memory) I created a service for this case but my problem is that when i killed the app the service restarting and the uploading start again. I found same problems without solution:
keeping background service alive after user exit app
My service is restarted each time the application is closed
So it won't work, but what is the solution? How does the youtube app???
You should use a foreground service via the startForeground() method if you are concerned about the possibility of the service being killed.
From the Service Lifecycle Docs:
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.)
Do you have control over the server? This seems just like:
Uploading big files over HTTP
Googling brought up a proposal for the Gears project:
https://code.google.com/p/gears/wiki/ResumableHttpRequestsProposal
If you can use a server/plugin/module that will allow for Ranged PUTs, that's your best bet, otherwise you may have to roll-your-own "chunking"... Depending on your tools and knowledge, that may be the best option anyway, you could tweak it to optimize it for your specific mobile conditions.
Related
I am building a ride-hailing app and I need a real-time driver location update even when the app is closed or in background, according to the new android os versions I can't use background services even if I could use it the os might kill it so my best option is to use foreground service with a noticeable notification, my question is, is it possible to use an ongoing foreground service for realtime location updates without being killed?
A foreground service can still be killed, its just less likely to be so. If the user was to open up a couple of memory hogging apps that meant it really needed your apps memory, it can still be killed. There's a priority to what stays in memory, having a foreground service just makes it higher priority than an app with a background service using the same resources. That said, a foreground service is your best bet for short duration updates like that.
Note that there's a difference between "closed" and backgrounded. If the app is backgrounded, a foreground service will continue. If the user terminates the app by swiping it away from recents or force stopping it, the foreground service will also be killed. But the foreground service would allow him to move to another app (like Waze or something) without killing your app unless the phone goes really low on memory.
i have a problem look like you . i am searching a lot and i test
foregroundservice , alarmManager , Worker and ...
none of them isnt working well and suddenly service stoped ! .
in the end i find 1 ways :
1- handle service in server in backened with pushNotificaiton .
Context / Current Approach
Hello, I'm curious about my usage of a Foreground Service. I have an app which performs voice communication and maintains a persistent connection to our backend via a websocket. It is a common use case for our users to background our app and do something else which is memory- and CPU-intensive, in particular playing mobile games.
In order to prevent our app's process from dying and severing the voice connection, we run a Foreground Service in our app's process (a local service, in some vocabularies). This Foreground Service doesn't actually do much, it displays a notification that allows the user to interact and mute/deafen/disconnect from the notification tray. All the voice logic doesn't actually live in the Service.
Our hypothesis is that by running a Foreground Service, we effectively mark our process as "foregrounded", and the OS is less likely to kill our app. This also allows the user to swipe away our app and have the process stay alive (including the voice connection). This appears to work and looks very similar to the process/service signatures of similar products (Skype, Spotify) using adb shell dumpsys activity services and the inspectors in the device's settings.
However, from time to time we still hear about users who experience our app being killed while gaming or streaming videos, even when they are on voice and the Service is running.
And Now For The Question(s)
After much research it FEELS like we are doing the right thing already. However, we'd like to make our voice stability more bulletproof if possible, and address those user complaints.
Am I doing the right thing already, or is my understanding of using a Service to "mark our app as foreground priority" flawed? (Addendum: It took me getting to the end of writing this for this question to pop up in my searches. It reads like we're on the right track already).
Is there any way I can verify that the OS is indeed killing my app process? Conventional wisdom says no. However I can imagine some solutions which abuse the STICKY flag to relaunch the Service, log to our servers that the Service was relaunched by the OS (and therefore, must have been killed by the OS), and then stops itself again. I just thought of this while writing so forgive me for not having tried it yet...
Do we have other options? The UI components of our app are not particularly heavyweight. This leads me to think that even if we were to invest in a Remote Service (running in another process), if the OS is already killing our Foreground Service, then the OS will likely also just kill that Remote Service. I don't want to use STICKY to combat that as it would be a poor user experience -- it makes sense for services passively processing data but for active voice chat, restarting "later" doesn't sound great...
Thank you very much for taking the time to read the question, I'm happy to provide any additional necessary context.
I know that I can register a service by adding Code A in AndroidManifest.xml.
Will the service resident in mobile phone system until I uninstall the App?
Will the service may cost system resource when it stays in system?
Code A
<service android:name="bll.CleanupService">
</service>
There are a lot of stuff available on internet related to service and it's usage, But still, I will try to answer as much as possible.
Service: It is android component where it runs on background and foreground of the system.
A foreground service performs some operation that is noticeable to the
user. For example, an audio app would use a foreground service to play
an audio track. Foreground services must display a Notification.
Foreground services continue running even when the user isn't
interacting with the app.
Android - implementing startForeground for a service?
A background service performs an operation that is not noticeable to
the user, It can be downloading any file. We can use this for long
running operation.
Coming back to your question, will try to answer one by one.
Will the service resident in mobile phone system until I uninstall the App ?
Yes, It will reside on your phone until you not uninstall application. But it will not run infinite, As your job finished it will be stop.
Will the service cost may system resource when it stay in system?
It may cause, If you are not using it properly, If you are running background service we should know when to stop it, unless it will run continuously. It may also cause you memory related issue.
If you start the service and the task not complete till then the service will be there in the system. In case of low system resources, the system can kill your service. But you can add options like START_STICKY to start the service again automatically after the system is out of low resources.
You can check this link for further understanding
https://developer.android.com/reference/android/app/Service#ServiceLifecycle
A Service is an application component that can perform long-running
operations in the background, and it doesn't provide a user interface.
Another application component can start a service, and it continues to
run in the background even if the user switches to another
application.
There are two reasons that a service can be run by the system. If someone calls Context.startService() then the system will retrieve the service (creating it and calling its onCreate() method if needed) and then call its onStartCommand(Intent, int, int) method with the arguments supplied by the client. The service will at this point continue running until Context.stopService() or stopSelf() is called.
Will the service resident in mobile phone system until I uninstall the
App ?
Yes. According to Service Lifecycle it can perform long-running operations in the background (i.e Unitil Install Application) until Context.stopService() or stopSelf() is called.
Will the service cost may system resource when it stay in system?
NOTE
Services should be used with caution.To allow running processes, Android sets a hard limit on the heap size alloted for each app. The exact heap size limit varies between devices based on how much RAM the device has available overall. If your app has reached the heap capacity and tries to allocate more memory, the system throws an OutOfMemoryError.
GOOD APPROACH
Developer’s responsibility to make sure that stopService() or stopSelf() is being called after work is done.
Will the service resident in mobile phone system until I uninstall the App ?
[ANS] : Yes,it will reside in mobile phone until you uninstall the app.
Will the service cost may system resource when it stay in system?
[ANS] : If you start the service and it does not stop (if you haven't called stopSelf()) when it's job is over,then it may cost system resources until you uninstall the app.
Will the service resident in mobile phone system until I uninstall the
App?
Yes, the service does reside in mobile phone until the app is uninstalled.
Will the service cost may system resource when it stay in system?
There are different types of services, if the service is STICKY and the operation is not yet fully performed, the service will stay awake and will consume system resources.
Android services might get killed by the operating system at any possible time. There are no guaranteed lifecycle calls like onDestroy() you can rely on. I have to implement a service doing a lot of long running tasks and a bunch of file operations in the background. So my questions are:
Is it generally a good idea to do that in any kind of service? What happens with an open file handle when the process gets killed?
Is there a preferred way to achieve this like using a foreground service?
I think I won't be the first person having this type of problem/question, but I could not find anything on Google or SO. Thanks in advance.
Android services might get killed by the operating system at any possible time.
More accurately, Android app processes might get killed by the operating system at any point.
There are no guaranteed lifecycle calls like onDestroy() you can rely on.
Correct. onDestroy() is very likely to be called, but it is not guaranteed.
I have to implement a service doing a lot of long running tasks and a bunch of file operations in the background.
Pretty much any piece of software bigger than "hello, world" fits that description.
Is it generally a good idea to do that in any kind of service?
You do not have much of an option. A service is what is helping to keep your process around when it no longer is in the foreground from a UI standpoint. If you do not use a service, your process lifetime will likely be on the order of minutes, maybe less. With a service, your process lifetime can be hours, though it depends a lot on the device (e.g., amount of system RAM) and user (e.g., how busy the user is and how many other apps want to do background work).
What happens with an open file handle when the process gets killed?
If you have tried writing stuff to the file at about the point of process termination, any bytes not yet handed over to the OS (e.g., buffered in Java) will not be in the file.
Is there a preferred way to achieve this
I have no idea what "this" is.
like using a foreground service?
There are three main patterns for using a foreground service:
Brief transactions. K9 Mail, for example, appears to use a foreground service while it is checking for new messages, but only during that short window.
User-controlled operations. This is the conventional use case for foreground services. Music players, for example, will usually implement a foreground service for the music playback.
"I am going to try to live forever" types of services. That's not especially practical, as foreground services do not live forever. Users also get irritated with foreground services where they do not understand what they are getting as trade-off for the system RAM/CPU consumption and the always-visible notification icon.
Whether any of these patterns fits your project is something you would need to determine for yourself.
I don't know much about Android multitasking but I thought I'd ask the question before I attempt my project.
Is there a way I can program an Android application (aimed at Android 4.0+ only) to always be open in the background and keep all the network connections alive and the UI "drawn" so that when I open it, it ALWAYS opens instantly and I can use it instantly even if the tablet is doing something else?
Thanks.
Most likely, you want to create a foreground service. A foreground service is a service that the user is aware of and is not considered a candidate to kill if Android is running out of memory. It is associated to a persistent notification bar, that the user can tap to bring to the foreground an activity. To make sure that the network connection are not switched off, your service should acquire a wake lock.
However, please remember that a long running process that potentially kills the battery is considered a bad practice, and you should avoid doing this unless you have really really strong reasons to do it.
No, Android is not build like that. The OS can always kill services/activities in the background when it needs more resources.
You can make services which are always running (sticky service) which restarts if it is killed because of resource problems, when there are resources again available.
With Activies you cannot do that. But it could be happen that your activity is 'paused' and still in the background, so it can be 'resumed' very quickly. But again Android can easily kill it for resources.
There is no way you can have an application always running in the background, unless you modify Android at the firmware level and build your own version. Android kills other apps as and when it needs more resources to run the app currently in the foreground.
However, it is possible to make your app better at handling this by saving data and it's current state in onPause() and restoring the same in onResume().