With over 2.5 billion active users, Android is the most widely used operating system worldwide. While the OS itself has been localized to dozens of different languages, that’s not the case for many third-party apps. Larger companies can localize their apps in-house or hire professional translation services, but these options aren’t economically feasible for smaller teams or independent app devs. At best, a smaller team or indie app dev can crowd-source translations from native speakers, and at worst, they can use machine translation services to do the job. However, this could change in Android 12, as we’ve seen evidence that suggests Google may be working on a framework for automatically translating an app’s UI to the user’s native language.
Earlier this week, we obtained an unreleased Android 12 build that contains a couple of new features and UI changes. While digging through the release, we discovered loads of new classes in the framework related to a new “translation service.” Our search began when we discovered two new permissions added to this build of Android 12: BIND_TRANSLATION_SERVICE
and MANAGE_UI_TRANSLATION
. Android’s SystemUI holds the former permission to bind to an app that holds the latter permission, which by default is defined by the value config_defaultTranslationService
. Presumably, an app like Google Translate or Device Personalization Services can be set up as the translation service, but Google may open it up to third-party apps as the MANAGE_UI_TRANSLATION
permission has “role” defined as one of the supported protection levels. If you’ll recall, Android 10 added “Roles” that define apps that should have certain privileges; it’s possible that Google may add “Translator” as a Role, but we don’t know if this role can be granted to apps installed by the user.
In any case, we found references to these permissions in framework code, where we spotted evidence that this new translation code is acting on views within activities rather than on a screenshot or the recent apps panel. Translating text within screenshots or the recent apps panel can already be done by Google Lens, and in conjunction with Device Personalization Services, text can be translated right from the recent apps panel. Meanwhile, Android’s intent system already allows for the basic sharing of text to translate. This new framework, however, seems to be more complex and low-level, and we believe it aims to directly translate text within the UI of an app, replacing text in-line to make the translation feel more native.
We examined the latest versions of Google Translate and Device Personalization Services but did not find any evidence of either integrating this new API. It’s possible this API won’t use Google Translate directly but rather a different API endpoint. If this feature is implemented in line with our speculation, we doubt that Google will charge users for this feature. However, it’s possible they may enable UI translations powered by Google Translate as a Pixel-exclusive feature. Since the framework seems to be coming to AOSP, though, it’s possible that OEMs can define their own translation service if they don’t want to use Google’s.
Third-party apps like AllTrans have for years offered a UI translation feature of their own. Powered by the Xposed Framework, these mods work similarly to how we think Android 12’s UI translation will work, directly hooking into an app’s views to translate and replace the text. However, these mods require users to grab their own API key for a translation service since a shared key would go over the free limit quite quickly. With Google seemingly building a UI translation framework directly into Android 12, though, users would no longer need to root their device to translate apps to their native language. This will hopefully make thousands of apps more accessible to users worldwide.
Using the Xposed Framework, AllTrans hooks into text views within apps to translate the text using Microsoft’s Translator.
Developers will also benefit from automated UI translations. Developers who don’t have the resources to translate their app or who don’t want to use machine translation can let the OS handle things. Releasing a machine-translated app can result in negative reviews from users who blame the developer for the poor translation, but having the user themselves direct the OS to translate the app will result in less frustration as the user better understands where to place the blame for any poorly translated text.
While we’re fairly confident this feature is intended to translate the UI within apps, we aren’t 100% sure it’s the case until we see the feature in action. An alternative use of this feature would be to translate the UI within the OS or only system apps, but we think that’s unlikely because the OS is both already widely localized and any localization can be done before the device leaves the factory or via an OTA update. On the other hand, Google and OEMs can’t account for which languages an app supports, so this feature would help fill in the gap. Considering that Google is developing this feature at the View level, making it so it can be used in all apps, also makes it more likely it’s intended for use in apps rather than the OS. Again, though, we won’t know for sure until this feature gets released, which may or may not happen in the Android 12 stable release.
Thanks to developers Quinny899 and kdrag0n for their assistance in analyzing this code. Also thanks to PNF Software for providing us a license to use JEB Decompiler, a professional-grade reverse engineering tool for Android applications.