On Android Lollipop versions before 5.1 some custom fonts loaded using the API Typeface.createFromAsset() do not render using the correct font. This issue was fixed with the release of Android 5.1, but will still affect your users running Android Lollipop 5.0.x.
This should not cause a crash in your app, it will just cause your view to render using the default typeface rather than the custom font you have specified.
What causes the issue?
The cause of this issue is badly formed TTF font files. Minor issues in font files may be ignored or tolerated by most systems rendering the font, however the tolerance level in the early builds of Lollipop was not so high and some fonts fail to render causing the system to fall back to using the default font. It is similar to having a badly written audio file that will play in some media apps but is flagged as corrupted in others.
Is my app affected?
The first thing to check is if your app loads custom fonts. Take a look for any font files found in your Android assets/fonts folder. Then look for the code that is loading the font so you can see where in the apps UI the custom font is used. Loading a custom font from your apps Assets folder and setting it into a View is quite straight forward.
Typeface tf = Typeface.createFromAsset(getAssets(), "fonts/myfont.ttf"); myView.setTypeface(tf);
Having custom fonts doesn’t always mean your app will be affected by this issue however. The quickest way to check is to visually verify those custom fonts are being rendered correctly. Another check suggested by the Android team is to run your font through the Sanitiser for OpenType engine. To determine a potential issue look for this in the output:
WARNING at ots-read-only/src/cmap.cc:160: bad id_range_offset
The root cause of the problem is badly written font files, so it makes sense that the solution is to re-encode the offending font.
If you only have a couple of font files you would like to re-encode a great place to start is with an online converting tool such as http://www.freefontconverter.com/. Upload your dodgy font file and even if you select the same input and output font format (ie. TTF), the file will still be re-encoded and should now be able to be used in your app. This web service has successfully fixed all the non conforming fonts I have thrown at it.
However if that online tool did not help, or you have a huge repository of files you would like to re-encode you may like to use https://github.com/behdad/fonttools/ to convert your TTF to XML and then back to a TTF.
Be careful running any software that will re-encode your font files. As this process will be changing the file there may be side effects such as loss of quality. Also it is possible the tool you are using to re-encode the file will also produce non-compliant font files that fail in some environments.
Why did my Unit tests not catch this error?
If you have had to fix this error then you may be thinking to yourself, Why did my unit test not alert me to this issue? or How can I write a unit test to stop this issue next time?
Don’t be too hard on yourself; for all intents and purposes the code appears to function correctly without visually verifying the rendering. The typeface is loaded correctly and it can be set into a view without issue or complaint. Even after the view has been invalidated and rendered there is still no exceptions or warnings of an issue raised. The problem only becomes obvious on visual inspection of the View.
Android issue tracker for this issue:
Android Typeface documentation: