Status Update
No update yet.
Comments
ve...@google.com
ve...@google.com
The ToT dependency was coming from compose:test-utils. Jeremy raised aosp/2254837 to pin this to a prebuilt.
Alternatively, we could have added explicit androidTestImplementation dependencies on ToT to ensure it's available during dependency resolution.
TL;DR If we express a constraint on androidx.thing:thing:$TOT_VERSION which maps to the tip-of-tree version for :thing:thing, then any occurrence of androidx.thing:thing:$VERSION where the constraint is present must also include :thing:thing somewhere in the transitive dependencies.
mm...@commonsware.com
My understanding of this issue is:
-
Project A's library code depends on prebuilt B.
-
Project A's test depends on prebuilt B and also library C.
-
Library C declares a constraint saying that B must be the same version as Library C.
-
When resolving dependencies for Project A's tests, these tests depend on prebuilt B and library C, so library C's dependency information is also considered.
-
Library C says it requires B of the same version.
-
To reconcile:
- these requirements:
- the dependency on prebuilt B
- the constraint for B to match the version of C
- Gradle looks for a prebuilt of B with version matching C.
- these requirements:
-
No prebuilt of B exists with the same version matching Library C, so Gradle fails to resolve the dependency.
Is this right?
The request in
cg...@gmail.com
No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.
Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.
Assuming we're aligned...
Yes however if library B (e.g. project("B")) exists in the set of dependencies and its version matches C, then Gradle will successfully resolve the dependency by "upgrading" prebuilt B to library B.
pz...@gmail.com
No prebuilt of B exists with the same version matching the prebuilt of C, so Gradle fails to resolve the dependency.
Just to make sure we're aligned, this should read "library C" rather than prebuilt? It's library C (e.g. project(C) with version $X) that expresses a constraint on prebuilt B at version $X.
Yes! Fixed, thanks
cg...@gmail.com
The request in
is that libraries should publish this constraint information (rather than that Gradle should know how to automatically update prebuilt dependencies into project dependencies), so I think this issue is probably different b/146802533
Slightly different. Fixing
Given that this was caused by tests using different dependency versions than the library's runtime dependencies, though, maybe this is broken-as-intended? The fix that Jeremy implemented was to pin the tests to the same version.
cc...@google.com
Marking as Fixed even though the general problem can still occur. Unclear that we need a systemic fix.
Description
google/sailfish/sailfish:Q/QPP2.190228.023/5433927:user/release-keys
* Is this a regression from P to Q?
Yes.
* What device are you using? (for example, Pixel XL)
Pixel
* What are the steps to reproduce the problem? (Please provide the minimal reproducible test case.)
Step #1: UnZIP the attached project and import it into Android Studio (tested using 3.4)
Step #2: Run the legacyfile app and confirm that it shows a Toast indicating that files were written -- these will be a test.txt and a QStorage2/test2.txt file in the root of external storage
Step #3: Click the Open Document button to start an ACTION_OPEN_DOCUMENT activity, and notice that neither file shows up when you go to the root of external storage
Step #4: Click the Open Tree button to start an ACTION_OPEN_DOCUMENT_TREE activity, and notice that the QStorage2 directory does not show up when you go to the root of external storage (and wonder why you are seeing files in this activity, but that's a separate problem)
Step #5: Repeat steps 2-4 using the qfile app, which is the same app but with a targetSdkVersion of Q, and notice that you get the same results (nothing that was created shows up in the root of external storage)
Step #6: Use the Files app, navigate
* Issue Category e.g. Framework (platform), NDK (platform), Hardware (CPU, GPU, Sensor, Camera), ART (platform), Runtime Permissions etc
Platform
* What was the expected result?
The files should be visible in the Storage Access Framework UI
* What was the actual result?
The files are not visible, despite the fact that the apps can read them in.
This means that files written by *all* apps to external storage are inaccessible to the user, by any means, unless:
- The app writes them to getExternalFilesDir() and similar locations, or
- The app uses FileProvider and starts third-party activities using a suitable Intent (e.g., ACTION_VIEW)
* Relevant logcat output.
If you happen to select the root of external storage for the Open Tree scenario, Logcat will show a list of the visible contents, and you will get results like:
2019-04-23 16:04:38.206 9778-9778/com.commonsware.android.legacyfile D/Legacy File: # of children = Pictures, Alarms, DCIM, Download, gravatar2.png, Ringtones, Music, Podcasts, Notifications, Movies, Android
Note that neither test.txt nor QStorage2/ show up.
* Optional: Link to any screenshot(s) that demonstrate the issue (shared privately in Drive.)
Attached, please find two screencasts showing the behavior that I describe, for the legacyfile and qfile samples.