Run from the real Gradle root
Look for settings.gradle or settings.gradle.kts and the wrapper scripts. In a framework project, the Android Gradle root may be a nested android/ directory rather than the repository root.
./gradlew projects
./gradlew tasks --all
If these commands fail during configuration, fix that earlier failure first. The absence of task output is not evidence that the task itself was deleted.
Check module inclusion and plugins
| Symptom | Investigation |
|---|---|
:app missing |
Settings file and included project paths |
| No Android assemble tasks | Android application/library plugin application |
| Only root utility tasks | Wrong directory or incomplete project import |
| Tasks appear in CLI but not IDE | IDE sync and selected Gradle project |
| Expected flavor task absent | Variant configuration and disabled variants |
The Android build overview explains project structure. Gradle's task documentation explains how plugins register tasks and how task paths identify their owning project.
Use an explicit task path
After confirming the task exists, invoke the appropriate module-qualified task, such as :app:assembleDebug. Do not assume every repository has a module called app or a variant called release; shared libraries and custom flavors may differ.
Avoid adding an empty task with the missing name just to satisfy the IDE. That can make a command succeed without producing the expected APK.
Reimport only after configuration is valid
Use the wrapper and a compatible JDK. Resolve plugin and repository failures, then refresh the IDE's project model. Deleting editor settings before understanding the root can remove useful configuration without fixing the build.
Verify an output, not a green status
Confirm that the intended task creates the expected artifact at the expected path. APKLint's Build Analyzer can help inspect configuration snippets, but the actual task graph must come from Gradle. Save the successful command and artifact identity in the build instructions so CI does not rely on an ambiguous IDE action.
Separate a missing task from failed task discovery
Consider a repository where :mobile:assembleDemoRelease is expected, but the task list never appears because plugin resolution fails first. Fixing the plugin repository or selected version is the immediate requirement. Creating a custom task with the expected name would hide the intended Android task and provide no evidence that a release was built. Preserve the complete configuration error before reasoning about the task inventory.
Once configuration succeeds, inspect ./gradlew :mobile:tasks --all. Use the actual project path reported by the build. If mobile is absent, inspect the settings file and any explicit project-directory mapping. In a composite build, the relevant task may belong to a separate included build rather than the main project's expected module hierarchy.
Match the task to a real enabled variant
An application with free and paid product flavors may expose flavor-specific assembly tasks rather than the exact task name copied from another repository. Check the configured flavor dimensions and any variant filtering. A deliberately disabled variant should not be restored just to satisfy an obsolete CI command without reviewing why it was disabled.
The Android variant guide explains how product flavors and build types combine. Use the task listing from the current project as the source of executable names. A library module also produces a different kind of artifact from an application module, so absence of an APK at an assumed app path may be correct for that module.
After selecting the intended task, inspect its output directory and the artifact's package or library identity. Update the CI invocation and artifact collection path together. A pipeline can run the correct task but upload an old file from another directory if collection remains stale. In a disposable build environment, ensure the selected output is freshly produced and record its digest. If CLI discovery works but the IDE list remains incomplete, refresh the correct Gradle project only after confirming the build model is valid. Keep the verified module-qualified command in the project instructions to remove future dependence on an ambiguous IDE task selection.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
