Nov 3 | 8:25 AM |
Mark M. | has entered the room |
Mark M. | turned on guest access |
Nov 3 | 8:35 AM |
Derek | has entered the room |
Mark M. |
hello, Derek!
|
Mark M. |
how can I help you today?
|
Derek |
Hi Mark
|
Derek |
I have an app that relies on constast bluetooth device interaction without any user interaction. To prevent Android killing the application process we have used a foreground service and it is working quite well on some devices
|
Derek |
However, on testing the app on a Samsung device, the application process is killed. On further research, I have found that devices from some companies (Samsung, One Plus) have a trigger happy battery manager which removes even foreground processes.
|
Derek | |
Mark M. |
no
|
Mark M. |
in the end, we are subject to manufacturer whims
|
Mark M. |
now, there may be specific steps that you can advise users to take to try to help -- sometimes there is some sort of whitelist that they can add your app to, so it is opted out of this behavior
|
Derek |
okay, thought as much
|
Derek |
do you have any links to info regarding what practices most common manufacturers use?
|
Nov 3 | 8:40 AM |
Mark M. |
can you clarify what you mean by "practices" in this context?
|
Derek |
I mean battery saving techniques these manufactures use
|
Derek |
for example Samsung removes all foreground processes after 30-40 mins
|
Mark M. |
I'd be careful about making a blanket statement about Samsung -- they have a zillion device models
|
Mark M. |
I have no doubt that some are fairly aggressive about process termination, but at the same time, that might not be true across the board
|
Mark M. |
I do not know all the details, but I have assumed that manufacturers modify the "out of memory killer" that exists in all Android devices, changing its policies
|
Mark M. |
and, since it's their firmware, they can have those policies be whatever they want (e.g., "terminate all processes whose names contain 'q' withing 30 seconds of entering the background")
|
Nov 3 | 8:45 AM |
Mark M. |
those policies can include a whitelist, whether user-managed or manufacturer-managed (e.g., pay us $$$ and we won't terminate your process quite so aggressively)
|
Mark M. |
but little of this is documented, to the best of my knowledge -- it's all internal decision-making within the manufacturers
|
Mark M. |
we, and our users, just bear the brunt of the problem
|
Derek |
yeah, it is disappointing there is no transparency regarding these sorts of things
|
Derek |
I will think about testing on different devices and changing our approach a bit
|
Derek |
thank you for your help
|
Mark M. |
sorry that I did not have a solution for you!
|
Derek |
No problem, seems like everyone is struggling with the same issue. Goodbye
|
Mark M. |
have a pleasant day!
|
Nov 3 | 9:00 AM |
Derek | has left the room |
Nov 3 | 9:25 AM |
Kai H. | has entered the room |
Kai H. |
So
|
Mark M. |
hello, Kai!
|
Kai H. |
I have a talent for wanting to participate in the office hours and missing it :D
|
Kai H. |
Hello
|
Mark M. |
yeah, I was about to point out the time
|
Mark M. |
got anything quick?
|
Kai H. |
Not really
|
Kai H. |
I'll have to wait till saturday
|
Kai H. |
Or stay up till 1:30 am in my time ;-)
|
Mark M. |
don't forget that you can sign up to be able to post the Android Development Discussion board, and ask questions whenever you wish
|
Kai H. |
Sure, that is another possibility. Thanks.
|
Kai H. |
I hope you had a good office hour ;-)
|
Nov 3 | 9:30 AM |
Mark M. |
I managed to ¯\_(ツ)_/¯ at questions about why manufacturers like killing background processes, so there's that
|
Kai H. |
Heh
|
Mark M. |
you'll be able to read about it in the transcript shortly
|
Mark M. |
but, yeah, that's a wrap for today's chat
|
Kai H. |
Have a good one
|
Mark M. |
you too!
|
Kai H. | has left the room |
Mark M. | turned off guest access |