Status Update
Comments
ar...@google.com <ar...@google.com>
an...@airbnb.com <an...@airbnb.com> #2
i donnot understand why is the data the same?
ri...@google.com <ri...@google.com>
ch...@google.com <ch...@google.com> #3
an...@airbnb.com <an...@airbnb.com> #4
What steps are needed to reproduce this issue? Frequency of occurrence?
Which Android build are you using? (e.g. AP4A.241205.013.A1)
Which device did you use to reproduce this issue?
Can you confirm if this issue is reproducible on a Pixel/Nexus device?
Please provide a sample project or apk to reproduce the issue. Also mention the steps to be followed for reproducing the issue with the given sample project or apk.
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer:
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the bug report and screenshot to google drive and share the folder to android-bugreport@google.com, then share the link here.
ch...@google.com <ch...@google.com> #5
Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.
ch...@google.com <ch...@google.com> #6
for example,we hava 100 users.
20 users returned the same location information, longitude is 121.474000 and latitude is 31.230001。
30 users returned the same location information, longitude is 122.474000 and latitude is 32.230001。
15 users returned the same location information, longitude is 120.474000 and latitude is 30.230001。
as for Android build,all versions have it.
I dont reprodouce this issue.
what may be the cause of this issue?please
an...@airbnb.com <an...@airbnb.com> #7
We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
ch...@google.com <ch...@google.com> #8
Thanks for reporting this issue.
COARSE_LOCATION typically takes location information from the nearby cell tower. If many users are near the same cell tower, each of those users will be given the same position. Using a FINE position will give much more detailed information.
Also, in certain areas, for privacy reasons, a less-exact location will be given, and that less-exact location might be identical for many users. Again, a fine-location configuration will return more precise location data.
ch...@google.com <ch...@google.com> #9
We believe with reference to the above comment, your query has been answered, hence closing the bug. Please feel free to re-open the issue in the future if desired.
ap...@google.com <ap...@google.com> #10
ap...@google.com <ap...@google.com> #11
Branch: main
commit 18021f50bf2661a1c1aa6312004b3da2ef107ca7
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 08:22:16 2023
Only allow instances of final classes in filled-new-array
Bug:
Change-Id: I0554aaaba74509a5afff9147ba11e6cfd68c7e14
M src/main/java/com/android/tools/r8/ir/conversion/passes/ArrayConstructionSimplifier.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
M src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #12
Branch: main
commit 5cbe19ee74c39112578bef2ada4b1dc9d5e795d1
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 08:22:12 2023
Reproduce error from filled-new-array with subtype and missing interface
Bug:
Change-Id: I128ca78d97d5893722b857714f51364e69897186
M src/test/java/com/android/tools/r8/Dex2OatTestRunResult.java
A src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #13
Branch: main
commit ae077a205717fb7a8f635ee100acde7c8f659a2f
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 09:48:34 2023
Aggressively map into InvokeNewArray then eliminate in backend
Bug:
Change-Id: I75ea3ad4172ae0564b356de79b331144053bf79e
M src/main/java/com/android/tools/r8/graph/DexType.java
M src/main/java/com/android/tools/r8/ir/code/ArrayAccess.java
M src/main/java/com/android/tools/r8/ir/code/ArrayPut.java
M src/main/java/com/android/tools/r8/ir/code/BasicBlock.java
M src/main/java/com/android/tools/r8/ir/code/BasicBlockInstructionListIterator.java
M src/main/java/com/android/tools/r8/ir/code/IRMetadata.java
M src/main/java/com/android/tools/r8/ir/code/NewArrayEmpty.java
M src/main/java/com/android/tools/r8/ir/conversion/IRConverter.java
M src/main/java/com/android/tools/r8/ir/conversion/PrimaryR8IRConverter.java
M src/main/java/com/android/tools/r8/ir/conversion/passes/ArrayConstructionSimplifier.java
A src/main/java/com/android/tools/r8/ir/conversion/passes/FilledNewArrayRewriter.java
M src/main/java/com/android/tools/r8/ir/desugar/desugaredlibrary/apiconversion/DesugaredLibraryWrapperSynthesizer.java
M src/main/java/com/android/tools/r8/ir/desugar/varhandle/VarHandleDesugaring.java
M src/main/java/com/android/tools/r8/ir/optimize/enums/EnumUnboxerImpl.java
M src/main/java/com/android/tools/r8/ir/optimize/enums/EnumUnboxingRewriter.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
M src/test/java/com/android/tools/r8/rewrite/arrays/ArrayWithDataLengthRewriteTest.java
M src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #14
Branch: 8.1
commit 964ccac8e5b4a5712a6dc505f4a3d21e5d4c54b0
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:50:08 2023
Reproduce error from filled-new-array with subtype and missing interface
Bug:
Change-Id: I128ca78d97d5893722b857714f51364e69897186
M src/test/java/com/android/tools/r8/Dex2OatTestRunResult.java
A src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #15
Branch: 8.1
commit 77fb862cd612fe3a7cb0f4aa35b3ee4003bcd12e
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:49:55 2023
Avoid conflating register sets at move-exception
In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.
Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).
The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.
Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.
The instructions must be laid out in sequence as:
move r11, r3
move r1, r11
When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:
move r1, r11
move r11, r3
Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.
Bug:
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/ir/regalloc/SpillMoveSet.java
ap...@google.com <ap...@google.com> #16
Branch: 8.1
commit 439b2606165d2a4903d80b4fab96dcb90ab095bb
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 11:21:25 2023
Only allow instances of final classes in filled-new-array
Bug:
Change-Id: I0554aaaba74509a5afff9147ba11e6cfd68c7e14
M src/main/java/com/android/tools/r8/ir/optimize/CodeRewriter.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
M src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #17
Branch: 8.1
commit 31d320f3c151ad981fab2d901668566ce862c08f
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 11:21:39 2023
Version 8.1.61
Bug:
Change-Id: Idefa23cb18b94ee8912dc93154820f2b40da714a
M src/main/java/com/android/tools/r8/Version.java
ap...@google.com <ap...@google.com> #18
Branch: 8.2
commit 937b41f403fd2972f9e74a1441b40e4c99c34657
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:39:02 2023
Only allow instances of final classes in filled-new-array
Bug:
Change-Id: I0554aaaba74509a5afff9147ba11e6cfd68c7e14
M src/main/java/com/android/tools/r8/ir/conversion/passes/ArrayConstructionSimplifier.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
M src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #19
Branch: 8.2
commit bd0c69e00cf701477bce85095a3f15f544692c2f
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:38:51 2023
Reproduce error from filled-new-array with subtype and missing interface
Bug:
Change-Id: I128ca78d97d5893722b857714f51364e69897186
M src/test/java/com/android/tools/r8/Dex2OatTestRunResult.java
A src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #20
Branch: 8.2
commit b44cd016482f23c7ea9309d1c3f05fc982300b91
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:38:39 2023
Avoid conflating register sets at move-exception
In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.
Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).
The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.
Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.
The instructions must be laid out in sequence as:
move r11, r3
move r1, r11
When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:
move r1, r11
move r11, r3
Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.
Bug:
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/ir/regalloc/SpillMoveSet.java
ap...@google.com <ap...@google.com> #21
Branch: 8.2
commit e5053eb5908dae15c3c090aa097982d1172639e1
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:39:14 2023
Version 8.2.22
Bug:
Change-Id: I1e59e6fb494a79a9961a2a8a86add05519f2c6f9
M src/main/java/com/android/tools/r8/Version.java
ap...@google.com <ap...@google.com> #22
Branch: 8.1
commit 964ccac8e5b4a5712a6dc505f4a3d21e5d4c54b0
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:50:08 2023
Reproduce error from filled-new-array with subtype and missing interface
Bug:
Change-Id: I128ca78d97d5893722b857714f51364e69897186
M src/test/java/com/android/tools/r8/Dex2OatTestRunResult.java
A src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #23
Branch: 8.1
commit 77fb862cd612fe3a7cb0f4aa35b3ee4003bcd12e
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 10:49:55 2023
Avoid conflating register sets at move-exception
In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.
Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).
The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.
Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.
The instructions must be laid out in sequence as:
move r11, r3
move r1, r11
When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:
move r1, r11
move r11, r3
Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.
Bug:
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/ir/regalloc/SpillMoveSet.java
ap...@google.com <ap...@google.com> #24
Branch: 8.1
commit 439b2606165d2a4903d80b4fab96dcb90ab095bb
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 11:21:25 2023
Only allow instances of final classes in filled-new-array
Bug:
Change-Id: I0554aaaba74509a5afff9147ba11e6cfd68c7e14
M src/main/java/com/android/tools/r8/ir/optimize/CodeRewriter.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
M src/test/java/com/android/tools/r8/workaround/FilledNewArrayFromSubtypeWithMissingInterfaceWorkaroundTest.java
ap...@google.com <ap...@google.com> #25
Branch: 4.0
commit 684c429d5cec188ef3df3a466cb098ec9837e1e7
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 12:55:09 2023
Avoid conflating register sets at move-exception
In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.
Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).
The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.
Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.
The instructions must be laid out in sequence as:
move r11, r3
move r1, r11
When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:
move r1, r11
move r11, r3
Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.
Bug:
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/ir/regalloc/SpillMoveSet.java
ap...@google.com <ap...@google.com> #26
Branch: 4.0
commit c9bd88348443b3b3571568215179f04e0db8264f
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 12:56:50 2023
Version 4.0.65
Bug:
Change-Id: I2030aa0f72a124ded924a6c39287351d0f2cf1a7
M src/main/java/com/android/tools/r8/Version.java
ap...@google.com <ap...@google.com> #27
Branch: 8.0
commit c2fadd146f0a752ee81a06c7129ac9667884fdea
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 12:54:38 2023
Avoid conflating register sets at move-exception
In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.
Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).
The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.
Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.
The instructions must be laid out in sequence as:
move r11, r3
move r1, r11
When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:
move r1, r11
move r11, r3
Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.
Bug:
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/ir/regalloc/SpillMoveSet.java
ap...@google.com <ap...@google.com> #28
Branch: 8.0
commit 2edf53642866e17052a8e05c4b4a39fff0c2da52
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 12:54:48 2023
Version 8.0.60
Bug:
Change-Id: I6aa0d73858b8ee7b314c86dcef6728e7476cc773
M src/main/java/com/android/tools/r8/Version.java
ap...@google.com <ap...@google.com> #29
Branch: 4.0
commit 684c429d5cec188ef3df3a466cb098ec9837e1e7
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Fri Aug 11 12:55:09 2023
Avoid conflating register sets at move-exception
In-resolution moves to a move-exception instruction cannot be inserted before the move-exception instruction.
Previously, we worked around this by adding the in-resolution moves to a move-exception instruction as in-resolution moves to the goto instruction that is always after the move-exception instruction (since catch handlers are split blocks).
The in-resolution moves to the move-exception instruction must be inserted before any of the in-resolution moves to the goto instruction, however. By conflating the two in-resolution move sets, the subsequent parallel move scheduling may incorrectly reorder two moves.
Example: Consider that the in-resolution moves for the move-exception instruction is the set { move r11, r3 } and the in-resolution moves for the goto instruction is the set { move r1, r11 }.
The instructions must be laid out in sequence as:
move r11, r3
move r1, r11
When the two sets are conflated as { move r11, r3; move r1, r11 }, parallel move scheduling will instead layout the moves as follows, which may lead to arbitrary errors:
move r1, r11
move r11, r3
Fix: Instead of conflating the two in-resolution move sets, this CL simply inserts the in-resolution moves for the move-exception instruction immediately after the move-exception instruction.
Bug:
Change-Id: I3975902ce63fb1f03914441c7c7357c839ff8a74
M src/main/java/com/android/tools/r8/ir/regalloc/LinearScanRegisterAllocator.java
M src/main/java/com/android/tools/r8/ir/regalloc/SpillMoveSet.java
ap...@google.com <ap...@google.com> #30
Branch: main
commit 4818724dc6821648d5b52d8db3453fe2a7471dc4
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Sun Aug 13 08:19:53 2023
Update FilledNewArray test expectations
Bug:
Change-Id: Ic9e62aa64cf8fef177d558bad745a6d474fb0fda
M src/main/java/com/android/tools/r8/ir/conversion/passes/ArrayConstructionSimplifier.java
M src/test/java/com/android/tools/r8/TestParameters.java
M src/test/java/com/android/tools/r8/rewrite/arrays/FilledArrayDataRemoveCheckCastTest.java
M src/test/java/com/android/tools/r8/rewrite/arrays/SimplifyArrayConstructionTest.java
ap...@google.com <ap...@google.com> #31
Branch: 8.2
commit 329bb7c1dab09933316bafedc05ffddb95111b19
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Sun Aug 13 13:52:23 2023
Update FilledNewArray test expectations
Bug:
Change-Id: Ic9e62aa64cf8fef177d558bad745a6d474fb0fda
M src/main/java/com/android/tools/r8/ir/conversion/passes/ArrayConstructionSimplifier.java
M src/test/java/com/android/tools/r8/TestParameters.java
M src/test/java/com/android/tools/r8/rewrite/arrays/FilledArrayDataRemoveCheckCastTest.java
M src/test/java/com/android/tools/r8/rewrite/arrays/SimplifyArrayConstructionTest.java
ap...@google.com <ap...@google.com> #32
Branch: 8.2
commit a0efa73ffad29cbb7f1bc289e0091dfcc86422d3
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Sun Aug 13 13:52:43 2023
Version 8.2.23
Bug:
Change-Id: Ia9d86f84a5fa4820d7afd7fbe0bba4ea7e097567
M src/main/java/com/android/tools/r8/Version.java
ap...@google.com <ap...@google.com> #33
Branch: 8.1
commit 86dcafc9f0fc6ef2ee7e4d1c93b3c1f17e4b3292
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Sun Aug 13 14:07:20 2023
Update FilledNewArray test expectations
Bug:
Change-Id: Ic9e62aa64cf8fef177d558bad745a6d474fb0fda
M src/main/java/com/android/tools/r8/ir/optimize/CodeRewriter.java
M src/test/java/com/android/tools/r8/TestParameters.java
M src/test/java/com/android/tools/r8/rewrite/arrays/FilledArrayDataRemoveCheckCastTest.java
M src/test/java/com/android/tools/r8/rewrite/arrays/SimplifyArrayConstructionTest.java
ap...@google.com <ap...@google.com> #34
Branch: 8.2
commit 329bb7c1dab09933316bafedc05ffddb95111b19
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Sun Aug 13 13:52:23 2023
Update FilledNewArray test expectations
Bug:
Change-Id: Ic9e62aa64cf8fef177d558bad745a6d474fb0fda
M src/main/java/com/android/tools/r8/ir/conversion/passes/ArrayConstructionSimplifier.java
M src/test/java/com/android/tools/r8/TestParameters.java
M src/test/java/com/android/tools/r8/rewrite/arrays/FilledArrayDataRemoveCheckCastTest.java
M src/test/java/com/android/tools/r8/rewrite/arrays/SimplifyArrayConstructionTest.java
ch...@google.com <ch...@google.com> #35
This should now be fixed in R8 4.0.66, 8.0.61, 8.1.63 and 8.2.23.
The verification error reported in
Additionally, I cherry-picked fixes to avoid another verification error with R8 8.1.63 and 8.2.23. This was caused by R8 8.1 and 8.2 starting to use the fillednewarray instruction in more cases, which triggered a bug in ART.
It would be great if you could confirm if your issue is resolved with the latest version.
an...@airbnb.com <an...@airbnb.com> #36
Sorry for late reply, was out on PTO, but I just also verified the fix with the original issue we had. Thank you!
Description
DESCRIBE THE ISSUE IN DETAIL:
Our app started crashing today out of the blue without any code change (or tooling version upgrades) to the code in question:
I saw several of those fixed in the past months so we updated to latest version of R8 (4.0.64) but we are still seeing it.
We are working around this right now by just keeping the class in question but I think this is a bug in R8.
I included the broken .aab and .apk files and also an input dump and shared it with "the usual" people. Happy to share it with others if required, or provide more information.
IMPORTANT: Please readhttps://developer.android.com/studio/report-bugs.html carefully and supply
all required information.
Studio Build: Not relevant Version of Gradle Plugin: 7.4.2 Version of Kotlin: 1.8.21 Version of Gradle: 7.6 Version of Java: openjdk 17.0.8 2023-07-18 LTS OS: Linux