Future of ADT

[Csaba Kozák]

Can we get an official statement about the future of ADT? From the outside it seems ADT is a little-bit abandoned project. It does not get any improvements, only the most crucial updates to stay compatible with the new SDKs. With ADT 23, even the compatibility updates were missing, it was released with lot of bugs, really core functionality are broken. I know the tools team puts really great effort to build Android Studio and the new build system, but it seems that just leaves no resources for the ADT.
So my question is: Should we count on ADT in the future, or it is wise to start to migrate our projects and workflow to ADT. I love Eclipse personally, so i do not want to switch to AS only i really have to, but if ADT will be no longer supported i guess i won't have any other options.

[Avram Lyon]

Csaba--

The closest I've heard to an official answer was at the Fireside Chat at Google I/O: https://www.youtube.com/watch?v=K3meJyiYWFw

They pretty much said that the Eclipse-based ADT is not going to be maintained by the tools team, at least not in terms of new feature development. They didn't specifically indicate that compatibility will not be maintained, but I suspect that is going to eventually go away as well, hopefully not before the final release of AS.

- Avram

[Xavier Ducrohet]

23 is clearly broken. We are working to fix this. The last thing we want to do is break existing ADT users and we clearly failed here.

23.0.1 is a first fix for this. Expect another one sometimes next week.

For new features, our focus is Studio.

On Sun, Jun 29, 2014 at 4:37 AM, Csaba Kozák <kozak...@gmail.com> wrote:

Can we get an official statement about the future of ADT? From the outside it seems ADT is a little-bit abandoned project. It does not get any improvements, only the most crucial updates to stay compatible with the new SDKs. With ADT 23, even the compatibility updates were missing, it was released with lot of bugs, really core functionality are broken. I know the tools team puts really great effort to build Android Studio and the new build system, but it seems that just leaves no resources for the ADT.
So my question is: Should we count on ADT in the future, or it is wise to start to migrate our projects and workflow to ADT. I love Eclipse personally, so i do not want to switch to AS only i really have to, but if ADT will be no longer supported i guess i won't have any other options.

--
You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Xavier Ducrohet
Android SDK Tech Lead
Google Inc.
http://developer.android.com | http://tools.android.com

Please do not send me questions directly. Thanks!

[Csaba Kozák]

Thanks for both of your answers!

I should not have bring the problems of SDK 23 here. It affects the Gradle build system too, also i was sure that you guys will fix it. Thanks for the first patch, appreciated!

Xavier is very, very diplomatic, but i guess this means ADT will indeed go away. I think it may be too much to expect maintaining both of the IDEs, i just a little but confused about the lack of information about ADT here.

[Kevin Schultz]

I think the future of Eclipse+ADT is pretty clear to anyone following the development of Android Studio. It is going to be a second class citizen at best. I honestly hope that it gets killed off completely so as not to pull resources away from Studio development. The lack of clarity on this is a big problem though.

I was a bit surprised to find out how many developers have not yet switched to Gradle / Android Studio. I took an informal poll at a NYC Android Developers meetup this spring and from the show of hands it was about 50/50 Eclipse+ADT vs Android Studio. That night we gave 2 talks on why you should switch to Studio & on how to use Gradle, and I know that gave some people the nudge to switch over, but I was really expecting more people to have switched. 

I think the people that haven't yet switched fall into two camps.

#1) Eclipse users. A couple years ago I was at a company that wrote Eclipse plugins, so you can imagine that I'm a pretty big fan of Eclipse. I had never tried IntelliJ at all prior to Android Studio. Switching seemed of dubious value, even though I had heard from a lot of Java developers that IntelliJ was superior. Having now made the switch, I vastly prefer IntelliJ. The refactoring tools are better, and the stability of the IDE is much better. But I think there will be a lot of developers that no matter what the feature set of the Android tools just don't want to learn IntelliJ after years of using Eclipse. I have never met anyone that has used IntelliJ extensively but still prefers Eclipse, but I have met many that simply have never used IntelliJ and don't want to invest the time to learn something new. I don't think there is much the Android tools team can do about getting this group of people to switch other than officially killing off the Eclipse plugin. Some people won't be happy, but you can't please everyone.

#2) Those that think Android Studio + Gradle are not yet stable enough. I think this is the bulk of those that haven't yet switched, and I think this is largely a result of the messaging from the tools team. 

