What is the added advantage of using Bazel over Gradle? [closed]
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:
Experimental Bazel Support
Some of these samples can be built with Bazel on Linux. These samples contain a
BUILD.bazel
file, which is similar to abuild.gradle
file. The external dependencies are defined in the top level WORKSPACE file.
This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.
Then,
- What is the added advantage of using Bazel over the existing Gradle?
- Is it really good to have TWO build tools for Android?
- Does it mean that Android developers will probably need to learn this new build tool in future?
Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.
Update #2: Updated with google code labs for bazel android introduction.


closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
add a comment |
I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:
Experimental Bazel Support
Some of these samples can be built with Bazel on Linux. These samples contain a
BUILD.bazel
file, which is similar to abuild.gradle
file. The external dependencies are defined in the top level WORKSPACE file.
This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.
Then,
- What is the added advantage of using Bazel over the existing Gradle?
- Is it really good to have TWO build tools for Android?
- Does it mean that Android developers will probably need to learn this new build tool in future?
Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.
Update #2: Updated with google code labs for bazel android introduction.


closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
2
Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…
– Jignesh Patel
Jan 3 at 6:13
Does Google has a road map of migrate Android development from Gradle to Bazel?
– shizhen
Jan 4 at 1:53
@shizhen No, but there are codelabs for you to try it out.
– Jin
Jan 9 at 17:30
add a comment |
I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:
Experimental Bazel Support
Some of these samples can be built with Bazel on Linux. These samples contain a
BUILD.bazel
file, which is similar to abuild.gradle
file. The external dependencies are defined in the top level WORKSPACE file.
This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.
Then,
- What is the added advantage of using Bazel over the existing Gradle?
- Is it really good to have TWO build tools for Android?
- Does it mean that Android developers will probably need to learn this new build tool in future?
Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.
Update #2: Updated with google code labs for bazel android introduction.


I was reading about the Android Testing Samples project and noticed that a "new" build tool named Bazel is being used for building Android projects:
Experimental Bazel Support
Some of these samples can be built with Bazel on Linux. These samples contain a
BUILD.bazel
file, which is similar to abuild.gradle
file. The external dependencies are defined in the top level WORKSPACE file.
This is experimental feature. To run the tests, please install the latest version of Bazel (0.12.0 or later) by following the instructions on the Bazel website.
Then,
- What is the added advantage of using Bazel over the existing Gradle?
- Is it really good to have TWO build tools for Android?
- Does it mean that Android developers will probably need to learn this new build tool in future?
Update #1: Updated with accepted answer from farhana and thanks to Jin for the in depth details about the google build systems.
Update #2: Updated with google code labs for bazel android introduction.




edited Feb 22 at 8:16
shizhen
asked Jan 3 at 5:08


