On Android, the lifecycle of an application includes the case of its native window being disposed when the app moves to background. When the app comes to foreground again, a new native window is created. However, the JavaFX window is still the same.
In com.sun.glass.ui.Screen, a pointer is kept for a native screen, and when notifySettingsChanged() is called, the JavaFX window(s) gets its screen updated, considering only that the new screen has the same pointer as before.
For instance on Android, this covers the case where the screen changes orientation, where the screen dimensions change but the pointer to the native screen is still the same.
However, when the app goes to background the native screen is disposed, its pointer is 0 as the native window is null. In case the app comes to foreground again, a new native window is created, and therefore there is a new pointer.
The current algorithm only checks that the pointer for the old screen is still the same as the new one, but doesn't take into account this case, in which the old screen has been disposed (and has 0 as pointer) and the new screen has a new non-zero pointer.
This prevents the JavaFX window from getting that new screen, and further changes (for instance in orientation) will produce unexpected results.
In com.sun.glass.ui.Screen, a pointer is kept for a native screen, and when notifySettingsChanged() is called, the JavaFX window(s) gets its screen updated, considering only that the new screen has the same pointer as before.
For instance on Android, this covers the case where the screen changes orientation, where the screen dimensions change but the pointer to the native screen is still the same.
However, when the app goes to background the native screen is disposed, its pointer is 0 as the native window is null. In case the app comes to foreground again, a new native window is created, and therefore there is a new pointer.
The current algorithm only checks that the pointer for the old screen is still the same as the new one, but doesn't take into account this case, in which the old screen has been disposed (and has 0 as pointer) and the new screen has a new non-zero pointer.
This prevents the JavaFX window from getting that new screen, and further changes (for instance in orientation) will produce unexpected results.