ObjCClass doesn't have other virtual methods; it is not intended to be
used as an interface or dynamic type. Removing the virtual destructor
is intended to promote composition over inheritance when using this
type.
This bug could be observed in the DemoRunner:
- Enable "button" navigation mode (as opposed to "gesture" mode) on the
Android device.
- Remove the line enabling kiosk mode, build and install the DemoRunner.
- Run the app and navigate to the Settings pane. Open a menu, or the
bluetooth MIDI dialog window, then close the popup window.
- Rotate the device.
Previously, the steps above could result in the system painting its own
backgrounds behind the system bars. With this patch in place, we reset
the requested system UI colours and transparency, which seems to
maintain the desired appearance.
Regarding didComplete():
When a WebInputStream is destroyed, the thread of execution will wait in
SharedSession::removeTask() until the task is no longer present in the
list of all active tasks. If multiple threads are all waiting in
removeTask(), then all of those threads should wake when the set of
active tasks changes. Waking only a single thread may result in
deadlocks, as that thread's task may not have completed successfully.
Then, the thread that woke up will be forced to sleep again and may not
get another chance to wake.
Regarding didBecomeInvalid():
Normally, didBecomeInvalid() will only be called after the
SharedSession's destructor. If the destructor is running, we may assume
that no other thread can access the SharedSession, so using notify_one()
in didBecomeInvalid() should be sufficient to wake up the destructor's
thread. However, there's a chance that the NSURLSession may be
invalidated unexpectedly (i.e. before the SharedSession's destructor
runs), in which case there may still be threads waiting in removeTask().
In this scenario we need to notify_all() so that all waiting threads are
able to wake and make progress.
Android 15+ removed the 'legacy' png-based emoji font. Modern Android
versions may include only a COLR-v1-based font, which JUCE cannot
render itself.
As a workaround, on Android, we use a Canvas object to render each emoji
glyph into a bitmap, and then render that bitmap in the same way as a
legacy png-based glyph. This won't look as crisp as rendering COLRv1
glyphs directly, especially at larger sizes, but this is a sufficient
stop-gap for the time being.
The goal of this change is to ensure that the safeAreaInsets and
keyboardInsets members of Display correctly take the current system UI
and screen cutouts into account.
This change also enables rendering behind the status bar and navigation
bar for JUCE applications. This is in line with the new defaults in
Android 15, where building against the Android SDK 35 will automatically
enable "edge-to-edge" drawing. Enabling this behaviour on older
platforms too provides a more consistent experience.
