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.