shizhenshizhen
4,13441337
4,13441337
closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as primarily opinion-based by Mark Rotteveel, Larry Shatzer, TylerH, Bob Dalgleish, David Maze Jan 18 at 19:04
Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.
2
Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…
– Jignesh Patel
Jan 3 at 6:13
Does Google has a road map of migrate Android development from Gradle to Bazel?
– shizhen
Jan 4 at 1:53
@shizhen No, but there are codelabs for you to try it out.
– Jin
Jan 9 at 17:30
add a comment |
2
Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…
– Jignesh Patel
Jan 3 at 6:13
Does Google has a road map of migrate Android development from Gradle to Bazel?
– shizhen
Jan 4 at 1:53
@shizhen No, but there are codelabs for you to try it out.
– Jin
Jan 9 at 17:30
2
2
Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…
– Jignesh Patel
Jan 3 at 6:13
Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…
– Jignesh Patel
Jan 3 at 6:13
Does Google has a road map of migrate Android development from Gradle to Bazel?
– shizhen
Jan 4 at 1:53
Does Google has a road map of migrate Android development from Gradle to Bazel?
– shizhen
Jan 4 at 1:53
@shizhen No, but there are codelabs for you to try it out.
– Jin
Jan 9 at 17:30
@shizhen No, but there are codelabs for you to try it out.
– Jin
Jan 9 at 17:30
add a comment |
2 Answers
2
active
oldest
votes
Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:
- Bazel configuration files are much more structured than Gradle’s,
letting Bazel understand exactly what each action does. This allows
for more parallelism and better reproducibility.
Bazel Build Files
Bazel operates off of two configuration files: BUILD
and WORKSPACE
The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.
The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:
Gradle Build Files
The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.
The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:
Things that Bazel does really well include:
bit for bit reproducibility. This is EXCELLENT.
Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.
Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.
Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.
Bad about bazel
Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.
Conclusion:
There is a similar level of functionality between these two build
formats, and it becomes apparent that the two systems are made with
different philosophies. Bazel provides a structured system that is
easy to reason about and provides a strong, functional foundation for
large and growing products. Gradle, on the other hand, offers a
flexible, stateful, object-oriented interface that may feel familiar
to those who don’t frequently use scripting languages.
For more references:
- gradle team perspective on bazel
- differences between bazel and gradle builds
- what is gradle in android studio
add a comment |
I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:
- Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.
- Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.
- Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.
- Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.
- Bazel has a built in command called
mobile-install
, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.
Is it really good to have TWO build tools for Android?
There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.
Having the option to try out different approaches, IMO, is a good thing.
Does it mean that Android developer probably need to learn this new build tools in future?
Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
1
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
2
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:
- Bazel configuration files are much more structured than Gradle’s,
letting Bazel understand exactly what each action does. This allows
for more parallelism and better reproducibility.
Bazel Build Files
Bazel operates off of two configuration files: BUILD
and WORKSPACE
The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.
The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:
Gradle Build Files
The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.
The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:
Things that Bazel does really well include:
bit for bit reproducibility. This is EXCELLENT.
Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.
Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.
Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.
Bad about bazel
Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.
Conclusion:
There is a similar level of functionality between these two build
formats, and it becomes apparent that the two systems are made with
different philosophies. Bazel provides a structured system that is
easy to reason about and provides a strong, functional foundation for
large and growing products. Gradle, on the other hand, offers a
flexible, stateful, object-oriented interface that may feel familiar
to those who don’t frequently use scripting languages.
For more references:
- gradle team perspective on bazel
- differences between bazel and gradle builds
- what is gradle in android studio
add a comment |
Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:
- Bazel configuration files are much more structured than Gradle’s,
letting Bazel understand exactly what each action does. This allows
for more parallelism and better reproducibility.
Bazel Build Files
Bazel operates off of two configuration files: BUILD
and WORKSPACE
The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.
The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:
Gradle Build Files
The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.
The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:
Things that Bazel does really well include:
bit for bit reproducibility. This is EXCELLENT.
Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.
Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.
Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.
Bad about bazel
Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.
Conclusion:
There is a similar level of functionality between these two build
formats, and it becomes apparent that the two systems are made with
different philosophies. Bazel provides a structured system that is
easy to reason about and provides a strong, functional foundation for
large and growing products. Gradle, on the other hand, offers a
flexible, stateful, object-oriented interface that may feel familiar
to those who don’t frequently use scripting languages.
For more references:
- gradle team perspective on bazel
- differences between bazel and gradle builds
- what is gradle in android studio
add a comment |
Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:
- Bazel configuration files are much more structured than Gradle’s,
letting Bazel understand exactly what each action does. This allows
for more parallelism and better reproducibility.
Bazel Build Files
Bazel operates off of two configuration files: BUILD
and WORKSPACE
The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.
The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:
Gradle Build Files
The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.
The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:
Things that Bazel does really well include:
bit for bit reproducibility. This is EXCELLENT.
Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.
Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.
Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.
Bad about bazel
Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.
Conclusion:
There is a similar level of functionality between these two build
formats, and it becomes apparent that the two systems are made with
different philosophies. Bazel provides a structured system that is
easy to reason about and provides a strong, functional foundation for
large and growing products. Gradle, on the other hand, offers a
flexible, stateful, object-oriented interface that may feel familiar
to those who don’t frequently use scripting languages.
For more references:
- gradle team perspective on bazel
- differences between bazel and gradle builds
- what is gradle in android studio
Bazel is a subset of the internal Google build system called Blaze. As such, Bazel has evolved to solve a very big problem that is somewhat (but perhaps not entirely) unique to Google:
- Bazel configuration files are much more structured than Gradle’s,
letting Bazel understand exactly what each action does. This allows
for more parallelism and better reproducibility.
Bazel Build Files
Bazel operates off of two configuration files: BUILD
and WORKSPACE
The presence of a BUILD file tells Bazel that it is looking at a package of code — this package of code includes the current directory and any subdirectories within it, unless the subdirectory contains a build file.
The WORKSPACE file is written in the BUILD language, and, like BUILD files, there can only be one WORKSPACE in a package. The purpose of the WORKSPACE file is to track the external dependencies of a project. Each external dependency is added to the WORKSPACE using rules — the following is an example:
Gradle Build Files
The Gradle build system uses several files: build.gradle, settings.gradle and gradlew. Rather than running each build step in scripted sequence as Bazel does, Gradle handles build step configuration using Groovy, an object-oriented language related to Java.
The build.gradle file defines the configuration and execution phases of a build, separating between the two using objects. Execution orders of the script are defined as such:
Things that Bazel does really well include:
bit for bit reproducibility. This is EXCELLENT.
Technology agnostic intra-package builds. Do you have some python that depends upon some C code? Some Java that requires javascript for the front-end? Bazel can do that, and it is one of the few open source build systems that can.
Enabled by its reproducibility, Bazel can cache build results and only rebuild what it needs to. This makes it FAST.
Bazel is FLEXIBLE. It has its own domain language, so you can extend it to support whatever you need to build, whether the creators have heard of it or not. Want to “build” (syntax check and test) Javascript?Java? C? C++? Objective C? Fortran? Brainfuck? NO PROBLEM. If it isn’t already implemented, you can implement it. If you don’t like how it works, you can write your own. Want to use a custom compiler? A custom static checker? A custom test harness? No problem. The world is your oyster.
Bad about bazel
Bazel is not real dependency management. It manages WHAT your dependencies are, but not which versions to use. If you have everything in your entire dependency tree checked into one big monolithic code repository (like Google does with their fork of perforce), then that’s just fine. “The google way” is to build everything at tip all the time, and never to depend upon older versions.
Conclusion:
There is a similar level of functionality between these two build
formats, and it becomes apparent that the two systems are made with
different philosophies. Bazel provides a structured system that is
easy to reason about and provides a strong, functional foundation for
large and growing products. Gradle, on the other hand, offers a
flexible, stateful, object-oriented interface that may feel familiar
to those who don’t frequently use scripting languages.
For more references:
- gradle team perspective on bazel
- differences between bazel and gradle builds
- what is gradle in android studio
edited Jan 6 at 12:35


