Android Question Why (and how) does my app force itself to the front?

[Sandman]

Just today I received a report that my app forces itself to the front over and over again. This obviously interferes with how the user wants to use their device so it's very disturbing.

I have no code for ability to draw over other apps, and to my knowledge I have never added anything that would make it pop to the front. So normally I'd just lean towards the user being confused - but they actually got a friend to record their screen and sent me the film. It's absolutely correct, my app forces itself to the front, over and over again.

I know nobody but me knows my code, but before I start investigating from square one, I'd thought I'd ask the forum to get a better start in my investigation: What code does even have the ability to force an app to the front?

(Not sure if it's relevant, but the user has a Samsung Galaxy S23, running Android 13 (API level 33).)

 

[Erel]

1. Are you showing a notification?
2. Are you calling StartActivity from a receiver or service?
3. Are you using CallSubDelayed to call a sub in different activity?
4. Is this the only report of this issue?

 

[Sandman]

1. Are you showing a notification?

Yes, there are three situations when I show notifications. Two of the situations are not relevant, I can tell that from the user interface in the film. What is not shown in the film is the last notification: At app launch, if the app has a stored list of locations that must be registered as geofences I do that in a foreground service, which require a notification. The film does not show this notification, but it could be in the overflow dot in the top of the mobile screen, or - more likely - this is a fresh install of the app so there are no locations stored to create geofences from.

2. Are you calling StartActivity from a receiver or service?

No.

I do have three StartActivity in the app, two for launching urls and one for handling NFC scanning. None of these are in a receiver or service. (Also, I can tell by the film that the user doesn't tap on an url or scan a nfc tag.)

3. Are you using CallSubDelayed to call a sub in different activity?

I have two cases of CallSubDelayed:

1. In a reciever (in Receiver_receive) for geofences. It calls a sub in itself. (I can't remember why I did it like that.) That sub in turn starts Starter if it is paused. Then it processes the geofence event, which includes communicating with my API (see 2 below, for instance), and finally stops Starter.

2. In code that communicate with my server API, and uses it to return the response. All calls into this are done with Wait For.

4. Is this the only report of this issue?

The only one that have reached me, yes. But I have during the day today looked at reported exceptions and it's clear there's an increase. I've yet to find a strong connection with the film, but it's entirely possible that it affects more people that simply haven't reported it.

This is an unusually bad bug because the only real solution the user have is to uninstall the app - meaning they won't get a bugfixed version.


Extra information from the logged exceptions:

1. I can't remember ever seeing this one before: (only one instance of this)

android.app.ForegroundServiceStartNotAllowedException: startForegroundService() not allowed due to mAllowStartForeground false: service net.fineapp.my/.srvcmain

2. I have a large increase of these:

android.view.WindowManager$BadTokenException: Unable to add window -- token android.os.BinderProxy@11501fb is not valid; is your activity running?

Thank you for taking a look, I appreciate it

 

[Erel]

That sub in turn starts Starter if it is paused.

This can be a candidate for such strange behavior.

See if you can avoid this.