Fixed
Status Update
Comments
[Deleted User] <[Deleted User]> #2
This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
[Deleted User] <[Deleted User]> #3
Almost 2 months later and this is still broken
hu...@google.com <hu...@google.com> #4
Since there is no progression, I wanted to share our quick-fix for the issue.
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
#sdkmanager --package_file=${PATH_WORKSPACE}/packages
while read p; do echo "y" | sdkmanager "${p}"; done <${PATH_WORKSPACE}/packages
ce...@gmail.com <ce...@gmail.com> #5
jb...@google.com What is the update on this?
hu...@google.com <hu...@google.com> #6
What is the status of this item?
[Deleted User] <[Deleted User]> #7
This has been fixed on master today (internal ref: ag/2945015) and will be available in the next SDK release.
hu...@google.com <hu...@google.com> #8
Any ETA on next release?
[Deleted User] <[Deleted User]> #9
Still broken and not updated? --package_file argument is not usable in it's current form on 26.1.1 straight from the developer site.
ce...@gmail.com <ce...@gmail.com> #10
Comfirmed that this seems to still be broken. Can we have an update please?
```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1
(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```
```
(15:58:11) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --version
26.1.1
(15:58:17) C02W513SHTD8:files aso$ /opt/android-sdk-macosx/tools/bin/sdkmanager --install --package_file=package_file
Warning: Unknown argument --package_file=package_file
```
cm...@google.com <cm...@google.com> #11
Hi, is there any update to this issue? Thanks.
hu...@google.com <hu...@google.com> #12
Hi Google. You claim it's been fixed on master, but we haven't had a new release since the broken version 26.1.1. Can you please release the fix?
ce...@gmail.com <ce...@gmail.com> #13
Yeah, still not fixed --'
hu...@google.com <hu...@google.com> #14
Can't believe this still isn't fixed 2 years later for a command line utility that sits on the main dev site.
ce...@gmail.com <ce...@gmail.com> #15
Any updates on this? The help for this command clearly states this argument is supported.
hu...@google.com <hu...@google.com> #16
Has anyone re-tried it?
We switched back to RUN sdkmanager --package_file=$ANDROID_HOME/packages.txt
in our Dockerfile back in March of 2021.
hu...@google.com <hu...@google.com> #17
For what it's worth, I did a quick test with the latest CLI: 11076708 (
./sdkmanager --sdk_root="../sdk" --package_file=deps.txt
Deps.txt:
platform-tools
extras;google;instantapps
build-tools;35.0.0-rc3
So perhaps this is now resolved? I haven't tried it with more packages
ce...@gmail.com <ce...@gmail.com> #18
Yeah, thanks, that's what I meant when I said earlier that both Gradle and AS seemed to run tests using the project directory. Using paths that are relative to the project directory sounds perfect to me.
hu...@google.com <hu...@google.com> #19
That sounds good.
Starting with AGP 3.5.0-alpha05, the following Gradle property will be available to use:
android.testConfig.useRelativePath
It currently defaults to false. When set to true, the test config file will contain all paths relative to the current project directory. It should already work with Robolectric 4.0+.
Relevant commits:
-https://android.googlesource.com/platform/tools/base/+/e1d267e226d7c69cebe8f53a4df519ab658a1a67
-https://android.googlesource.com/platform/tools/base/+/e80be3495eab92186ef955850ba2ada7ff514caa
Please try out this feature and let us know if you see any issues. I'm expecting to set this flag to true by default soon. Leaving this bug open to keep track of that.
Starting with AGP 3.5.0-alpha05, the following Gradle property will be available to use:
android.testConfig.useRelativePath
It currently defaults to false. When set to true, the test config file will contain all paths relative to the current project directory. It should already work with Robolectric 4.0+.
Relevant commits:
-
-
Please try out this feature and let us know if you see any issues. I'm expecting to set this flag to true by default soon. Leaving this bug open to keep track of that.
[Deleted User] <[Deleted User]> #20
When do you expect 3.5.0-alpha05 to be published? The latest I can find right now is alpha03.
hu...@google.com <hu...@google.com> #21
I think it will be released at the end of next week.
me...@gmail.com <me...@gmail.com> #22
Hi,
Is there a plan to make this available even in future versions of AGP 3.4 ?
Is there a plan to make this available even in future versions of AGP 3.4 ?
hu...@google.com <hu...@google.com> #23
I'm afraid not, as we have gone from beta to RC for 3.4, meaning it's a lot harder to cherry-pick fixes.
hu...@google.com <hu...@google.com> #24
Starting with AGP 3.6.0-alpha02, this flag android.testConfig.useRelativePath will be enabled by default. Android unit tests should be fully cacheable now. Thanks for the reports and discussion!
Change:https://android.googlesource.com/platform/tools/base/+/e48c3831b9a9dd4829d63ba80fddc46ba7e67e61
Change:
ce...@gmail.com <ce...@gmail.com> #25
I'd like to point out a pitfall with unit test caching that should probably be fixed in gradle: test ordering is currently indeterministic, and may affect the test results if tests happen to be coupled. I filed a ticket a while back with Gradle, but it's not getting much traction: https://github.com/gradle/gradle/issues/8520 .
hu...@google.com <hu...@google.com> #26
I see, hopefully the Gradle team will get to it soon.
[Deleted User] <[Deleted User]> #27
Relating to #4 and `includeAndroidResources=false`, has this been addressed yet? If not, when do we think it will be?
hu...@google.com <hu...@google.com> #28
Yes, when includeAndroidResources=false, unit tests are already cacheable since 3.5.0-alpha03 (that's what I meant when writing comment #4 ).
[Deleted User] <[Deleted User]> #29
Oh, what I meant was, when will unit tests be cacheable when it's true? You said
> Next, we are working on making unit tests cacheable when includeAndroidResources=true.
:)
> Next, we are working on making unit tests cacheable when includeAndroidResources=true.
:)
hu...@google.com <hu...@google.com> #30
Ah I see, when includeAndroidResources=true, unit tests will be cacheable starting with 3.6.0-alpha02 ( comment #24 ).
[Deleted User] <[Deleted User]> #31
Got it. Thanks for the clarification!
Description
No description yet.