As the author of this technology at Localazy, I can explain it pretty well.

How do we change strings.xml on the fly? We don't.

Our Gradle plugin adds a library to your app, performs bytecode analysis, and routes all the relevant method calls through our library. The library itself acts as a proxy, updates its internal strings database from our servers, and serves updated strings whenever possible. It also calculates anonymous stats about string usage, etc., to optimize the translation process on the Localazy site.

All of this happens during the build time without ever touching your source code and resources. It's completely transparent.

While it sounds like a simple task, it's much more complicated as it's impossible to route all method calls easily. E.g., LayoutInflater uses a different method for obtaining strings, and the same applies to Preferences, Menus, etc.

We also download and merge your strings.xml with the latest translations available on Localazy as the standard system method is always a reasonable fallback. We must correctly handle edge cases such as language aliases (iw vs. he), RTL languages, etc.

One of the biggest challenges was correctly supporting build types, product flavors, libraries, and dynamic app modules. It's not just about serving strings from the internal database but selecting the right one. E.g., a string with the same key from a library has lower priority than the app's one. The situation is different for dynamic app modules.

We've designed Localazy to handle all of these situations from the ground - the library, how we store strings on our servers, etc.

It's not a simple task to do this correctly, so better use the existing solution if possible.

Feel free to ask me if you need further help.