chore(dockerFile): dual android sdk installation and conflicts

[UnschooledGamer]

This PR refactors the .devcontainer/Dockerfile from a single-stage build into a three-stage multi-stage build (base → devcontainer / standalone), eliminating the previous conflict where Android SDK was installed twice when used as a devcontainer. The devcontainer target is intentionally lean (SDK and Node provided by devcontainer features), while standalone self-installs both. CONTRIBUTING.md is updated with the new --target standalone build command and a Podman compatibility note.

[greptile-apps]

Greptile Summary

This PR refactors the .devcontainer/Dockerfile from a single-stage build into a three-stage multi-stage build (base → devcontainer / standalone), eliminating the previous conflict where Android SDK was installed twice when used as a devcontainer. The devcontainer target is intentionally lean (SDK and Node provided by devcontainer features), while standalone self-installs both. CONTRIBUTING.md is updated with the new --target standalone build command and a Podman compatibility note.

Confidence Score: 5/5

Safe to merge; the multi-stage refactor is structurally sound and the only finding is a minor P2 maintenance concern in devcontainer.json.

Only P2 findings present (hardcoded build-tools version in remoteEnv PATH). All previously raised P1 concerns are resolved: GRADLE_VERSION is now declared inside the base stage, and ARG inheritance across child stages is handled correctly per the custom rule. No P0/P1 issues identified.

.devcontainer/devcontainer.json — the hardcoded 36.0.0 in remoteEnv.PATH should be kept in sync with the build_tools feature option.

Important Files Changed

Filename	Overview
.devcontainer/Dockerfile	Converted to a clean three-stage build (base → devcontainer / standalone); ARG declarations are properly scoped within base and inherited by child stages; standalone correctly installs Android SDK and Node/pnpm; Gradle PATH chain is correct across stages.
.devcontainer/devcontainer.json	Correctly targets the new devcontainer stage; android-sdk feature and node feature handle SDK/Node; build-tools version in remoteEnv.PATH is hardcoded and must be kept in sync with the feature option manually.
CONTRIBUTING.md	Updated docker build command to use --target standalone; added Podman compatibility note; minor link enhancement.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["FROM java:1-21-bullseye AS base\n(Gradle, apt deps, WORKDIR)"] --> B["FROM base AS devcontainer\n(empty – features handle SDK + Node)"]
    A --> C["FROM base AS standalone\n(Android SDK + fnm + Node + pnpm)"]
    B --> D["devcontainer.json\n(target: devcontainer)\nFeatures: android-sdk, node"]
    C --> E["docker build --target standalone\n(CONTRIBUTING.md Option 2)"]
    D --> F["remoteEnv injects\nANDROID_SDK_ROOT + PATH\n(build-tools/36.0.0 hardcoded ⚠️)"]

Loading

_{Reviews (9): Last reviewed commit: "fix(CONTRIBUTING.md): `Podmon` to Podman..." | Re-trigger Greptile}

[UnschooledGamer]

@greptileai As per this wording of Variable Scoping from Docker Docs; it should work:

Build arguments declared in the global scope of a Dockerfile aren't automatically inherited into the build stages. They're only accessible in the global scope.

# syntax=docker/dockerfile:1

# The following build argument is declared in the global scope:
ARG NAME="joe"

FROM alpine
# The following instruction doesn't have access to the $NAME build argument
# because the argument was defined in the global scope, not for this stage.
RUN echo "hello ${NAME}!"

The echo command in this example evaluates to hello ! because the value of the NAME build argument is out of scope. To inherit global build arguments into a stage, you must consume them:

# syntax=docker/dockerfile:1

# Declare the build argument in the global scope
ARG NAME="joe"

FROM alpine
# Consume the build argument in the build stage
ARG NAME
RUN echo $NAME

Once a build argument is declared or consumed in a stage, it's automatically inherited by child stages.

# syntax=docker/dockerfile:1
FROM alpine AS base
# Declare the build argument in the build stage
ARG NAME="joe"

# Create a new stage based on "base"
FROM base AS build
# The NAME build argument is available here
# since it's declared in a parent stage
RUN echo "hello $NAME!"

[UnschooledGamer]

Also as per this graph it should work (see stage-a & stage-c)

[UnschooledGamer]

@greptile fixed the typo.