English 字幕

← Configuring Generated Tasks


Showing Revision 3 created 05/24/2016 by Udacity Robot.

  1. Let's say say we want to change
    a compile flag in our Java project.
  2. We can just add some configuration
    to the compile Java task.
  3. However, unlike simple Java projects,
  4. which have a finite set of tasks such
    as, compile Java, jar, test, etc.
  5. Android projects can have
    an indeterminate number of tasks,
  6. depending on the build types and
    product flavors we have declared.
  7. Additionally, the names of
    these tasks are generated, and
  8. they're based on the name of
    the particular variant the task is for.
  9. Not only that, but these tasks
    are created at a very late stage of
  10. the project configuration life cycle.
  11. Which means, in most cases,
  12. we can't directly reference
    them in our build script.
  13. Essentially, we need
    to solve two problems.
  14. First, we need a way to reference each
    task used to build a particular variant
  15. without having to know
    the task's actual name.
  16. Quite simply, we want to configure all
    the tasks of a particular type for
  17. every variant.
  18. Second, we need a way to defer
    the configuration of that task
  19. until after all of our build
    variants have been created.
  20. Which really just means that we can't
    configure the task until a task exists.
  21. The first problem is solved by
    the Android Gradle Plugin itself,
  22. which groups all the information
    to include the tasks
  23. associated with any given
    variant into a single object.
  24. There are three main types of these
    objects, the Application Variant,
  25. the Library Variant or the Test Variant.
  26. The type of variant we need depends on
    the type of project we're building.
  27. Application Variants and
  28. Library Variants are created for Android
    Applications or libraries respectively.
  29. And Test Variants are created for
    the on device test APK.
  30. Each one has its own specific
    properties, but they all have common
  31. tasks, like compiling Java,
    merging resources, and so on.
  32. So the Android Griddle plugin is
    nice enough to neatly package all
  33. the information about a variant for
  34. us, but the problem remains, how do
    we reference these variant objects?
  35. This problem is solved by what
    Gradle calls live collections.
  36. Essentially, as the Android
    plugin creates variants,
  37. they are added to a fancy
    type of collection.
  38. These collections allow us
    to define configurations for
  39. objects that don't yet exist.
  40. Instead, Gradle will remember
    our configuration and
  41. execute it when a new object is added.
  42. We specify this configuration
    by calling the all method
  43. on our variant collection.
  44. For example, if we wanted to configure
    all the Java compile tasks for
  45. our application variants
    to add a compiler argument,
  46. we could do something like this.
  47. This will now configure each Java
    compile task for each of our debug build
  48. types, regardless of how many
    product flavors we have configured.
  49. Also, you don't have to try and
  50. guess what the final names of
    each of those tasks might be.