My personal experience has been extremely positive. My team was trying out Studio after each release since I/O 2013, and we started getting everything in our app working sometime in August 2013. We switched our master branch over to Gradle and all team members switched to Android Studio in about October 2013. Since then we have been using Android Studio all day every day for production work and haven't looked back. We have lost maybe 2 full days spread over the last 8 months to fixing things after changes to the Gradle plugin causing us to have to rework our build files. That is not a big deal in light of the fact that all of the features in Gradle have saved us a massive amount of time: switching our dependencies to Maven instead of git submodules, package naming, build config, build variants, etc. Perhaps most importantly, Android Studio itself is significantly more stable today than Eclipse + ADT ever was. 

But up until I/O 2014 the developer.android.com documentation was effectively a link to the download page with a big red warning that this wasn't for production use. A lot of people are taking that at face value and not even trying Studio. The "beta" tag and better documentation that was posted will help, but I still don't think it is enough. The impression of Studio from those that haven't tried it is that it crashes all the time, or that Gradle changes all the time (and yes, it changes, but generally it's not hard to keep up with).

Android Studio is the better option for production development today. From what I can tell, most of the really good teams are using Android Studio + Gradle or IntelliJ + Maven already. If it's good enough for the use of teams making apps for millions of users, then we shouldn't be discouraging developers from using Studio. I think larger teams have the resources to try out multiple build systems and IDEs and do their own cost/benefit analysis. Generally the conclusion is that Studio is better than Eclipse/ADT/Ant, and a polished IntelliJ + Maven setup is comparable or better than Studio at this time. But individual developers and new entrants to the platform don't have that luxury. They go by what the documentation recommends, and right now, even with the changes after I/O 2014, I think it pushes people towards Eclipse + ADT. 

That is unfortunate because individual developers and hobbyists will benefit the most from Studio + Gradle. The ease of pulling in dependencies & leveraging libraries is highly valuable to newcomers to the community. All of the additional Android refactoring tools & the improved visual design tools makes individual developers more productive and eliminate bugs. And learning 2 tools over the next 2 years is a waste of time for people that are already trying to learn the entire Android platform. I think Google is being overly conservative with pushing the new tools and dramatically underestimating the costs of the current status quo. 

I think Google should make it clear that they endorse Studio over Eclipse+ADT for use today. I imagine there was a lot of thought put into the exact wording on the developers site, but "[Studio] will be the official Android IDE once it's ready" is not a strong vote of confidence. In my opinion, in addition to the wording about the fact that in the future it will be the official IDE, it should be clear that it is in use by many developers already and that the Studio is plenty stable (in fact, more stable than Eclipse). The only downside to using Gradle is that the API is evolving and you sometimes have to update your build.gradle files. That's not a big ask from developers in the context of everything else that is constantly evolving in the ecosystem. 

And if Google intends to sunset Eclipse+ADT when Studio is "ready", that should be in the current messaging as well. Right now the cost/benefit question is 'are the new features worth the cost of learning a new tool'. If you know that you will have to switch eventually, then it changes your thought process to 'well I have to learn this someday anyway, and I'll get the new features today'.

[Csaba Kozák]

Actually i currently use Eclipse + ADT + Maven. :) I also contributed several features to m2e-android, which brings Maven to ADT.
Using the Ant based ADT without proper dependency managament is clearly much-much less usable then AS and Gradle, but it also applies to an Eclipse + Maven setup.

I cannot agree you more about Google should really make a more clear statement.

[Mark Murphy]

On Wed, Jul 2, 2014, at 11:18, Kevin Schultz wrote:
> I have never met anyone that has used
> IntelliJ extensively but still prefers Eclipse

I do not know how you define "extensively", but I definitely have met
people who do not like IntelliJ. There are developers who use NetBeans
too, or no IDE at all.

> #2) Those that think Android Studio + Gradle are not yet stable enough. I
> think this is the bulk of those that haven't yet switched, and I think
> this
> is largely a result of the messaging from the tools team.

#3) People who have limited English literacy. Android Studio knowledge
is thin on the ground even in English, compared with Eclipse.

#4) People who have limited Java experience (or, in many cases, limited
programming experience). Again, there is a lot more written about
Android development with Eclipse than there is with Android Studio.

Etc.

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 5.9: Now With
More Gradle!

[Justin Breitfeller]

> From what I can tell, most of the really good teams are using Android Studio + Gradle or IntelliJ + Maven already.

