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.
When building in C++23 mode for iOS with Xcode 16.1 and Ninja, this
symbol could not be found, presumably because it is no longer included
transitively via other standard headers.
This issue manifested on Linux when building in Debug mode. It may also
have caused issues on other platforms. When editing a slider's value
using its text box, and then pressing the enter key, the program would
crash. The issue was not present when running with address sanitizer.
Valgrind was able to find the problem.
This fixes an issue where paths consisting of just a drive letter ("C:")
would be passed to CreateFile without a trailing path separator. The
documented behaviour in this case is for the path to be interpreted
relative to the "current directory" on that disk, so getLinkedTarget()
would incorrectly return the disk's working directory instead of the
drive root.
This also fixes a bug introduced in f7c7225f5c
where the condition guarding the definition of traitCollectionDidChange
was incorrect. This function is never required if the deployment target
is at least 17.0.