shizhen
4,13441337
4,13441337
answered Jan 3 at 6:22


FarhanaFarhana
2,70552335
2,70552335
add a comment |
add a comment |
I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:
- Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.
- Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.
- Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.
- Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.
- Bazel has a built in command called
mobile-install
, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.
Is it really good to have TWO build tools for Android?
There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.
Having the option to try out different approaches, IMO, is a good thing.
Does it mean that Android developer probably need to learn this new build tools in future?
Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
1
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
2
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
add a comment |
I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:
- Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.
- Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.
- Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.
- Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.
- Bazel has a built in command called
mobile-install
, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.
Is it really good to have TWO build tools for Android?
There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.
Having the option to try out different approaches, IMO, is a good thing.
Does it mean that Android developer probably need to learn this new build tools in future?
Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
1
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
2
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
add a comment |
I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:
- Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.
- Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.
- Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.
- Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.
- Bazel has a built in command called
mobile-install
, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.
Is it really good to have TWO build tools for Android?
There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.
Having the option to try out different approaches, IMO, is a good thing.
Does it mean that Android developer probably need to learn this new build tools in future?
Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.
I'm the author of the Bazel support in that repository, and I work on the Bazel Android rules team. farhana has written an amazing answer already, but I just want to add on a few points:
- Bazel is the build system used internally at Google, and that means it's the same build system used to build Google apps like YouTube, Gmail, and Photos.
- Some of these Google apps are huge, and will take Bazel very long to build them locally. Therefore, there's a remote execution feature in Bazel (on top of a remote cache like Gradle has, but more fine-grained IIUC) that allows you to fan out your build actions to a remote farm of executors. Bazel has a static and hermetic dependency graph of actions that is designed to be fully reproducible, with each action having a fully declared set of inputs, outputs, environment variables, command lines, and additional knowledge within Bazel about configuration, toolchains and host/target/execution platform. With this graph, Bazel can safely farm out actions to remote workers, enabling very large degrees of parallelism. I have successfully built the Tensorflow Android app with 500-800 parallel jobs on Google Cloud Remote Build Execution before.
- Automated test discovery. Bazel's static graph also encodes the dependencies between tests, binaries/libraries and data, so making a change in your source files automatically invalidates all tests that depend on them. This tells Bazel to rerun the tests, and skip the cached ones if they do not need to run again. And yes, you can use remote execution with tests too, so you can run hundreds to thousands of tests at the same time.
- Bazel can build many languages: C++, Go, Java, Scala, Rust, and even Haskell. It can also build clients like iOS and Angular/TypeScript/JavaScript. This means that you don't need a separate tool like CMake to build your NDK and C++ code. You can use the same build tool to build both front and backend, and run integration tests together.
- Bazel has a built in command called
mobile-install
, which allows for fast and iterative development of Android apps. It builds your app, shards out native libs, dexes and resource files, and only pushes changed shards to the device to reduce build and deploy times. Read more about it here.
Is it really good to have TWO build tools for Android?
There are more than just two: Buck & Pants are two other popular build systems for Android. Each build system has its pros and cons, and are designed and implemented to solve a particular set of requirements. For example, Bazel (and its surrounding ecosystem of tools) was born out of Google's gigantic monorepo, so it solves scalability issues really well.
Having the option to try out different approaches, IMO, is a good thing.
Does it mean that Android developer probably need to learn this new build tools in future?
Bazel is open source and has support in Android Studio via the Bazel plugin. If you think it looks interesting, feel free to try it out! We're still in early stages of adapting the Android rules to work in the open source world, so expect some features to be work-in-progress for the time being.
edited Mar 15 at 4:47
answered Jan 3 at 15:00


JinJin
6,16721931
6,16721931
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
1
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
2
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
add a comment |
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
1
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
2
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
"maybe not external dependencies (yet)" any insight into when this may come @Jin ?
– Mark Han
Jan 3 at 19:19
1
1
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
@MarkHan Not yet, but we're working on it.
– Jin
Jan 3 at 19:26
2
2
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
@MarkHan It's ready :-) github.com/bazelbuild/rules_jvm_external
– Jin
Mar 15 at 4:46
add a comment |
2
Yes, looking for the same. Just for reference - stackoverflow.com/questions/29245787/…
– Jignesh Patel
Jan 3 at 6:13
Does Google has a road map of migrate Android development from Gradle to Bazel?
– shizhen
Jan 4 at 1:53
@shizhen No, but there are codelabs for you to try it out.
– Jin
Jan 9 at 17:30