They could, as you indicate, build two frameworks instead, but it would be a challenge to keep parity between them, both in look and feel and in functionality.

Having both opinions look the same is less important on mobile than on the desktop, but feel is important. For example, click delays should be very, very similar, selection methods should be the same, etc.

Functionality would be an even bigger challenge. If they ever release new functionality, say a new kind of control, for one framework first, and for the other a few months later, it would appear as if they do not consider the two languages to be primary languages on their platform.

So, one GUI framework, IMO, would be the best solution, not on technical, but on social/political grounds. As thevibesman suggests in a sister comment, having the non-GC framework instantiate a JVM is a solution, but only technically. Again, that would make the non-GC language look like a second-class, bolted-on thing.

Finally, all of the above applies non-GUI functionality (for example, if functionality gets added to the address book, it must become available in a GC and a non-GC API) and to third-party developers selling libraries to Android developers, too.

While it is likely that this is how it could play out, it is certainly possible to have a garbage collected language and a managed memory language working together in the same program (e.g. a manual memory managed C program can start an internal JVM and pass data between the two languages).