You have to make the jump to Android Studio. At a minimum, I don't think any of the Eclipse-based build tools can output the new bundle format that the play store prefers these days. I'm sure they'll change it in the future - but it definitely feels like a decade-newer development environment. And while I'm not certain, I would be surprised if the AVD (android virtual device) support is as good in eclipse.
Moving from eclipse to Android Studio / IntelliJ / Gradle is a big codebase refactor - moving nearly all the files around, refactoring references - plus moving to gradle. And, of course, it's obviously preferable to have a complete history in git. But it would take a lot of work to cleanly commit all of the operations to move from one to the other. The desire for that continuity hung me up for a while. Until I realized that the problem wasn't in the critical path: The first commit in the GrazeTen repo is the result of 'Import' into Studio of the last commit of GrazeRSS. The missing link could be filled in today or two years from now - and the only benefit is that it makes life easier for a developer who can see the entire history of a piece of code without switching contexts.
And that points out the real challenge. In the last two weeks, I've done four or five releases of GrazeTen, modernized the code base to meet my needs, triaged several issues and crashes, etc ... But I'm not an android/java developer - I'm just a maintainer. Except for a few simple fixes, most of the work was done by a freelancer that I hired at my own expense.
But there's plenty of work that still needs to be done - things I don't know how to fix, even if I could test and package. The best example is the background sync - see issue #16 in github - not only does background sync not work at all - but has caused several hundred crashes (silent to the user) with under a dozen registered apps. That code needs to be refactored to the modern job scheduler. Widgets are broken, mobilizer code seems to be hanging ... There's a few more crash reports that I haven't even triaged yet.
My point is ... if you've got a limited amount of time to spend ... assess the bang for the buck - and don't die on the hill of making a commit-perfect code repository.