Verified
Status Update
Comments
ze...@google.com <ze...@google.com>
be...@gmail.com <be...@gmail.com> #2
This was broken by 3bca759a5ff08352de831bb1e9b61b1ec2b3362d.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
Fix (pending) is I2c2dc7b600603ee430fd0d91b23d52ea8aa29ca9.
ap...@google.com <ap...@google.com> #3
Almost 2 months later and this is still broken
ap...@google.com <ap...@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
ap...@google.com <ap...@google.com> #5
jb...@google.com What is the update on this?
ap...@google.com <ap...@google.com> #6
What is the status of this item?
ap...@google.com <ap...@google.com> #7
This has been fixed on master today (internal ref: ag/2945015) and will be available in the next SDK release.
ap...@google.com <ap...@google.com> #8
Any ETA on next release?
ap...@google.com <ap...@google.com> #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.
ap...@google.com <ap...@google.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
```
ap...@google.com <ap...@google.com> #11
Hi, is there any update to this issue? Thanks.
ap...@google.com <ap...@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?
ap...@google.com <ap...@google.com> #13
Yeah, still not fixed --'
ap...@google.com <ap...@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.
ap...@google.com <ap...@google.com> #15
Any updates on this? The help for this command clearly states this argument is supported.
ap...@google.com <ap...@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.
ap...@google.com <ap...@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
ch...@google.com <ch...@google.com>
ap...@google.com <ap...@google.com> #18
Project: r8
Branch: 4.0
commit 100d0b0162ec31385e004be1fdf0e35103f5df1d
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Wed May 31 11:28:09 2023
Fix inadequate argument propagation in presence of join types
Bug: b/284188592
Change-Id: Ic00ce43da9839884cbb19a87a7b43020951c3114
M src/main/java/com/android/tools/r8/optimize/argumentpropagation/propagation/VirtualDispatchMethodArgumentPropagator.java
M src/test/java/com/android/tools/r8/optimize/argumentpropagation/ArgumentPropagationUpperBoundWithInterfacesTest.java
https://r8-review.googlesource.com/80041
Branch: 4.0
commit 100d0b0162ec31385e004be1fdf0e35103f5df1d
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Wed May 31 11:28:09 2023
Fix inadequate argument propagation in presence of join types
Bug:
Change-Id: Ic00ce43da9839884cbb19a87a7b43020951c3114
M src/main/java/com/android/tools/r8/optimize/argumentpropagation/propagation/VirtualDispatchMethodArgumentPropagator.java
M src/test/java/com/android/tools/r8/optimize/argumentpropagation/ArgumentPropagationUpperBoundWithInterfacesTest.java
ap...@google.com <ap...@google.com> #19
Project: r8
Branch: 4.0
commit 9a0e85220f3e4627d126a55ba6a778a57cecaa06
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Wed May 31 11:27:44 2023
Reproduce inadequate argument propagation in presence of join types
Bug: b/284188592
Change-Id: Ic1ad298f99b286d681b52b338349a2d4510610bd
A src/test/java/com/android/tools/r8/optimize/argumentpropagation/ArgumentPropagationUpperBoundWithInterfacesTest.java
https://r8-review.googlesource.com/80040
Branch: 4.0
commit 9a0e85220f3e4627d126a55ba6a778a57cecaa06
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Wed May 31 11:27:44 2023
Reproduce inadequate argument propagation in presence of join types
Bug:
Change-Id: Ic1ad298f99b286d681b52b338349a2d4510610bd
A src/test/java/com/android/tools/r8/optimize/argumentpropagation/ArgumentPropagationUpperBoundWithInterfacesTest.java
be...@gmail.com <be...@gmail.com> #20
Has this bug fixed in 4.0.54?
ch...@google.com <ch...@google.com> #21
No this was fixed in R8 4.0.63. You can build with this version by adding the following to settings.gradle
:
pluginManagement {
buildscript {
repositories {
mavenCentral()
maven {
url = uri("https://storage.googleapis.com/r8-releases/raw")
}
}
dependencies {
classpath("com.android.tools:r8:4.0.63")
}
}
}
Description
In R8 4.0.54, the method is as follows:
private boolean shouldActivateMethodStateGuardedByBounds(
ClassTypeElement upperBound, DexProgramClass currentClass, DexProgramClass superClass) {
ClassTypeElement classType =
TypeElement.fromDexType(currentClass.getType(), maybeNull(), appView).asClassType();
// When propagating argument information for interface methods downwards from an interface to
// a non-interface we need to account for the parent classes of the current class.
if (superClass.isInterface()
&& !currentClass.isInterface()
&& currentClass.getSuperType() != appView.dexItemFactory().objectType) {
return classType.lessThanOrEqualUpToNullability(upperBound, appView);
}
return classType.equalUpToNullability(upperBound);
}
But there is a corner case, i.e upperBound and classType point to the same class, while classType.equalUpToNullability(upperBound); return false. And the reason is that upperBound has more interfaces than classType because of some vertical optimization.
As a result, some virtual method will be thought not reachable and put into throw null in method's body.