0

I've come across this app: Fast Reboot

My app sometimes needs to kill another app - Gallery.

I've tried different methods for that, and none worked reliably. However, it seems that "fast reboot" does indeed kill apps without requiring root.

How does the above described application work?

Violet Giraffe
  • 32,368
  • 48
  • 194
  • 335

1 Answers1

2

I'm suspecting that perhaps the application in question has the KILL_BACKGROUND_PROCESSES permission and uses the killBackgroundProcesses method.

In Android 2, killing processes was kind of occasionally justifiable, but on Android 4 and up, this really isn't something you should be doing to other running applications. I had a task killer app installed on my Nexus One but have had no cause to use one on any post-Gingerbread device.

As far as "fast reboot" goes, I've noticed that some Android versions take much longer to shutdown and start up than others. Cyanogen is super-quick, vanilla Android is only a bit slower, but I always found Samsung's Touchwiz-encumbered Android to be fairly slow on my S3. Fundamentally, if processes need to be shut down cleanly, and there are more of them, then both the shutdown and startup times will be extended. Not really something an application could influence in a reliable fashion.

And don't forget that killing a process (or force stopping in settings) can corrupt that application's data.

Phil Haigh
  • 4,522
  • 1
  • 25
  • 29
  • I've tried killBackgroundProcesses. Doesn't work. And believe me, I have a reason to kill Gallery. It totally disrupts my app's functioning. – Violet Giraffe Jun 12 '13 at 12:37
  • How does gallery (which is a stock app, after all) disrupt your app? – Phil Haigh Jun 12 '13 at 12:56
  • By communicating over USB to a digital camera that I'm also trying to work with. This causes severe hangs since USB functions do not return until timeout passes. – Violet Giraffe Jun 12 '13 at 13:00
  • Hmm. When I plug my Canon DSLR into my tablet (also over USB), I get an OS prompt asking which application I want to use it with (I use DSLR Controller), and when I select one that application is launched or switched to. Can't pretend to know the technical solution (feels like a manifest entry) but that would probably solve your contention issues if you could arrange for Android to prompt the user which app to use (listing all that apply, including gallery and your app) when it is detected. – Phil Haigh Jun 12 '13 at 13:07
  • I did got that way (only got the idea recently) and it helps a lot. But still, a user can choose to always open Gallery for this camera, which brings me to square one. – Violet Giraffe Jun 12 '13 at 13:10
  • Yeah OK, you can't design for the user deciding to move to a conflicting app. With the audio subsystem you can register to be alerted when you lose and then regain audio focus (i.e. another audio clip wants to play over the top of yours). As far as I can see, the USB API lacks this elegant way of being told that another app has seized control. You're using claimInterface/releaseInterface either side of each interaction? – Phil Haigh Jun 12 '13 at 14:20
  • Not exactly. I'm calling `claimInterface` when starting working with the device (connecting to it) and `releaseInterface` when disconnecting. Do you think I should do it for each read / write? – Violet Giraffe Jun 13 '13 at 12:51
  • I don't think so - the guidelines certainly don't suggest that. maybe closing your connection as soon as an operation is complete, rather than keeping it open for long periods of inactivity (if that is what you are doing). I've not done much here before but I'm about to, which is why I'm so interested in this issue. – Phil Haigh Jun 13 '13 at 13:47