In Progress
Status Update
No update yet.
Comments
ji...@google.com
Issue with notification access code in core. Unclear where, but probably safe to assume NotificationCompat.
ji...@google.com
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
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
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
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
Examine the extension of the API so that it would open CCT on pre-U via
startActivityForResultwhich 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.