In Progress
Status Update
Comments
ji...@google.com <ji...@google.com> #2
Issue with notification access code in core. Unclear where, but probably safe to assume NotificationCompat
.
ji...@google.com <ji...@google.com> #3
Note that this is a lint error and can be suppressed or lowered to warning-level on the client side. Lowering back to P2
.
si...@google.com <si...@google.com> #4
To find cause of issue, update
androidx/platform/frameworks/support/+/androidx-main:buildSrc/public/src/main/kotlin/androidx/build/SupportConfig.kt;l=50 to 33 and then run ./gradlew :core:core:lintDebug
androidx/platform/frameworks/support/+/androidx-main:buildSrc/public/src/main/kotlin/androidx/build/SupportConfig.kt;l=50 to 33 and then run ./gradlew :core:core:lintDebug
tw...@google.com <tw...@google.com> #5
It's at
frameworks/support/core/core/src/main/java/androidx/core/app/NotificationManagerCompat.java:223: Error: When targeting Android 13 or higher, posting a permission requires holding the POST_NOTIFICATIONS permission [NotificationPermission]
mNotificationManager.notify(tag, id, notification);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Explanation for issues of type "NotificationPermission":
When targeting Android 13 and higher, posting permissions requires holding
the runtime permission android.permission.POST_NOTIFICATIONS.
si...@google.com <si...@google.com> #6
Handling this as part of
Description
Identity sharing API introduced in U lets CCT obtain the identity of the host app (package name). This is now defined in Androidx browser API . On pre-U devices the API is no-op.
Examine the extension of the API so that it would open CCT on pre-U via
startActivityForResult
which also has the effect of sharing the identity with CCT.Things to consider (feedback from twellington@):
Smoothing over the multiple ways to share an identity for APIs that require via some mechanism in the custom tabs AndroidX API sounds helpful. Need to think through how that could be done without causing breakage, though.
Would the app get a call to #onActivityResult with the request code (0 in this example) when the custom tab is closed?
If so, if the client app is using 0 for something else, that could result in unexpected behavior. Maybe the newer AndroidX Activity Result APIs can smooth that over.
There's also the wrinkle that the app would need to use an Activity Context when launching the intent for #startActivityForResult to work, but we could do an instanceof check for that.