Assigned
Status Update
Comments
vi...@google.com <vi...@google.com> #2
When we fix nullability in Jetpack libraries, it is very painful for clients. Also for us attempting to land in g3.
I think this is a good idea; however, I'm not sure if we'd run into any issues since these are currently synthetic annotations generated by Metalava. It's possible that creating real annotations might conflict with the SDK stubs.
ed...@gmail.com <ed...@gmail.com> #3
If we do this we need to involve the Kotlin team; this basically introduces an "unenforced nullability warnings" level; they added the hardcoded qualified names for those two classes into the Kotlin compiler. intended for the narrow use case it's there for now; if this were to be broadened into something bigger they should be involved. +jvg
Description
Hello!
Similarly to the version , it'd be very nice for both app and library developers to have a
@ChecksSdkIntAtLeast
annotation that was added toandroidx.annotation
in1.2.0-alpha01
@ChecksPermissionGranted
annotation.Minimal specification draft
That annotation would be available to use on functions/methods and classes (including abstract classes, which would make subclasses inherit the tooling behavior provided by the annotation).
It would take one of these two parameters:
permissionNames
, an array ofString
s (useful for apps)permissionsParameter
, aString
which would reference a parameter for the function (or constructor?) where the permission names would arrive as an argument. (useful for libraries) Allowed types of the parameter would beString
and itsvararg
variant (aka.String...
). For that case, the tooling would warn at call site if the@ChecksPermissionGranted
annotation is not propagated with the same value, unless compile time constants are passed to the referenced parameter, allowing to make the missing permission error suppression work.Use case
With coroutines, it's possible to make a function that will suspend until a given permission is granted, and it's also possible, with a reference to a
FragmentActivity
or aFragment
, to ask this permission and await for the user to grant or deny it.With this library , that's what I'm doing in this example as well as production code thanks to these handy extensions using
AlertDialog
.The only bummer is that the IDE tells me that I'm not handling the case where the permission would be denied, which is false. To avoid starting to ignore errors and warnings, I have to put
@Suppress("MissingPermission")
all over the place, but this is the "nuclear" option, which will not let me spot an extra permission that I'd have forgotten to ensure that I have.Here's an example: I put the warning suppression because I ensured I have the camera permission, then I need the microphone permission, so I use it, and I'm not warned because
@Suppress("MissingPermission")
suppresses all runtime permission warnings in the scope. Later on, the app crashes because the permission is not granted there in the app.