AskMeAnything
Ask
Ask
25
@rosco_p ·

Failed to find package tools: setup-android and sdkmanager

Every Android job on every branch went red this morning, on a commit that only touched a string resource. Nothing in the workflow changed for weeks.

Warning: Failed to find package 'tools'
Error: The process '/home/ubuntu/.android/sdk/cmdline-tools/16.0/bin/sdkmanager' failed with exit code 1

The step is the ordinary android-actions/setup-android@v4, pinned, no inputs set. So the workflow is asking sdkmanager for a package called tools and sdkmanager cannot find it any more.

Google has listed tools as deprecated for a long time, and it looks like it stopped being served yesterday. There is an issue on the action, filed the same morning, already at dozens of reactions and no answer in it yet.

Rolling back to an older action tag changes nothing, which makes sense if the package is simply gone from the other end. Is there a correct fix, or is everyone waiting for a release of the action?

8 answers Share
Report

8 answers

BestTopNewOldControversial

Answering anonymously, a moderator will review it first.

  • @ilka_nn · 2h ago
    @ilka_nn ·

    The empty-string variant is documented too, and it is the one I would pick if you install anything unusual: packages: '' installs nothing, then you call sdkmanager yourself in a later step with the exact list you want. Slightly more yaml, no surprises the next time a default changes under you.

    20
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
  • @pike_44 · 2h ago · 2 replies
    @pike_44 ·

    You do not need a release. The action has a packages input and its default is tools platform-tools, which is the only reason your job asks for the dead one. Name what you want instead:

    - uses: android-actions/setup-android@v4
  with:
    packages: 'platform-tools'

    Green again on the next run.

    28
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @rosco_p · 2h ago
      @rosco_p OP ·

      That was it. Four repos, one line each, all passing. I had been reading the action's source looking for a hardcoded list.

      14
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @svea_m · 2h ago · 2 replies
    @svea_m ·

    Why was it installing a deprecated package by default in the first place?

    17
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @pike_44 · 2h ago
      @pike_44 ·

      Because it has been the default since before it was deprecated, and nothing broke while Google kept serving it. Defaults are only load bearing on the day the other side changes, which is also the day you find out what yours are.

      16
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
  • @tom_vance · 2h ago · 3 replies
    @tom_vance ·

    If you run self-hosted, expect this to look random across the fleet. Runners with a warm SDK directory sail through, and the moment one rebuilds its cache it joins the failures. Took me an hour to stop suspecting a specific machine.

    15
    Share
    Reply

    Answering anonymously, a moderator will review it first.

    Report
    • @ilka_nn · 6h ago · 2 replies
      @ilka_nn ·

      Same, and our scheduled nightly was green while every PR run was red, which sent me looking at the wrong difference entirely.

      11
      Share
      Reply

      Answering anonymously, a moderator will review it first.

      Report
      • @tom_vance · 8h ago
        @tom_vance ·

        The tell is that the failing step never reaches Gradle. If your build log dies before the first Gradle line, it is the SDK setup, not your project.

        9
        Share
        Reply

        Answering anonymously, a moderator will review it first.

        Report