Status Update
No update yet.
Comments
pt...@google.com
Branch: androidx-master-dev
commit d46999fa005b4726287814ea0f8abe30cf189a01
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue May 26 15:36:06 2020
Clean up ActivityResultCaller implementation
Instead of using two separate anonymous classes to be returned by the
register methods, lets clean it up by using an internal class and only
doing the implementation once.
Test: Tested in app
Bug: 156875743
Change-Id: Ia63dd0dce4ecd7115ea93168f889e119738e3352
M activity/activity-ktx/api/1.2.0-alpha06.txt
M activity/activity-ktx/api/current.txt
M activity/activity-ktx/api/public_plus_experimental_1.2.0-alpha06.txt
M activity/activity-ktx/api/public_plus_experimental_current.txt
M activity/activity-ktx/api/restricted_1.2.0-alpha06.txt
M activity/activity-ktx/api/restricted_current.txt
M activity/activity-ktx/src/main/java/androidx/activity/result/ActivityResultCaller.kt
pt...@google.com
Branch: androidx-master-dev
commit 55c784def8b9942026075af6fc659b551732ef44
Author: Jeremy Woods <jbwoods@google.com>
Date: Tue May 26 08:45:51 2020
Add getContract to ActivityResultLauncher
Intents provide a way to check if the intent can be handled by any
Activity components and the ActivityResultLauncher should provide
the ability to do something similar.
This change adds a getContract API to ActivityResultLauncher that gives
the returns the contract used to register the launcher. This means that
users can create an Intent from their contract and make all of their
desired checks.
Test: ActivityResultLauncherTest
Bug: 156875743
RelNote: "ActivityResultLauncher now allows you to get the
ActivityResultContract that was used to register the launcher."
Change-Id: I64f536f2b3dde3e87cea884c6b9c111e5efe26ed
M activity/activity-ktx/build.gradle
M activity/activity-ktx/src/androidTest/AndroidManifest.xml
A activity/activity-ktx/src/androidTest/java/androidx/activity/result/ActivityResultCallerTest.kt
M activity/activity-ktx/src/main/java/androidx/activity/result/ActivityResultCaller.kt
M activity/activity/api/1.2.0-alpha06.txt
M activity/activity/api/current.txt
M activity/activity/api/public_plus_experimental_1.2.0-alpha06.txt
M activity/activity/api/public_plus_experimental_current.txt
M activity/activity/api/restricted_1.2.0-alpha06.txt
M activity/activity/api/restricted_current.txt
M activity/activity/src/androidTest/java/androidx/activity/result/ActivityResultLauncherTest.kt
M activity/activity/src/main/java/androidx/activity/result/ActivityResultLauncher.java
M activity/activity/src/main/java/androidx/activity/result/ActivityResultRegistry.java
M fragment/fragment/src/main/java/androidx/fragment/app/Fragment.java
bu...@google.com
This has been fixed internally and will be available in the Activity 1.2.0-alpha06 release.
To address this the ActivityResultLauncher now gives access to the ActivityResultContract.
With the contract, you can create the intent and use it to call resolveActivity() directly:
launcher.contract.createIntent(context, input).resolveActivity(packageManager)
ch...@gmail.com
Keep in mind that due to the resolveActivity() will return null unless you add the specific <queries> elements to your manifest.
As per that doc, the alternative is to catch the ActivityNotFoundException yourself by wrapping your launch() call in a try / catch, just like if you were using startActivityForResult() yourself.
bu...@google.com
pb...@google.com
Thank you for the test application. I can confirm the issue.
The problem is the parsing of the content-disposition, as implemented by
The immediate issue is that the regular expression fails if it encounters unexpected content, such as filename* instead of simply ignoring it.
Ideally it should also respect filename* values. As per the RFC, a filename* option should be preferred.
be...@google.com
The filename*.
I see that
I haven't looked at any of the rest of the spec but it might not only be filename* that we need to update as part of this.
We should probably treat this as a feature request.
nt...@google.com
We discussed this today. Some ideas include:
- We could update the Android framework code for this API (have not determined how difficult this would be). This would fix the issue only for new Android OS versions, however an app developer could copy this open source implementation into their own app.
- We could consider porting the implementation into our
androidx.webkitlibrary. That would let developers get an updated implementation that works on any OS version. This doesn't necessarily even need to call into chromium code, since it seems the current version of the API is implemented without calling chromium code.
I agree this is best categorized as a feature request.
pb...@google.com
ap...@google.com
Branch: androidx-main
commit df6bc29927fe53578c08ed0f23a417281728357a
Author: Peter Birk Pakkenberg <pbirk@google.com>
Date: Tue Dec 05 14:15:20 2023
Add URLUtilCompat class with new implementations
These methods can be used by the android.webkit.DownloadListener interface
to determine the filename suggested by the server.
The methods are an update to android.webkitURLUtil.
Bug: 309927164
Test: Added URLUtilTest.java
Change-Id: Ie4d6a8d0349a8a19c85a15fcb900e947146558d5
A webkit/integration-tests/instrumentation/src/androidTest/java/androidx/webkit/URLUtilCompatTest.java
A webkit/webkit/src/main/java/androidx/webkit/URLUtilCompat.java
pb...@google.com
Filed
pb...@google.com
ap...@google.com
Branch: androidx-main
commit 9fcc12508205bcaba61c3fe2a770f3ff6833c88d
Author: Peter Birk Pakkenberg <pbirk@google.com>
Date: Wed Jan 10 11:15:07 2024
Unhide URLUtilCompat
RelNote: """Add compatibility for `URLUtil.guessFileName`. The
compatibility version supports parsing of `Content-Disposition`
headers that use the `filename*` encoded value attribute as defined
in [RFC 6266](
The compatibility API also directly exposes a method to parse the
`Content-Disposition` header where a suggested file name based on
URL and MIME-type is not desired."""
Fixes: 309927164
Test: N/A - unhide API
Change-Id: If6ae780cbb49f2092f22bd796a6eccb34f25e877
M webkit/webkit/api/current.txt
M webkit/webkit/api/restricted_current.txt
M webkit/webkit/src/main/java/androidx/webkit/URLUtilCompat.java
Description
Component used: android.webkit.URLUtil.guess Version used: Android SDK 34 Devices/Android versions reproduced on: Android 13/14 Pixel 4/5
The issue is that the regex matching the contentDisposition to retrieve the filename does not support the "filename*"-directive which allows for a specific encoding. Thus, the following input for contentDisposition is ignored and instead the filename is guessed based on the url: attachment; filename*=UTF-8''Test.png; filename="Test.png"
See