WatchFaceType.DIGITAL and other constants within annotation types show as RestrictTo.Scope.LIBRARY [288750666]

Fixed

Bug

Status Update

No update yet.

Description

ia...@gmail.com

created issue #1

Jun 26, 2023 12:04AM

Component used: Wear-Watchface

Version used: 1.2.0-alpha08 or higher

After upgrading to Wear Watchface 1.2.0-alpha08 or higher, I noticed an error in Android Studio on both the WatchFaceType and CanvasType integers that they should only be used within the androidx.wear.watchface library:

Companion.DIGITAL can only be accessed from within the same library
(androidx.wear.watchface:watchface)

It appears this is an unintended side effect of this CL that marked those annotation classes as @RestrictTo(RestrictTo.Scope.LIBRARY).

Would it be possible to separate the constants (which really could just be on a regular Kotlin object, rather than as part of a companion object of a restricted class) from the restricted annotation class (which it doesn't matter what the class name of that annotation actually is)?

It is really annoying to have the red underlines in Android Studio and associated lint failures.

FWIW, I noticed that this does not apply to constants such as WatchFaceStyle.PROTECT_STATUS_BAR, but only to constants within a public annotation class that is restricted.

From this search, it appears this issue affects:

all WatchFaceType constants
all CanvasType constants
all TapType constants
all ComplicationsSlotBoundsType constants

Comments

al...@google.com <al...@google.com> #2Jun 26, 2023 09:14AM

Assigned to al...@google.com.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019

Change the way to detect mismatch between POJO and query

This fixes cursor mismatch warnings with expandProjection.

Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8

M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt

https://android-review.googlesource.com/1123258

https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1

al...@google.com <al...@google.com> #3Jun 26, 2023 09:37AM

Accepted by al...@google.com.

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

ap...@google.com <ap...@google.com> #4Jun 28, 2023 02:07PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020

Re-factor how errors are dismissed when query is re-written

This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (

b/140759491

).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.

This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.

Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f

M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt

https://android-review.googlesource.com/1288456

al...@google.com <al...@google.com> #5Jun 28, 2023 03:22PM

Marked as fixed.

That patch is subject to API council review, but hopefully it improves the situation. I'll arrange for another alpha in due course.

ia...@gmail.com <ia...@gmail.com> #6Jun 28, 2023 04:17PM

Is there a reason you needed to change any part of the public API surface? Given that the annotation itself isn't part of the public API, couldn't you have just renamed the IntDef annotation class?

E.g.,

public object WatchFaceType {
    /* The WatchFace has an analog time display. */
    public const val ANALOG: Int = 0

    /* The WatchFace has a digital time display. */
    public const val DIGITAL: Int = 1
}

@RestrictTo(RestrictTo.Scope.LIBRARY_GROUP)
@IntDef(value = [WatchFaceType.DIGITAL, WatchFaceType.ANALOG])
public annotation class WatchFaceTypes

al...@google.com <al...@google.com> #7Jun 30, 2023 01:53PM

Status: Assigned (reopened)

OK if we can rename the IntDefs that does sound better.

al...@google.com <al...@google.com> Jun 30, 2023 03:13PM

Accepted by al...@google.com.

al...@google.com <al...@google.com> #8Jul 3, 2023 09:26AM

Marked as fixed.

Oops I'm probably going to confuse the tooling here. I landed a follow up patch: https://android-review.git.corp.google.com/c/platform/frameworks/support/+/2646822 but it looks like I copied the wrong bug number.

Message last modified on Jul 3, 2023 09:27AM

ia...@gmail.com <ia...@gmail.com> #9Jul 3, 2023 07:23PM

Thanks so much - that follow up change looks great! I'll be sure to test it once the next release comes out.