Version 1.49.2

Version 1.49.2 is released!

• Fixed a crash for NR photo mode on some devices since version 1.49.
• Now supporting latest emoji.

Apart from some minor other improvements, that's it I'm afraid. You may be wondering, what do emoji have to do with Open Camera? This is due to a new Google Play policy, in order to support a new Android method that allows older devices to support newer emoji. On the face of it this seems a good thing, but what's odd is the urgency that this has been given, and doing so via a policy:

• Firstly, a note about timelines: whilst the issue of making latest emoji has existed for a while, this has not been due to applications lagging behind - the version of AppCompat from Google that supports updatable emoji only came out of beta November 17 2021. The policy was originally declared as being active from February 2 2022, leaving a short time period for what must surely be a vast number of apps on Google Play needing to suddenly be updated. (It seems it's now dated at April 20, 2022, which is a little better, but wasn't the original announcement.)

• But surely it's only things like chat applications? you might say. After all, this is the reported problem (that people receive emoji symbols that don't display properly). The policy however applies to all applications, or at least, all those that can display any user text, even if it's not received from elsewhere. In Open Camera, one example would be the photo stamp option; more obscure examples would be folders and filename prefix options - although putting emoji in filenames is a bit weird, this policy would still presumably apply.

• To be fair, it does mean that if you're putting emoji in a string to stamp onto photos, this will now work with latest emoji even on older devices, so that's an improvement. But there is the question of priority - in all the years of Open Camera, in all the emails and forum posts I've received, to my knowledge not a single person has requested or even noticed this. Yet making it a Google Play policy means it now becomes required to fix this in the timeframe with the highest priority. This comes at a cost - the time spent doing this is time not spent fixing bugs or implementing features that users actually want.

• It's unclear why Google have used a policy for this - previously they've used technical means to get applications to update, with less strict consequences and more realistic timelines (e.g., not being able to release updates if not using latest version of such-and-such - this method is used for targetting new Android versions, and hence also for things like scoped storage; it was also used for 64-bit). Policies, in my opinion, should be used for things like malware, privacy violations, and so on, not things that are better handled as "best practices". In recent years more and more development time has been spent reacting to changes in Android (e.g., scoped storage), and this sets a worrying precedent where policies are used to direct ordinary application development, rather than it being directed by users and developers. If this really is the most important thing ever, why wasn't it fixed years ago anyway?

• Implementing the changes was not as simple as just using the latest AppCompat library. A gotcha is that this doesn't work if a TextView (or subclass) class is created programmatically instead of XML. This is a practice that is valid and non-deprecated as far as I know, and useful for dynamically created UIs (e.g., Open Camera's popup menu). This leads to a real risk of getting it wrong - an application could be in violation of Google Play policies simply due to a single programmatically created EditText. A further complication is that EditTextPreference creates an EditText programmatically. To be fair the class has been deprecated, but the AndroidX Preference replacement system is not a backwards compatible replacement, but requires substantial changes (most notably that sub-screens are not directly supported so have to be handled by the application).

• Google seems to have not realised that Canvas.drawText() is not fixed by their provided solution. In Open Camera (where this is used for user text when rendering the photo stamp text onto the image), I had to instead put the text into a TextView and render that onto the Canvas.

• It's interesting to note that another recent Google Play policy banned the use of emoji in titles, icon and developer names on Google Play. (It's like, emoji are suddenly the most important and inclusive thing ever, except when they aren't.)

There seems to be surprisingly little awareness or discussion among Android developers of the changes needed, or maybe I'm not looking in the right places - just a few threads here and there. I also note this will be a problem for anyone using high level third party toolkits if they haven't in turn been updated.

Let's face it, we know there are lots of apps that haven't been updated for years, even if they're still perfectly good. If they have an EditText, it seems they surely risk being in violation when the new policy becomes active - is Google really going to do a mass ban? Probably not. But that's the problem - Google Play policy enforcement already feels a bit "russian roulette", but it seems very odd if policies are so broad, yet randomly enforced, that a vast number of apps could technically be in violation. Unless of course I've read this all wrong! In which case, some clarification from Google on the policy would be welcome.

It's easy to see if any given application is compliant yet, by following Google's instructions for testing on a device running Android version from 4.4 to 10 inclusive. So hey, let's test Google's own apps! I tested on an Android 9 device. As of today, the latest version of Google Keep still shows "tofu" for some of the emoji listed on their test page. Chrome meanwhile does now show the emoji correctly. Curiously in Gmail, whilst they display correctly when viewing them in an email message, I still see "tofu" if the emoji are showed in the preview when viewing one's email list. Of course, there's still time yet for them to fix that! (To be sure, Google say there are other reasons why a device might not display the latest emoji correctly, but I know that this device does display the latest emoji once using the latest AppCompat etc, as I used this same device for testing Open Camera.)

Update 19 June 2022: I note the wording of the linked policy has been changed, stating "Apps that use default Android Emoji without any custom implementations already use the latest version of Unicode Emoji when running on Android 12+.", and then suggesting that the policy only applies to "Apps with custom emoji implementations, including those provided by third-party libraries". So that's an improvement, and possibly means Open Camera was never affected - however it wasn't the wording as of 31 March 2022 ( http://web.archive.org/web/20220331144459/https://support.google.com/googleplay/android-developer/answer/11190644 ), and with the imminent policy deadline it's not like developers could wait for that clarification. Even for applications that do use a custom emoji implementation, it still seems odd to me to announce this with such urgency and via a policy.