I’m running into a couple basic problems with regards to fonts when running JUCE on Android. It seems to struggle with emojis, and really any irregular text. These problems can be reproduced via the emulator - in these examples, I’m using the Pixel 9 Pro XL with API 36 (shown in the screenshots), but any emulator or device should do.
For the first issue: when clicking the FontsDemo in the emulator, this assertion is hit immediately (stack trace shown afterwards).
As for the second issue: if you use the OSK and try to insert emojis into any text editor, I get an assertion and a blank glyph. I’m not sure what’s expected by JUCE in this case: should this work out of the box, or is this “developer and app and situation dependent?”
Is the assertion always hit? For me, the assertion only seems to hit when selecting a few specific fonts (e.g. NotoSansSymbols). If you’re getting the assertion consistently for regular fonts like DroidSans then it would be interesting to know how your emulator/environment differs from mine… In any case, I can investigate the issue using the symbols font, for now.
This seems to be a new(ish) behaviour as of Android 15. Currently, JUCE can only render colour fonts that use the “COLRv0” or “png” formats, but Android 15’s system emoji font only contains COLRv1 data, without any way to fall back to the old font version. Fixing this is going to be a bit involved - adding a COLRv1 renderer is definitely out-of-scope at the moment, so we’ll need to investigate an alternative approach that still lets us display these glyphs. In the meantime, things should work correctly at API level 34.
Yeah; this was on my home Win11 desktop with the latest AS/AGP/ndk/etc. The emulator env is pretty vanilla and freshly created; in the screenshots, you can see that I was using the Pixel 9 Pro XL API 36 emu.
I’ll make a reminder to take some time in the next several days to trace problematic fonts and list them here.
Alright, np. I think targeting API 34 will get me by for now. I just noticed the disclaimer for COLRv1 in Typeface::getLayersForGlyph so at least I’ll have an in-code point of reference.
