[RestrictTo] @RestrictTo cannot be used outside the support library

[vanniktech]

The following class gets flagged:

@RestrictTo(LIBRARY) public final class Utils {
  public static void raiseEvent(final GeoFire geoFire, final Runnable runnable) {
    geoFire.raiseEvent(runnable);
  }

  private Utils() {
    throw new AssertionError("No instances.");
  }
}

with [RestrictTo] @RestrictTo cannot be used outside the support library. The package of the utility class is com.firebase.geofire while all of the other things are in a different package. I basically need the Utility class to call a package private function. Is this a false positive?

[liutikas]

RestrictTo check essentially breaks use of @RestrictTo annotation since it can only be used by android.support.* with this on by default. This annotation is general purpose and devs should be able to use it in their own projects.

[ZacSweers]

What was the resolution on this? Disabling it unblocks people but the check itself seems still wrong, unless google internally prevents anyone from the support library from using that annotation?

[liutikas]

It was simply disabled. The intention of this rule was to prevent apps within Google from using internal android.support.* library methods. Sadly, as implemented it blocks anyone from using @RestrictTo annotation. However, it is hard to implement this rule properly without deeper knowledge of the build system. If you have no concept of "library" or "library group" (both maven concepts) then you cannot know what uses should be restricted. As is, error-prone does not know which class is part of which library.

[vanniktech]

I'm also not happy with the 'fix' of disabling this rule.

[liutikas]

What's your proposal?

…

On Sun, Dec 3, 2017, 10:08 Niklas Baudy ***@***.***> wrote: I'm also not happy with the 'fix' of disabling this rule. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#812 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABWjyf8OTEC_IQjUPv9LwI0ghlJavStLks5s8uOggaJpZM4QS9gJ> .

[vanniktech]

I'd like to understand why this was even added in the first place and what's the benefit.

[JakeWharton]

Can we mark as @GoogleInternal? Why is it even open source if it's unusable anywhere but internally?

…

On Sun, Dec 3, 2017, 2:34 PM Niklas Baudy ***@***.***> wrote: I'd like to understand why this was even added in the first place and what's the benefit. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#812 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEYWW4j2ZpgMAyQbd_kNWeZeBmr46ks5s8vfdgaJpZM4QS9gJ> .

[eaftan]

I'll try to summarize the internal discussion on this.

@RestrictTo was not intended to be general purpose. It has semantics that depend on Gradle-specific things like LIBRARY or LIBRARY_GROUP. We wanted to enforce this inside Google, where we use the Bazel build system, and the only solution was to restrict its use to libraries where we know their structure, such as the support library.

Android team is also planning to move away from @RestrictTo: https://issuetracker.google.com/issues/68153195

Given all that, I don't this this makes sense for open-source users, and we should make it Google-internal.

[vanniktech]

Has there been any progress on this issue? Marking it as Google internal seems fine to me and should be trivial.