This class will provide an in-depth tour of the new Android build system, which was designed to elegantly deal with the diversity of the Android ecosystem and the demands of modern development practices. We will go through its concepts and features such as variant support and the latest performance improvements. The new build system is also key component to the new Android Studio, and to Continuous Integration. We will show how this makes Android Studio much more powerful than other Android IDEs. We’ll also discuss how the build system can be leveraged to build powerful CI solutions and how to integrate it into larger enterprise build processes. We will give a sneak preview of a new major version of the Gradle Android plugin which comes with another massive boost for performance, variant aware dependency management and an easier yet more powerful configuration model.
Video Transcript
Had a funny incident last night. I went back to the hotel, and went for my room. Put in the room card and nothing happened. I said did I forget my room number. Tried out a few other rooms, and was completely weird. What is going on? I went down to the reception and said, either the card is broken, or I’ve forgotten my room number. She said let me see your card. She said no, you’re in the wrong hotel. Go down. Your one is down the street. It’s one further down. I said okay. It’s not even finished this story. Then I went to the other hotel. I said wow, it looks really similar. I met a friend of mine, I haven’t seen for a while.
I just told her the story. You know what happened to me. We went up to the second floor, and we said goodbye. Then she went to her room. Well she went to my room and put her room card in the room, my room door. Then she was in the wrong hotel. She was in the one I was before, so that’s the Hampton and the Holiday Inn. That’s really funny. Okay. Deep Dive Into The Gradle Based Android System. I’m Hans Dockter. I’m the founder of Gradle, and the COO of Gradle Inc. I want to talk about the Android Build System, the deep concepts behind the Android Build System, and why it is created that way. Let’s start.
What are the goals of the Gradle Android Build System? I think it is very important to understand as an educated Android developer, what are the qualities? What are the deeper design goals of that build system. Even if you use it from Android studio. It’s still I think important to understand. Also when you compare it with other platforms. It’s also interesting to see how we are actually doing in reality in regard to our lofty goals. Or not so lofty, we’ll see. The first thing to understand. Android is a complex platform. Not quite as complex as CC Blush Plush? [CC Blush Plush? 00:02:21], but way more complex than Java.
When you look at this diagram, even if you can’t read what is in there. This is the workflow of building an Android application. You all know that you have complex, resource, and code generation right? You don’t have that in Java. You have multiple different languages. You have NDK, you have Java. You have the interface definition languages. There’s a lot there going on. You have the signing, you have the texting, plus the compiling, and so on, and so on. The original Java tools that were used to build Android Apps, were not built for that complexity.
[There was End? 00:03:07]. There was Eclipse. There was for quite a few people Maven. Right? They’re already hitting their limit in Java land. They were not made for Android. I talked about it, written the script, native calling and what not, but there is another challenge in Android land. I call it platform diversity. Others call it fragmentation. This has been one of the biggest pain points for developers to deal with. I just want to have a little variation of my app for that platform. It was very hard to implement with the build system at that time.
How to make this diversity approachable from a developer tooling perspective was a key goal for the new build system. I forgot my transitions. Okay. Here we go. What makes Gradle unique, and what is harnessed by the Gradle Android plug-in, is that you have the expressiveness to model the complexity, if you have really concise descriptions of your build. That’s something Maven to some degree was doing a reasonable job at Java land. That is a strength of Gradle. At the same time Maven is concise for simple use cases, but can’t go beyond that. Other similar kind of design systems like a Facebook back, or what not.
They are very flexible, but they expose a level of complexity to developers and build masters that is at one point, very expensive to match. Gradle tries to combine the conciseness of a declarative good language like Maven, without sacrificing the power, and the flexibility, and the extensibility that you have with Ant and Ivy. In fact, In fact, done right, if you combine, it you get even better extensibility. Now we’ll talk about that later. To give you an example of what I mean with conciseness, look at this very simple build definition for stand alone Android app. A few lines of cord. You have two product flavors.
Two dimensions. For each dimension, you have two flavors. For the version, you have a free and a paid version. For the AVI you have AIM and 86. You could now do certain definitions. What you can already do when you have such a definition, you can put code in source free, or tasks in source free, or in source paid, or source AIM, or source 86. An android knows exactly the Android build system, and what to do with it. It runs the free tasks only when you build the free APK, and so on and so on. It is a reasonably simple problem, right. This is how it is expressed. Can you read that in the last row? No I’m joking.
[00:27:45]
[00:34:52]
[00:42:52]
[00:45:24]
[00:45:37] For this little build strip, when you do Gradle tasks, all the tasks that Gradle creates to build this. You have more than 300 tasks. Imagine how the in-build would look like. Would be thousand lines of [mixed amounts? 00:06:33]. With Maven on the other hand it’s completely impossible to model this within one project. Maven would tell you well you need a separate sup project per flavor, per tasks per flavor. You would end up with a sub project, per tasks per flavor. You would end up with a sub project 30 might module maven build or something like that. Which is also kind of you know I’m an android developer. I have a little requirement, certain variance right? I want to express around my simple android app. Now I end up with a 20, 30 sub module maven build. That’s not what you want to be challenged with as an android developer. that gives you kind of an idea what has to be in your sheaf. Key mission is accomplished. Thee is now a powerful android build system, with which you can elegantly describe many of the topical requirements you have in one android building application. Including one kick-ass dependency management. It has the right mixture between flexibility and structure. Too much when you just have flexibility, you might have a lower complexity to deal with as an android developer. But if you have just structure, no flexibility, you can’t extend a thing. This is a real nice mixture. It is a true achievement by the Google Android team, who is creating and maintaining the Gradle Android plug-in. Based of course on the capabilities of Gradle, but there’s more to come. The foundation is rock solid. The feedback we’re getting back is that people are very happy with that aspect. I haven’t talked about performance yet. I want to talk about something else first. Some other goals that are behind the system. It is not good enough for most android developers it just have a good android build. You have backend services written in Java, C Plus Plus, Ruby and what not. You have other libraries to deal with. Potentially written our languages. You want to be able to integrate deeply with those during development cycles. You don’t want to be the isolated android team, like it is still today in so many organizations. The android teams are isolated from the continual delivery process of the rest of the team, and that is not good. The people writing the backend services should be able to ask the question, is this change breaking the Android App? That is often not possible, but with Gradle you now have the tool to to have a really unified build experience. Gradle is a powerful polyglot build system. With strong support for C C Plus Plus and Java, also for pythen, an interesting wrapping around the Java script Eco-system. Linked In is a very good example for that. Linked In has an Armada of languages. It all builds with Gradle in one or the other way. 40+ languages, some exotic. All build with Gradle. Either with a direct implementation or with Gradle like with Pythen adding some functionality on top of the existing Pythen food chain. They’ve also integrated a [hadook? 00:09:57] developer tooling around it. That is a big benefit your get. If you work in a team, you’re not just writing android. You have now a build system that can integrate all the different pieces much better. To give you an idea of the scope how Gradle is used in some organizations, at Linked In it is used by 2,000 engineers, and they have 300,000 Gradle Build executions per week. Their biggest Gradle build has 3,800 sub-modules. One other thing that is interesting with Linked In. Like more and more organizations, they switch from teams that have been created around technology, the android team, the ios team, to functional teams. Teams that share the backend and the different UIs in apps that are developed around a set of functionality. For them it is even much more important to have a build system that wraps around the whole functional team. Even though they’re using very different languages. Okay for talk about performance. Extensibility. It is not just good enough to solve the standard requirements, even in a polyglot setting. You get a lot of out of the box stuff from Gradle. The example projects are work right? People that are ambitious about developer productivity, and automation, and or work in a more complex environment, desperately extensibility. With the new build system, you are able to inject custom steps any where. You have deep APIs with listener frameworks, to get into the guts of the system if needed. Even in a tasks execution. You can hook in a listener with Gradle. Hey send me an event after you’ve executed the tasks method. I want to do something with it, whatever that may be. Maybe you have a fragile tasks you want to deal with. You say oh, this tasks I want to run again to make sure it really failed, what not. Whatever pathology you need to embrace as part of your work. There are powerful features to integrate deeply any other technology tool chain into your build. It’s not just extensible. You can extend it in a way that your build stays concise. You can extend a greater declarative language, with your own declarative language element to make it very easy for your developers to work with your custom requirements. Even if you say oh extensibility is not important for me. In an indirect way it is, because you will benefit from it by a very powerful plug-in Eco-system that depends on the extensibility. There are really interesting android plug-ins out there of Gradle plug-ins that you can use. Always forget my transitions. Gradle is a very strong foundation for the Android build system. It is a build platform with massive tractions. We had just crossed the one million download for the month. 9 in September. It’s evolving very fast. We had 19 feature releases in the last three years. We get large amounts of contributions, from individuals and organizations like, Linked In, Netflix, Google Android, Unity Technologies, and many more. A lot of innovation is happening, and Gradle is a generic automation platform. For whatever you want to automate, you can use it. Because you as a developer, you’re not just creating apk’s. You’re shipping software with a group of people which is a much larger scope. You might want to have auto provision depth environment. You might want to generate document for client API that your are shipping. We’re all code snippets it’s our integration tasks. That is how we ship our documentation. Every snippet in the Gradle user guide is live tasked. While we’re grading the user guide, we run the integration tasks, against the snippet in there. We extract the output of the integration tasks, and insert it into the user guide to make sure that … We don’t have the money for an editorial team, I don’t want to spend it on that. I still want to give you high quality documentation. When you really think about shipping software, there are so many tasks you can automate. Once you have a system that allows you to do that you can get really creative. You want to have a fully automated release process, you might want to have central version strategies for the libraries you’re consuming, automated database migrations, container integration, for certain integration tasks. How to deal with fragile tasks. Big problem we see in many organizations. When you have a build system that says well you can only have one proof of tasks. When some of them are fragile tasks, it usually means people start ignoring if this tasks week fails. They say Ah, yeah, okay. It might be interesting that they fails, maybe not. With great inadequacies easy to isolate, you say okay, the non fragile tasks I put in that group. They are really part of my continuous delivery pipeline. If the CI is failing here, everyone stop work and fix it. Then there’s the other group of tasks, The fragile manual taskmasters, might still use them to get some indication, but I don’t want to rely on them for my automated pipeline. Stuff like this. Or you have very time consuming suit of integration tasks. Where you want to maybe separate them into, to be integration tasks, you are integration tasks, so you get faster feedback. People that work on a database only want to execute the to be integration tasks before they commit, because they don’t want to wait another hour. There is a lot of interesting stuff in the domain of continuous delivery. It is a complex domain. Gradle is your friend. Be ambitious about automating your whole shipping process. Lets look at an example some of the nice features that how Gradle can help you in getting better in the flow and achieving a higher degree of automation. What we have here is an Asciidoctor project. Who of you knows Asciidoctor? Asciidoctor is a mark up language. More complex than mark down. It’s kind of replacing the doc quotes and the [Latas? 00:16:52] of the world. Riley is using Asciidoctor only since a couple of years I think for their books. There’s a Gradle Asciidoctor plug-in out there. Let’s look at that project. We have a source main java directory, so it’s a java project. With Asciidoctor we create a manual … Can you see that by the way … For this java library. Example.manual is the source spot for the manual. Lets look at the source spot. Here you see the Asciidoctor annotate or a mark up language. We can now tell Gradle hey turn this into an html page. We did that. Now we open the html page. As you see this Asciidoctor document now ran that in html. Now lets change the source spot of the Asciidoctor file. Let’s do something exciting. Lets go back to the command line so that again, we refresh. I don’t expect you to be excited yet. Now we do something exciting. We run the Asciidoctor file in the Gradle continues mode. –continue. What you can see now Gradle listens to any changes. If we now go back to the document … This is something really exciting … And we save it, we don’t have to rebuild. We just do a refresh and it’s updated. Of course to continue to do that, continuous mode introduce with Gradle 2.5 and we are super excited about that. Save it again. We do a refresh. Here we go. You can now see the changes were detected, so the builds were executed. The interesting thing, it’s not the first time that there is a watch solution on the market. For people doing Ruby, they had that and what not. The special thing here is that you don’t need to specify anything. You don’t … Usually all the watch solutions you need to specify. Some glot patterns what to look for, and what to do if that pattern changes. Gradle knows all that. We have a rich input output mole. You just say run this task in continuous mode, and Gradle knows exactly for what changes to look, because the input and the outputs are defined in the Gradle build if that makes sense. For developers it’s super easy right? You can do this with any Gradle task. You don’t need to configure anything for this. We use that in many places internally. Documentation is a place. Another place … For our upcoming Gradle.com offering our whole backend app is using the continuous mode. We started in continuous mode, and then whatever we change in the app is automatically picked up. The app is redeployed. It’s wonderful record application development. Think about what that means from a deeper point of view. We had a chat with Linked In. Their goal for next year is that their developers never need to directly call the build system. That is the goal for 2016. How do they are going to achieve that? That is the key tool for that. They basically will bundle a pre-configured continuous mode settings with their IDE. When the developers fire up the IDE, they not just fire up jet frame intelligence. They fire up a whole set of rules, that Gradle gets instructed with. What to watch for. When you have some source code generation, some specific one, you just fire up the IDE. It starts the continuous mode. You developers do some changes in let’s say the xml configuration fire, and , Gradle will automatically rebuild it. The developers don’t even know is its the IDE doing this. It’s that the build system doing that well. The whole thing is the IDE. Its the whole thing. I am super excited about how continuous mode can basically extend the capabilities of the classic IDE. Because finally, your IDE becomes extendable with Gradle. Who of you has ever written an eclipse nature or an eclipse builder. Who wants to do that right? intelligent is the same thing. Build systems are made for this kind of stuff. Continuous mode is super exciting super exciting capability. I’m sure we will find interesting opportunities to integrate that with Android Studio. We’ve already had a chat with the guy and we will see what comes out of that. Talking about Android Studio. One of the most important goals of the new android developer tool chain was a true android IDE that natively understands android projects. In contrast to lets say an eclipse ADT project. The other key goal was the IDE should build the same way as the command line in CI. That you have consistency and coherent quality of service of the depth tooling. If you remember the eclipse ADT had a separate build system. You had an and build, or a maven build. Whatever you have chosen. When you are working an eclipse ADT it came with it’s own tool chain. Own Merging. Own everything. That’s how you had to do it. There was no way to deeply integrate it. The goal of android studio was, the IDE is not doing any actions themselves anymore. Every action execute tasks generate sources is delegated to the underlying Gradle build. Whether you execute your build from the command line or whether you’re just working android studio, it’s exactly the same behavior. Unified build system. I talked about with Gradle you can extend now your build system. You could easily. Let’s say you’re working android studio on some wiki that shows you the quote of the day. If it’s just fun for you developers. You just use it for the debug. Debug good tag. You could now easily tell Gradle, hey I want to hook in another task while you are generating resources I want you to retrieve the quote of the day from some server and add it to the resources spot. You just add that task to your field script. If you’re working in android studio. Because android studio instructs Gradle to create a resource, you will now have in your visual design wiki, always a changing quote of the day. You get the point right? It is now fully integrated to android studio. Because android studio delegating every thing to gradle. You can now really powerfully extend your IDE. With eclipse or ADt would have been completely impossible. Separate worlds. What you do in the bill and what you do in your IDE. Your IDE is usually not extendable. The other part besides being extension aware, is the android domain is deeply modeled in Gradled it is easy for android studio to write rich information from the build spot. If you look at an example … Here we have android studio. We have two product flavors, free and paid. For what ever reason they use different version codes. They use different … For what ever reason they use dependencies, but that’s not what I want to show you. Now we go into the visual mode. Now we can change … I will have a stiff neck after this talk. You can now change … Because I don’t see that on my screen … The build variance, we choose free release. If we switch to paid debug, that is deep IDE integration. That’s fine, that’s how it should be. Okay. I want to show here. Yeah, I skipped a whole tooling API topic. We have a special library that we create so that IDEs can integrate with Gradle. Be it android studio, plain intelligent, or eclipse. Don’t need to go into detail. The only thing that is interesting, that’s the only thing I would like to mention. We support, we ourselves create the Gradle plug-in for the eclipse plug-in Eco-system, to be very clear. We only do that for java. We’re not working on android support frankly. One thing we have added is really nice. I talked about how, what a deep API Gradle has. What you can now do from eclipse, is when you go to your package or to any tasks , and you can right click it. You can say execute. You know all the visual view you then get that shows you the tasks. The execution windows for the tasks within and IDE. Classically the IDE come with their own tasks runners. Now with build chip, you have now the same visual representation. Really nice runner, that runs the tasks. Gives you a green or red button. Actually all the tasks are excited by Gradle. With the tooling AVI, we will hook into the eventing system of Gradle and can have a really nice rich full presentation at the same time. Its no longer that the eclipse has a separate tasks execution than Gradle. Think about what that means for integration tasks. I’ve been in many organizations that told the developers if you want to execute an integration tasks from your IDE you have to go to the build wiki, before you integrate your integration tasks you have to go to the command line, and execute with your Gradle and Maden build, fire up database, create database, some manual step. Then you can run the integration tasks from eclipse. Because you couldn’t extend eclipse to do this kind of stuff. Now with Gradle all the tasks we just set up is just implemented in Gradle. If you now can run your tasks executed by Gradle to Ide you don’t any build wiki. Developers don’t care. They just say run my task, and Gradle makes sure all your task picture is properly set up. Because it is extensible. Okay. To wrap this up. I want to look a little bit under the hood of certain core concepts. This is the plug- in that has Gradle hey this is an android application. We call that a declarative element. We’ll talk about that in a second. What we mean by that. First of all it constitutes certain conventions. If you tell Gradle this is an android application, if you then put certain things in certain places. Like the source codes and the tasks, as defined by the conventions, you don’t need to specify anything. Just by those few lines of code, and sticking by the conventions, Gradle will provide you all the tasks that are necessary to deal with this application. That’s what we define as the declarative element in the build script. The declarative element of the is something that specifies to what. This is an android application. The how is automatically figured out for you by Gradle. We call this the executional unit that every build system has. You don’t need to specify them directly. And is fully imperative. You as a build author, or as someone that specifies the build with and you have to do all the specification you where direct You are an executional unit, by the target. With Gradle you have declarative elements and the executional units are derived. Then you can run assemble debug and what not. The interesting thing, and this is where Gradle goes way beyond other declarative systems, you have very fine frame development elements. Build types. You can specify release type. Or we have the product flavors where you can specify free and paid product flavors. This is not like simple configurations what you’re doing here. You really using new declarative elements. What do you mean by that. When you specify I have a free product flavor, you trigger a whole little mini framework. When you specify the free flavor, Gradle will automatically create an number of tasks to deal with this free flavor. Assemble. The free apk. All the resource generation. The test task that only generates the test for this flavor. You have a certain set of conventions in place. If you now put code in source free it will be picked up. This is a very powerful element. After adding the fact that you have a free flavor, you can see all the tasks that are automatically created as part of that. For us Declarative elements are a very important concept to give you the right mixture between flexibility and structure. High level declarative elements that you can pick and choose to construct your requirements. What is a key goal for us. That you can describe it. You are the main language. We don’t make you think like a build system. You can think like an android developer, specifying what you need and we translate it into build system concepts. If you need to do some really deep customizations, hen yes you need to understand the build systems. Not for your normal work. Finally performance. Gradle Core Performance. Let’s talk about the Gradle Core performance. Unrelated to android. Just the Gradle performance as a build system. Gradle is a very build system. If you look at java and you execute25 sub modules java will just say hey, clean upgrade me . All the jobs of that. Lets do fun. I think with the latest Gradle versions will be under 2 seconds. You can do it in parallel. With the later Gradle versions it will be under one second. If you do incremental mode, you know what I mean. We always continue to work on that. This is our 200th sub mule build. Eve that if you do a full clean build is not strictly slow. Again we have improved that even since I’ve been doing code. 7 seconds for 200 sub-module builds with a lot of code is fine. W are working with some very large software stats. Extraordinary performance requirements. Our goal is to be the faster build system in the world. Especially for those large teams to bring the finally into the agile land. When you have to wait one hour until your boot finishes, you can’t do agile development. The Linked In build time got knocked down and we are integrating from half hour, from 30-40 minutes. It’s still too long we want to get it down under a minute. We want to get there with and stuff like that. There’s a lot of stuff we want to do. We want to be insanely fast even for very large products. The key message is, even if we had all those capabilities already in Gradle, that wouldn’t remove the major bottleneck with android build that you are facing now a days. Lets look at the android tool shed. You have android. Its good to be aware of those lay outs. You have the Gradle java performance is very different from the Gradle android performance. One reason is that the java compiler is very fast. Where as the dexing is not quite as fast. If the java compiler was ten times faster, and the Gradle build was ten times faster in java. You shouldn’t praise us. You would have to praise the oracle java ct. We integrate with low level tool chain. As is also the case with android. If you have bottlenecks in android tooling, its nothing , we don’t maintain those tools, we just use them At the end of the day I understand that you want fast builds. That’s what we will achieve more and more. But its still important to understand that. After android tooling that is maintained by the android platform team, you to do Gradle platform maintained by us. You have to do the Gradle android plug-in maintained by the android tooling team. You have android studio IDE also maintained by the android people. Android studio is usually never the source for any bottlenecks. Its the three layers below android studio, that have improved a lot, but will continue improve that you will have a very fast experience. Still it is important to understand there are different layers. All those teams are working closely together to achieve that goal. They are all doing a great job. It is just that you can’t do every thing at the same time. It was a lot of work to introduce the new system. It was massive, including a new IDE. Certain optimizations will follow up late rand they’re not always properly. Lets talk about Gradle. By the way this was just a tweet today . Gradle in trade went great. Incremental builds went down from 10 seconds to 5 seconds on one project. From 20 seconds to 11 on another . Always remember to upgrade to the latest Gradle versions. There are a lot of improvements at the moment coming, with every release, and we re release every 4-6 weeks. Use the Gradle demon if you are buiding from the command line, otherwise … [inaudible 00:37:59] Lets look at some number how things have improved. Lets ignore 1-200. You see the improvements we have for a 10 android. Pretty big android build. 10 soft roll jacks, 10 variance for soft roll jacks. We’ve got the build time down significant. This is not extreme, one android project with 200 variance. You can see. If you’re not on Gradle to 4, that is the minimum you should be at. Because that has dramatic performance increase. Lets talk about the existing bottlenecks. What I use as my guinea pig is the Google io android app from 2014. It is on get top. Its an open source. It is a nice guinea pig. It is pretty representative. It has a bunch of open source libraries its using. When you look if you do a clean install, at the end of the day what you’re interested in is a developer, you do some changes, and then you want to see the changes. Either you want to run your instrument task which require an install, or you want to work with the deployed application on your virtual department. The big bottlenecks dexting, predestining, and installation. That is where 90% of the time is gone. When you do a clean install. When you move everything and you build again. I want to talk a little bit about predestining. The library your android project depends on all need to be sexed. Not just your compiled source code. This is done during the pretext step. The Google android plug-in caches the ext library so that the next time you run the bill, dexting will be much faster. But if you do a clean build, this cache is always deleted. All the libraries you depend on need to be preexisted again. That’s if you look at this predestining this takes the longest time. Clean builds are heavily penalized. If you like, or first builds, because predestining all the libraries you are using take such a long time. What we want to do over the next three to six months is a couple of things. First of all the predestining of your libraries is not happening in parallel. When you have 15 libraries, one is sexed after the other. The other thing that is something we want to improve, we want to put your libraries into a cache that survives clean. Sometimes you need to do a clean. Always after you have pretext and its a pain in the neck. We want to basically put the pretext libraries into our library cache that will survive a clean. We are going to look at a cache that is much more long lived. We want to use for those predexed libraries. Of course we have to store the version of the dexting to a chain so if you upgrade to a new ext version we don’t want to use this cache version. We need to have a reliability in there, but that is something we will work on. That means the predestining will become faster because we paralyze it, and it will survive a clean. So you will have to do it much less often. Predexting that is how this is going to be tracked. What we also are going to start working on next year is a distribute cache. This means, I talked about that we put the pretext libraries into a cache on your local machine that survives a clean. The next step is to put in a cache that can be shared with all your developers. If one developer has already preexisted the library, damn, to get it. Don’t do it again. Or if your CI build has already done that, get it. All those sources will feed the distributed cache with big output. Then other members of the team don’t need to rebuild it. Which means if you are, not just the one people team right, if you have ten fifty people. Even ten people and the CI server, you will hardly every have to wait for predestining, once this is implemented. Caching pretext libraries across theme build, and paralyzing predestining will cut the amount developers need to wait for predestining by a magnitude. That’s good news. Those are the thing we want to do. This is not a most common cycle. You don’t do a clean build. You’re in Android Studio right? You say he, I did some changes, now reinstall to my device. Now the situation is like … And you only lets say changed a single class right. Still you have now no predestining any more. Now its twice as fast but still, 33 seconds. Its not paradise yet. Most times spent now on dexting and the other big chunk is install. We will continue to work on making the other bits right before dexting, all the stuff. Gradle needs to be before dexting. Configuration time, this will get faster and faster. But obviously even if we get all the other stuff down to zero, its still 75% is still there. That needs to be addressed. Not requiring to do a pretext cuts the build time in half. As said its not dominated by dexting. The problem we have at the moment, first of all dexting takes long. Its also proportional to the number of changes you did. Whether you changed one file or a hundred files, everything will always be redexed. Your whole code pack. You have non incremental slow dexting right now. There is stuff on the way to improve that. There’s not much Gradle can do, nothing at all to make dexting faster so the Google android platform team is working on a new dexting compiler called Jack. Who has heard about Jack? I don’t have any deep knowledge about Jack. I can only look at the website what they doing. The idea is it consolidates the source code compilation and dexting into one step. No longer source byte code, dalvik byte code, but directly from source to byte code. has already and experimental, incremental option that you can use. There are serious efforts happening. Incremental dexting plus predestining will lead to tremendous improvements of development. I think with a little bit more patience things will significantly improve when it comes to your performance of your development cycles. What else will the future bring? I talked about performance in detail. For us this is at the moment one of our major on the effort. Every Gradle release will be faster, and with the other changes I talked about the specific android problem that has been there, when they are gone you will have extremely fast android build. That day will come. There is already the new experimental Gradle android plugin out there. It is based on what we call the new Gradle model. Which has much faster configuration time, which will eventually give you parallel task execution. Its still very experimental. Its open source so you can use it. To see what the future will give you. The benefits you have already in this new plugin are significant performance wise. The new android plugin, just the configuration time for ten android projects with ten variance with the next generation android plugin is already cut down by fact of 3 and more to come. Extensibility is already the very strength of the build platform. Especially android is pushing our extensibility to a certain degree. We have the Gradle platform. We have Gradle plugin by some group who is testing Gradle in the cloud. Like Testroid. Then we have organizations that do their own tensions. When you have this type of extension hierarchy, We now put you sometimes in the situation that you need to do some work around to get the configuration order right and stuff like that. We want even in this very complex extension scenario we want to provide you more solid extension model. That’s something we’re working on. Even if you don’t use it Directly you can benefit from the Eco system. The Eco system can work better for yew. Dependency Management. We want to support fully where in work dependency management, so that you can basically have android libraries, and java libraries that are aware not just of their version but also is this debug release type library for NDK. Is it 64 bit, is it 32 bit? To make that a first class solution when you do Dependency resolution. That is exciting work. CC Plus Plus is a very important platform for us. We are partnering for example with unity technology, who are by grading the whole native stack towards Gradle. The K support in the new experimental android plugin will no longer be based on make but on the gradle cc plus plus plugin. Were very excited about that. You will have a similarly rich declarative language to describe your native build requirement. Who is doing any NDK work? That should be really nice. Okay last but not least. We are releasing assess offering very soon that allows you to connect your local or Ci build. All of your Gradle builds in your organization with our assess offering. This service will help you with understanding why something is wrong with your build. Or helps the developer to understand why the build is not happy with the code. Why the tests are failing and things like that. Why is it working locally, and why is CI failing. Those kind of questions. Very excited about that. If you’re interested please sign up for the beta wait list. You should be … Hopefully November we can have a full gamit of that product. If you want to learn more about how to work with Gradle for android, there is now an excellent duacity class online. The udacity class we have created together with Google and udacity, its free. I think its now over 10,000 people that have signed up. Udacity is amazing. Who has ever taken a udacity class? I think its the best online class experience I ever had. This class is really really good. Might be interesting for you. Might be interesting for some of your colleagues. Its really good. Perfect start into Gradle land. We offer our own training, for if you want to get deeper into Gradle. We have introductory and intermediate classes. But also very advanced classes. All delivered by Gradle core engineers. The people that deeply understand the platform. Okay that’s it. Thank you. Andy questions? Questions? Yes please. Our classes are not free. We are not Google. And the different is they are instructor led, so udacity class is … So you can ask questions. You get a good teaching experience but you can also ask the Gradle questions you always wanted to ask. Yes please [inaudible 00:51:54] Please and you say it again? Yeah. Yes. Its a good point. Understand it is something you would need to ask the android tooling team. It’s beyond… Its a dud point but I would ask it on android deaf list what their plans. If there any plans. Yes. Not yet, but it will be coming. Its a very good point. Just to understand you and the consumers for that would be new developers you are hiring, your team? Yeah. Yeah. Yes. Yes. No its a good point. Yes we understand that used case, and we will provide something. Don’t read the menu=u you won’t find anything in it right now. You will find other interesting stuff in there but … Strictly speaking, j think it would take you, someone who knows a little bit about Gradle, one hour to create a login that would print out that information on the consult. At least you could do something about it. Not that we shouldn’t do it. Don’t misunderstand that. But Gradle is so open and so rich that you don’tmeed to create secret master knowledge to do that. You could do that in a pretty straight forward way actually. Yeah so you could ask the Gradle android build with the gradle plug in Hey … All those sources are represented by rich object. You can say main sources object please tell me what is the path to the java 5. Or what is the path to the resource 5. Because its all in there. You can print it out. Because it is all richly modeled. Hey Marion content, do you have some Marion. Hey free Marion tell me where are the sources for the free varien. Where are the resources? Where the integration test? I’m not even exaggerating, would be one hour, and would be on the console. Because it is richly modeled within. There is no magic property. Because that is what we hate. We hate something. Its something made up and there is some matching property half coding in the build script. No its all changeable and accessible. But yes, we should come with this out of the box. My fliers going no. Seriously thinking about it just thinking about my schedule might not have. I need to go to the airport. Maybe I hack it up on the way back on the plan. Yes please. Yeah the big accountability issues we had in the past . To be fair was when the gradle android plugin was ordered something. They were deliberately. They were by design . It was a long period until we got to 1.0 with the gradle android plugin. But in terms of the contract it was okay to break. But since 1.0 is out, I think it is extremely compatible. Because we are extremely backwards compatible. What they were doing before 1.0 they were always going to work closely together. They said to make this really good, we need a feature that is only in 2.0 or only in Gradle 2.1. Therefore it didn’t work. The next version of the android plugin didn’t work with an earlier version of Gradle, until they had reached 1.0 where they have invest more into backwards compatibility. But that was the reason. Gradle itself is extremely backwards compatible. We have a massive test suite. 16,000 tests. We run it every night against all different versions, and against cross version of gradle testing. That’s something the people usually very happy with. That’s the only reason why we can release so often. If we would break people … Imagine a team like Linked In with a team of 2,000 engineers. If you break them two times a year they’ll say well thank you very much. Then they would stop upgrading. We can only have that speed if you have the quality in that respect.
The post Deep Dive Into the Gradle Based Android Build System appeared first on Gradle.