It seems that QLocale::system() and therefore also QLocale() don't return the configured system locale under Android when invoked from the service process. This in turn leads to translations not working there.

I therefore tried passing QLocale().bcp47Name() from the frontend to the service manually where I then invoked QLocale::setDefault(QLocale(passedBcp47Name)). The last invocation was in my tests effectively QLocale::setDefault(QLocale(QStringLiteral("de"))). This also didn't work because QLocale() still got me the "C" locale and translations were not working.

I therefore tried instantiating a QGuiApplication in the service process with the help of a previous change of my which got merged: https://codereview.qt-project.org/c/qt/qtbase/+/653832

Only with this setting it was possible to set the default locale in the service process manually.

With this I got translations working but this approach has some serious drawbacks:

1. It shouldn't be required to pass the locale from the frontend to the service manually.
2. It shouldn't be required to instantiate a QGuiApplication in the service process for localization to work. (QAndroidService should be enough.)
3. Instantiating a QGuiApplication didn't even work in all my tests.
   1. It worked well with my x86-64 development build of Qt (with qtbase at 5f6bfa3692a91c9f162606c25ec496656c253dfe) in the emulator and Android 15.
   2. It didn't work with my aarch64 release build of Qt (version 6.9.2) on a real Samsung phone with Android 14 because the service got stuck up on the QGuiApplication instantiation leading to Android producing an ANR for the service process. Not sure why that is. When I tested https://codereview.qt-project.org/c/qt/qtbase/+/653832 with Android 6.9.1 (or was it even still 6.9.0?) the icon rendering I used it for worked on the very same phone where it now gets stuck.
   3. So if using a QGuiApplication is supposed to be "the way" despite 1 and 2 then 3.2 needs to be sorted out. (For the sake of doing image processing/rendering it would also generally make sense to sort this out - but that's a different feature request.) Maybe it only didn't work on the real phone because my aarch64 build is still based on Qt 6.9.2 and the problem is already fixed on the dev branch as of the mentioned commit.

Note that my use case for this is updating an Android notification from the service process even if the activity process isn't running.