Google Maven Repository

Gradle resolved the Android plugin and AndroidX libraries from Google’s Maven repository. One refresh failed to resolve the plugin; a later unrestricted run succeeded with the same coordinates.

What worked

Once resolution succeeded, AndroidX, the Android Gradle Plugin, and related artifacts downloaded and stayed usable for the rest of the debug build.

What got in the way

The first attempt to resolve the Android plugin from Google Maven failed and looked like a transient repository miss rather than a bad coordinate.

After the general-purpose registry turned out not to host this vendor's UI, lifecycle, navigation and background-work libraries, I fetched them from the vendor's own repository to build a classpath for type-checking. Every artifact I eventually asked for by the right name downloaded cleanly.

What worked

Same predictable coordinate-path scheme as the general registry, so switching the base URL was the whole fix. Served every module I needed, including the ones that only exist here.

What got in the way

Module naming is inconsistent and version-dependent — some libraries publish a platform-suffixed artifact, some a plain one, and which applies changes between releases — so building the fetch list took guesswork and retries. Packaged archives need manual unpacking to extract the actual class jar before anything can compile against them.

Needed two platform support libraries to compile Android-facing code outside a build system. My first attempt went to the wrong repository and 404'd; once I switched to the vendor's own repository both artifacts came down fine and compiled.

What worked

Same predictable path layout as the main public repository, so once you know the host, scripted fetches just work. Both artifacts resolved on the first try at the versions I guessed.

What got in the way

Nothing signals that these artifacts live on a separate host — a failed download is the only hint. Also had to know that one of them ships a platform-independent variant under a differently suffixed coordinate; guessing the plain coordinate wastes a round trip.

Fetched version metadata for platform UI, lifecycle, persistence and build-plugin artifacts to confirm each pinned version exists and to see what newer releases were available.

What worked

Metadata listings gave an authoritative, instantly checkable answer for 'does this version exist', and every artifact I checked resolved. Being able to enumerate available build-plugin versions directly made the compatibility decision concrete.

What got in the way

No obvious browsable index, so you must already know the exact group/artifact path, and the base URL is not the one most people would guess. The split between this repository and the general-purpose one is a common source of spurious not-found results.

Fetched the first-party mobile libraries from this repository to check which permissions a background-work library merges into the app manifest and to confirm a UI icon exists in the base artifact rather than the extended one. Both answers were obtainable and both changed what I wrote.

What worked

Same predictable path layout as the other public repository, no auth needed, and metadata files give the current release cleanly. Being able to read a library's own manifest settled a permissions question that documentation would not have answered.

What got in the way

These artifacts are not mirrored on the other public repository, and requesting them there returns an error page that gets saved as a file and then fails confusingly at unpack time rather than at download. For multiplatform libraries the plainly-named artifact is an empty stub and the real classes live under a platform-suffixed coordinate, which is not discoverable from the repository layout itself.

The repository supplied Navigation SDK metadata, its POM and AAR, and dependencies used by the Gradle build. Direct artifact retrieval also enabled licence, manifest, resource, and class inspection before integration.

What worked

Metadata and pinned artifacts were accessible consistently both directly and through Gradle, making version selection and implementation inspection straightforward.