android.support annotations still appearing after switching to androidX

[samschechter]

I have an Android project which uses Autovalue to generate some of its models. I am attempting to move from the old com.android.support.* to the new androidx.* dependencies.

I know that in the Android Gradle Plugin 3.2+ it attempts to replace all occurrences of the old support dependencies, but this doesn't seem to extend to the interfaces that are generated by Autovalue. These interfaces still reference android.support.annotation.NonNull and android.support.annotation.Nullable, instead of androidx.annotation.*

'com.android.tools.build:gradle:3.2.1'

implementation "com.google.auto.value:auto-value-annotations:1.6.3"
annotationProcessor "com.google.auto.value:auto-value:1.6.3"

androidx version - 1.0.0

I have enabled the following in my gradle.properties as well.
android.useAndroidX=true
android.enableJetifier=true

[eamonnmcmanus]

I guess we're talking about @Nullable here? AutoValue accepts any annotation called @Nullable in any package, and it uses the same package in its output code. For example if the input looks like this:

import android.support.annotation.Nullable;

@AutoValue
abstract class Foo {
  @Nullable String bar();
}

then the output might look like this:

import android.support.annotation.Nullable;

class AutoValue_Foo extends Foo {
  private @Nullable String bar;
  AutoValue_Foo(@Nullable String bar) {
    this.bar = bar;
  }
  @Override @Nullable String bar() {
    return bar;
  }
}

From what you describe, it sounds as if there's something happening the Android Gradle Plugin that somehow tweaks the code so that it appears as if the import is actually androidx.annotation.Nullable, but this tweak doesn't show up in the version of the code that the AutoValue processor receives. I'm not sure there's anything we can do on the AutoValue side about this, though if someone can suggest something we can certainly look into implementing it. The first step should be to log a bug against the Gradle plugin, though.

[samschechter]

I believe this issue was actually being caused by an outdated version of sqldelight. After updating the sqldelight version the models seem to be generated correctly.

I am still working through other issues with dependency change, but this problem appears resolved for now. Thank you for the help.