I think that is a bit early to say. I would say we are a "good" team, but we haven't successfully been able to migrate over due to our builds simply not working in gradle. In fact, I would guess that there are many developers who have tried to switch to gradle but failed due to some issue. For example, our team's app collection is what I would consider a "large" project (+1,000,000 lines of code), and we have tried switching to gradle on 3 ocassions. We are actually in the middle of a conversion attempt right now but we may not be able to complete the conversion because gradle won't build a few of our projects unless we run assemble on it twice. Why this happens, I have no idea.

I am confident the bugs will all be solved with the new build system, but it still isn't ready for prime time. I think the Google developers are just being responsible and waiting for gradle to be ready before wasting peoples time if things don't work. Trust me when I say, I am eager to move away from the bear that is Eclipse. We deal with crashes on an almost daily basis. 

[jdONeill gMail]

Another showstopper to full migration is lack of NDK support with
Studio, specifically NDK Debugging. It is not clear to me what the
migration pattern will be for developers who require NDK debugging.

[Xavier Ducrohet]

What's going on with your projects? Do you have custom logic in there?

I'm interested in helping you figure out the need to call assemble twice.

On Wed, Jul 2, 2014 at 10:40 AM, Justin Breitfeller <mrs...@gmail.com> wrote:

> From what I can tell, most of the really good teams are using Android Studio + Gradle or IntelliJ + Maven already.

I think that is a bit early to say. I would say we are a "good" team, but we haven't successfully been able to migrate over due to our builds simply not working in gradle. In fact, I would guess that there are many developers who have tried to switch to gradle but failed due to some issue. For example, our team's app collection is what I would consider a "large" project (+1,000,000 lines of code), and we have tried switching to gradle on 3 ocassions. We are actually in the middle of a conversion attempt right now but we may not be able to complete the conversion because gradle won't build a few of our projects unless we run assemble on it twice. Why this happens, I have no idea.

I am confident the bugs will all be solved with the new build system, but it still isn't ready for prime time. I think the Google developers are just being responsible and waiting for gradle to be ready before wasting peoples time if things don't work. Trust me when I say, I am eager to move away from the bear that is Eclipse. We deal with crashes on an almost daily basis.
 

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Justin Breitfeller]

Xavier,

Sorry about not going into further detail. I was going to make a separate post detailing the issue. I can do it here.

The problem seems to focus around the "build" folder in the root of our build directory. Essentially, if we delete the build folder and run assemble, we get a "Cannot access class error". The class it cannot find exists inside a jar in the libs directory of the OsmMaps project.
If we run assemble again, however, the application builds without error.

Just as a visual aid to our project structure

 Root
     build (<-- the root build folder)
     Lib 1
     Lib 2
     App_SDK
     OsmMaps
     MyProblemProject


The following is my gradle file. As you may notice, the only custom logic we have involves a 'provided' dependency and turning off manifest merging:

-----------------------Gradle file -----------------
apply plugin: 'android'

dependencies {
    compile fileTree(dir: 'libs', include: '*.jar')
    compile project(':OsmMaps')
    compile project(':Lib1')
    compile project(':Lib2')
    provided project(':App_SDK')
}

android {
    applicationVariants.all { variant ->
        variant.javaCompile.classpath += configurations.provided
        variant.processResources.manifestFile = file('AndroidManifest.xml')
        variant.processManifest.enabled=false
    }

    compileSdkVersion 17
    buildToolsVersion "19.1.0"

    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src']
            resources.srcDirs = ['src']
            aidl.srcDirs = ['src']
            renderscript.srcDirs = ['src']
            res.srcDirs = ['res']
            assets.srcDirs = ['assets']
        }

        // Move the tests to tests/java, tests/res, etc...
        instrumentTest.setRoot('tests')

        // Move the build types to build-types/<type>
        // For instance, build-types/debug/java, build-types/debug/AndroidManifest.xml, ...
        // This moves them out of them default location under src/<type>/... which would
        // conflict with src/ being used by the main source set.
        // Adding new build types or product flavors should be accompanied
        // by a similar customization.
        debug.setRoot('build-types/debug')
        release.setRoot('build-types/release')

[Justin Breitfeller]

Sorry I am getting this information relayed from one of my coworkers. The exact error we get is:

error: cannot access NonAcceleratedOverlay
public class MyProjectOverlay extends SomeBaseClass
^
class file for org.osmdroid.views.overlay.NonAcceleratedOverlay not found

[Ricardo Gladwell]

