Android app doesn't respond to user input after launch

Android
1

Some users are reporting that our Android app doesn’t respond to to user input (touch) events after launching. After minutes the app suddenly starts responding or the other way to unfreeze the app is by switching to another app and back. The UI itself responds to events from the network, so the UI itself is not frozen.

Unfortunately I’m unable to reproduce myself and the problems seems to be specific to certain devices.

I don’t get any crash reports or anything, logs don’t reveal anything so I’m in the dark as to what is going on.

Does anyone recognise these problems?

Are there potential workarounds for this issue?

1 Like
2

Do you have the situation where the modal JUCE Freeware license subwindow is popping up somewhere (maybe its not visible but is popping up), and UI events are therefore going to it before it disappears and are only then despatched to the main window?

3

Thank for your input on this.

I’ve disabled the JUCE splash screen (using JUCE_DISPLAY_SPLASH_SCREEN=0) so I don’t think this is whats happening.

4

Fine, set a breakpoint here and see what you see:

void JUCESplashScreen::parentHierarchyChanged()
{
toFront (false);
}

5

The breakpoint doesn’t get hit, would you expect it to be hit? Even when JUCE_DISPLAY_SPLASH_SCREEN=0 is defined?

6

Nope. Sorry, I meant in the virtual method for your main component, see if parentHierarchyChanged() of your main window is being called during initialization time, and if so - is there toFront(), and if not, why not?.

This would be a clue: the main window is not in focus - parentHierarchyChanged() should happen at least once to put your main component in focus.

So manually toFront() it in your constructor for Android or find out why in your particular case the window stack is not propagating toFront() events through this method …

7

I tried what you suggested, but unfortunately this didn’t seem to help. Here is an excerpt from the logs from the device where this happens:

2024-02-09 22:54:13.736036+00:00 [T] activeWindowStatusChanged() | false                             
2024-02-09 22:54:13.736094+00:00 [T] parentHierarchyChanged()                                        
2024-02-09 22:54:13.739760+00:00 [T] activeWindowStatusChanged() | false                             
2024-02-09 22:54:13.739805+00:00 [T] parentHierarchyChanged()                                        
2024-02-09 22:54:13.739859+00:00 [T] broughtToFront()                                                
2024-02-09 22:54:13.739879+00:00 [T] activeWindowStatusChanged() | false                             
2024-02-09 22:54:13.740672+00:00 [T] broughtToFront()                                                
2024-02-09 22:54:13.740733+00:00 [T] visibilityChanged() | true                                      
2024-02-09 22:54:13.741100+00:00 [T] activeWindowStatusChanged() | true                              
2024-02-09 22:54:13.741133+00:00 [T] focusOfChildComponentChanged()                                  
2024-02-09 22:54:13.741156+00:00 [T] activeWindowStatusChanged() | true                              
2024-02-09 22:54:13.741170+00:00 [T] parentHierarchyChanged()                                        
2024-02-09 22:54:13.741273+00:00 [T] broughtToFront()                                                
2024-02-09 22:54:13.741289+00:00 [T] isVisible=true                                                  
2024-02-09 22:54:13.741300+00:00 [T] isEnabled=true                                                  
2024-02-09 22:54:13.741308+00:00 [T] isActiveWindow=true                                             
2024-02-09 22:54:13.741318+00:00 [T] isActiveTopLevelWindow=true                                     
2024-02-09 22:54:13.741328+00:00 [T] hasKeyboardFocus=true
8

Perhaps a ‘hidden’ Android text window has the carat (cursor) associated with it. I’m not positive but I’ve seen something like this before where an Android TextField was used as a ‘hidden event trap’ for catching full IME-enabled input events (i.e. unicode results are provided for international key combinations) but was not displayed, visibly, in a way that it was obvious the key events were being trapped -i.e. the field is rendered off-screen or at the bottom of the window stack.

So, maybe check for that? The reason I think this is happening is because you mentioned that it all resolves if the app focus goes to another app and then comes back again - this would imply when the re-focus of the app occurs, its not on a hidden ‘IME input event trap TextField’, but rather your main App window …