The Support Library POMs Are Broken Again... Though You May Not Notice

UPDATE 2017-12-13: Version 27.0.2 appears to be properly configured.

If you try using Maven to build an Android app, most likely it will have problems with the Android Support Library v26 artifacts, at least through 26.1.0. That is because the Support Library POMs have a bug, where they do not declare the type of transitive dependencies. The Maven standard is that the default type is JAR, but many of the type-less transitive dependencies in the Support Library are actually AARs.

For example, here are the dependencies from recyclerview-v7:25.4.0, which has a valid POM:

  <dependencies>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-annotations</artifactId>
      <version>25.4.0</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-compat</artifactId>
      <version>25.4.0</version>
      <type>aar</type>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-core-ui</artifactId>
      <version>25.4.0</version>
      <type>aar</type>
      <scope>compile</scope>
    </dependency>
  </dependencies>

Notice how the support-compat and support-core-ui dependencies have <type>aar</type> to declare that they are AAR dependencies. support-annotations lacks a <type> element, but that is OK, as that dependency is a JAR, and so the default is fine.

Here is the same snippet of XML, this time from recyclerview-v7:26.1.0:

  <dependencies>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-annotations</artifactId>
      <version>26.1.0</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-compat</artifactId>
      <version>26.1.0</version>
      <scope>compile</scope>
    </dependency>
    <dependency>
      <groupId>com.android.support</groupId>
      <artifactId>support-core-ui</artifactId>
      <version>26.1.0</version>
      <scope>compile</scope>
    </dependency>
  </dependencies>

Here, all three transitive dependencies are missing the <type>… even though two of them are AARs. This breaks Maven and any build system that adheres to the “no type means it’s a JAR” rule.

The Android Plugin for Gradle does not notice this problem, as it is designed to be more flexible about default types. Apparently, it will check for both JARs and AARs. Certainly, Google is welcome to implement its tools however it wants.

But this bug has happened before.

In the meantime, I assume that a Maven user can hack the POMs to add in the missing <type> elements. An organization might use this as a reason to stop depending directly on Google’s artifact repository and instead host their own repository with copies of Google’s artifacts, for greater resiliency in face of this sort of compatibility issue.

And, if you’re using Android Studio and Gradle… keep on keepin’ on, I suppose.

(hat tip to William Ferguson for filing the issue and pointing out the problem!)