On Tuesday, 1 July 2014 02:20:31 UTC+1, Xavier Ducrohet wrote:

For new features, our focus is Studio.

One of the most important features we would like to see if the Eclipse ADT is support for AAR libraries. Is this still on the cards?

-- @rgladwell

[vogella]

On Wednesday, July 2, 2014 6:16:24 PM UTC+2, Mark Murphy (a Commons Guy) wrote:

On Wed, Jul 2, 2014, at 11:18, Kevin Schultz wrote:
> I have never met anyone that has used
> IntelliJ extensively but still prefers Eclipse

I do not know how you define "extensively", but I definitely have met
people who do not like IntelliJ. There are developers who use NetBeans
too, or no IDE at all.

 

AFAIK decisions within Google are data driven and I assume they collect the download data of their IDEs. Would be interesting to know the distribution of people download / installing ADT vs. Android Studio. 

Best regards, Lars

[b0b]

Eclipse + ADT  being slowly abandonned is worrying me.

I'm an happy Eclipse user. I don't want to switch to another IDE.
Eclipse + ADT has been extremely reliable for a long time now.

My somewhat complex project builds reasonnably fast with ADT.
I don't even know if I could build it with gradle as some of the dex code is loaded dynamically
at runtime which is known to break (or not play nice) with building tools.
I could workaround this with ADT, not sure I could with gradle.

And I use Eclipse for more than just Android developement (GWT, some C/C++ code, ...) and I don't want to run 2 IDEs.

Please, maintain ADT in a working state for future versions of Eclipse.

[Guy Tavor]

Our source code contains roughly 50 different android apps.

We are fairly early adapters, and do not mind switching over to Studio and go through the necessary learning curve.

We even started trying to do all of our production builds using gradle for quite some time now.

However, we can't go 100% studio because there are two features we use that are not supported yet by Studio/Gradle yet- NDK support and Google's support library 8 (for renderscript) support. Without these two features, we just can't even bulid using gradle.

In addition, since gradle settings include many projects, builds are painfully slow. We need some kind of a standard "configuration tool" that, based on our products' lib dependencies, configures the settings.gradle file to include only the libraries that actually needs to be built.

In any case, the tools team (and specifically Xavier) is doing a great job communicating and handling issues [especially compared to other dev related teams for Google products]. So we have a good feeling that once they give us the "please migrate now" signal, we will have adequate support doing so.

[Massimo Montecchi]

Please, maintain ADT in a working state for future versions of Eclipse.

[Massimo Montecchi]

Please, maintain ADT in a working state for future versions of Eclipse.!!!

[Ralph Bergmann | the4thFloor.eu]

Am 11.05.15 um 17:55 schrieb Massimo Montecchi:

> Please, maintain ADT in a working state for future versions of Eclipse.

see https://github.com/eclipse/andmore and
http://www.vogella.com/tutorials/EclipseGradle/article.html

[Lars Vogel]

> http://www.vogella.com/tutorials/EclipseGradle/article.html

Currently the Eclipse Gradle tooling cannot import Android projects, the current focus is the support of Java projects. Android support seems planned for the 1.0 release, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=467424#c1

For those of you, which are interested in the Gradle tooling for Eclipse, please test it (installation is described in the above link) and report bugs via: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Buildship 

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/RWu6uidXJOE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.

[Radim Kubacki]

2015-05-26 11:36 GMT+02:00 Lars Vogel <lars....@gmail.com>:

> http://www.vogella.com/tutorials/EclipseGradle/article.html

Currently the Eclipse Gradle tooling cannot import Android projects, the current focus is the support of Java projects. Android support seems planned for the 1.0 release, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=467424#c1

FWIW the comment says 'Supporting Android will not be addressed in Buildship 1.0.' So perhaps later.

-Radim

For those of you, which are interested in the Gradle tooling for Eclipse, please test it (installation is described in the above link) and report bugs via: https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Buildship 

2015-05-26 10:20 GMT+02:00 Ralph Bergmann | the4thFloor.eu <ra...@the4thfloor.eu>:

Am 11.05.15 um 17:55 schrieb Massimo Montecchi:
> Please, maintain ADT in a working state for future versions of Eclipse.

see https://github.com/eclipse/andmore and
http://www.vogella.com/tutorials/EclipseGradle/article.html

--
You received this message because you are subscribed to a topic in the Google Groups "adt-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/adt-dev/RWu6uidXJOE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to adt-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "adt-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+u...@googlegroups.com.