Many of us are eager to get a way to let our app run background services, in other words, not to be killed/terminated by the system when losing focus. Apps which require this feature include
- a clock app (which can wake you up after a 7h sound sleep)
- a map app (shouldn’t stop during a 4h drive, even if the screen is closed)
- a pedometer app (continues counting your step when you’re chatting online)
MIT App Inventor has build a demo , aiming to reach this goal. However, for some reasons, this site seems to have stopped functioning. And as far as I know, there are NO extension which can help.
However, recently I discovered that a simple Activity Starter component can solve this problem. The knowledge behind it is that Android kills your app for battery concerns. But in official Android Developer Reference, it offers some ways to help apps to avoid such optimization. One of the simplest way is here. This activity can start a dialog to ask users for this privilege. In Thubkable/App Inventor, we can use Activity Starter and set it as
Data Uri: package:com.thunkable.android.yourName.appName
(The exact package name can be obtain via various tools. Google for it by yourself.)
My phone is a Huawei Honor 8, on which this method works out fine. However, it doesn’t really start any dialog to inform me of the permission, but run my Thunkable app as a Special app automatically!. I consider its because Huawei has make many changes to build a system for itself. Anyway, if you have tried this method, please remember to comment the result and your device info under this post! What’s more, this case suggest us to use Activity Starter to accomplish certain functions. If you have any new ideas, feel free to discuss!
PS: I have to copy the special note from Android Reference. You have to be careful when deciding whether to use this method.
most applications should not use this; there are many facilities provided by the platform for applications to operate correctly in the various power saving modes. This is only for unusual applications that need to deeply control their own execution, at the potential expense of the user’s battery life. Note that these applications greatly run the risk of showing to the user as high power consumers on their device