That is the elephant in the room. While we've opened the door to an Eclipse based solution for Android, but there is no denying how complicated a task it is especially as you mention Andrew as the Android SDK evolves and shifts away from the foundation Andmore was originally built upon.
I think that is what is driving the IDE world to a much more modular approach where components can be shared between different IDE front ends. We've used that to our advantage with CDT where we rely as much as we can on the SDK to provide tools and the IDE becomes an integration exercise (thus the 'I' in IDE I guess :)). And now we're seeing it with the language servers. The IDE becomes a shell with a small number of well defined integration points that makes it so much easier to take in new directions.
Andmore on the other hand is massive and is highly coupled with Eclipse APIs. I really wonder whether the Android community needs to take a step back and re-envision what they really want in an IDE, especially if they don't like Android Studio and find it too hard to become an Andmore contributor. How would they build an IDE knowing what they know today and what's coming in the future. Lars mentions Flutter. I have React Native on my list of things to learn. Gradle is clearly the future for Android SDK builds. The IDE needs to be ready to adapt to wherever developers go.