IssueTracker

Context:

We have a very large Android project with many project modules, many of which are independent of each other until integration at the application module level. We also have build/developer machines which vary widely in terms of system specs/capabilities. It has become difficult for us to scale the build. The most significant system resource from the perspective of build success/failure has tended to be memory, as running out of other resources tend to only slow the build (disk space not withstanding) whereas running out of memory crashes the build.

Our current approach is predicated upon knowing the concrete task types defined by AGP. Given AGP's roadmap to hide implementation details in favor of moving to an API artifact, this means that our ability to successfully implement our current solution will be reduced/removed.

Request:

Add an optional mechanism into AGP to allow memory-intensive tasks to have limited concurrency within a parallel build execution. The concurrency should be able to be determined by the project or command line invocation such that more powerful machines can more fully take advantage of their expanded system resources, whereas weaker machines can constrain the build more.

Our current approach:

We have authored build plugins that perform simple system probes and bucket the systems into simple categories of CONSTRAINED, NORMAL, and UNCONSTRAINED. The definition of this part is very project specific. For us, this currently is defined by something like:

        private val constraint by lazy {
            when {
                processorCount < 8 || systemMemory <= 16 -> ConcurrencyConstraint.CONSTRAINED
                processorCount < 16 || systemMemory <= 64 -> ConcurrencyConstraint.NORMAL
                else -> ConcurrencyConstraint.UNCONSTRAINED
            }        

This is then used in conjunction with a build service which is being used as a simple semaphore:

        val limiterService = project.gradle.sharedServices.registerIfAbsent(
            "concurrencyConstraint", ConcurrencyLimiterBuildService::class.java
        ) {
            val slots = when (constraintClass) {
                ConcurrencyConstraint.CONSTRAINED -> 2
                ConcurrencyConstraint.NORMAL -> 5
                // When running totally unconstrained the build gets very slow.  Until we can investigate what the
                // point of contention is we'll cap things at a lower level in an attempt to retain speed.  This
                // is a totally contrived limit.
                else -> processorCount.coerceAtMost(24)
            }
            maxParallelUsages.set(slots)
        }

This build service is then associated with the most intensive tasks by type:

        project.tasks.configureEach {
            if (when {
                this is R8Task -> true
                this is AndroidLintTask -> true
                this is AndroidLintAnalysisTask -> true
                this is AndroidUnitTest -> true
                this is JavaCompile -> true
                name.startsWith("KotlinCompile") || name.startsWith("kapt") -> true
                this is com.android.build.gradle.tasks.PackageApplication -> true
                this is com.android.build.gradle.tasks.MergeResources -> true
                this is com.android.build.gradle.internal.tasks.DexMergingTask -> true
                else -> false
            }) {
                usesService(limiterService)
            }
        }

This lets the cheap tasks continue in mass parallel execution - something that cannot be achieved by simply reducing worker count - whilst moderately serializing the expensive tasks, increasing the success rate of our build on lower end hardware for our builds.