[TIMOB-23433] Android: Background service loses activity context and properties when restarted

For a long time we have been using a background service backed up with a alarm manger to implement a reoccurring service that runs some code and talks to a backend. This is a very common thing to do. To develop this feature according to google guide lines the use of a alarm manager is required to avoid having the service die due to different Android SDK limitations in power schemes and standby. Over time (2 years) I have seen Android 4, 5 and now 6 implement harsher and more restricted limitations on services. Too make sure a service is kept alive after a shutdown of the app for what ever reason you use the START_STICKY option to make the service restart. This is to make sure the service restarts if the main app (activity) is shut down by the user or by the system. The START_STICKY option makes the service restart regardless of the main app (activity) Along with this setting the Alarm manager will make sure to reenable/ restart the service if for any reason the Android system shut down the service for battery or other standby / doze reasons. For the moment we have a service running as expected when it comes to these settings and issues, however for a long time we have seen that the service that are restarted loses its original inheritance from the main app. For instance if you make an app and a service (see your own docs) the service can access the Alloy.Globals properties as long as the service is not restarted. This is most probably due to the fact that the service (thread) inherits the main apps memory area. This is at least how a Linux system would work. So far all good, but now if the service is restarted from a START_STYCKY setting, making sure that the service stays aline even if the main app (activity) is killed the service can no longer use the Alloy.Globals. We have of course worked around this by require the Alloy framework, however that will not solve the variables to come back, we also have to reinitiate them and set them "again" to make sure they are available everytime the service is restarted. Over time we have however found a problem we cannot solve without having to patch your SDK every time and at all code lines where you use it. In many many places in your code of the SDK you use something like: public boolean hasLocationPermissions() { if (Build.VERSION.SDK_INT < 23) { return true; } Activity currentActivity = TiApplication.getInstance().getCurrentActivity(); if (currentActivity.checkSelfPermission(Manifest.permission.ACCESS_FINE_LOCATION) == PackageManager.PERMISSION_GRANTED) { return true; } return false; } this is found in the file: and at the latest nightly builds android/modules/geolocation/src/java/ti/modules/titanium/geolocation/GeolocationModule.java As you can see you are using the : Activity currentActivity = TiApplication.getInstance().getCurrentActivity(); the problem is this is available when the service is still alive and inherited from main context, then the service is restarted the .getCurrentActivity is not available anymore, instead you have to use: .getApplicationContext So for every API that you have and use the TiApplication.getInstance().getCurrentActivity(); it means that the service in Android will crash, we have made some initial searches i your SDK and you use the TiApplication.getInstance().getCurrentActivity(); everywhere. To make the service remain working using the common APIs that can be run in a background service like location above you have to change all these lines of code into .getApplicationContext Now this is a CRITICAL VERY HIGH PRIO problem as this means (unless we are wrong) that no service in android can remain active when the main app is shut down and using START_STICKY is very common and the right way to use a service in the background, as well as using Alarm manager. We also found the same problem here: ndroid/modules/platform/src/java/ti/modules/titanium/platform/PlatformModule.java also an API that is a must in the background service, that one uses : Activity a = getActivity(); There are more. We have had to patch EVERY API to have our Service continue service after the more and more common doze and standby along with limitations from the system. This is a none wanted situation and should be quite critical to you too making sure the community and professionals can use the backgrund service continually. The last problem we encountered was that you probably use the same lines of code in your Analytics proprietary module making the Analytics to effectively crash in the service when used after a restart of the service, this also is a BIG problem as you want the analytics to report as well as not crashing the app. Here we havd to go into the SDK and remove the call to the Analytics module.. since we cant patch that code. Can we PLEASE have some attention to this serious bug in Android and sort this thing out. I do not have the time to make a example app of this right now but may help you later, just make sure to make a background service that uses START_STICKY and then kill the main app in the monitor (DDMS) observe the service restart (you do not have to use Alarm Manager as well) and then make sure you use one API that uses that getCurrentActivity call and you will see the service stop running...