To fix the problem, add an explicit permissions block that grants only the minimum required scopes to the GITHUB_TOKEN. Since this workflow checks out code and runs Gradle locally, contents: read is sufficient and matches the recommendation.

The best way to fix this without changing existing functionality is to add permissions: contents: read at the job level under build: (so it applies only to this job) or at the workflow root. Because CodeQL highlighted the job’s runs-on line, we will set the permissions for that specific job. Concretely, edit .github/workflows/android.yml and insert a permissions: section between build: and runs-on: ubuntu-latest, with two-space indentation under build: and four-space indentation for contents: read.

No additional methods, imports, or definitions are needed—this is purely a declarative change in the workflow YAML.

In general, the fix is to explicitly declare a permissions block in the workflow (either at the root or for the specific job) that grants only the minimal permissions needed. For this workflow, the steps only require read access to the repository contents to allow actions/checkout to work; no other GitHub API write operations are used. Therefore, we can safely set contents: read as the workflow or job permission.

The single best fix with no behavioral change is to add a root‑level permissions block under the name (and before on:) so that it applies to all jobs. This will make the GITHUB_TOKEN read‑only for repository contents, which is sufficient for checkout and does not interfere with deployment to Azure (which uses AZURE_FUNCTIONAPP_PUBLISH_PROFILE). Concretely, in .github/workflows/azure-functions-app-java.yml, insert:

permissions:
  contents: read

after line 19 (name: Deploy Java project to Azure Function App) and before line 21 (on:). No additional imports, methods, or definitions are needed because this is purely a workflow configuration change.