R8 Flurry SDK crash with AGP 8.2.0 [315877832]

Fixed

Bug

Status Update

No update yet.

Description

be...@citymapper.com

created issue #1

Dec 12, 2023 12:30PM

Attached a sample project which reproduces the crash when the release variant is built. Change AGP back to 8.1.4 and the crash no longer occurs.

The bytecode after running through R8 looks wrong

The original code in the constructor of com.flurry.sdk.ft in the SDK is (according to the intellij decompiler)

    if (this.a == null) {
        this.a = new HashMap();
    }

    this.a.clear();

With the R8 in 8.2.0, the whole constructor is inlined a few levels above, and the resulting bytecode assigns the field but looks like the local reference ends up in v1 instead of v0?

    iget-object v0, v6, Lcom/flurry/sdk/ft;->a:Ljava/util/Map;

    if-nez v0, :cond_116

    new-instance v1, Ljava/util/HashMap;

    invoke-direct {v1}, Ljava/util/HashMap;-><init>()V

    iput-object v1, v6, Lcom/flurry/sdk/ft;->a:Ljava/util/Map;

    :cond_116
    invoke-interface {v0}, Ljava/util/Map;->clear()V

With 8.1.4 the inlining doesn't happen, and looks like there's some redundancy in the bytecode, but it's at least correct.

    iget-object p1, p0, Lcom/flurry/sdk/ft;->a:Ljava/util/Map;

    if-nez p1, :cond_25

    new-instance p1, Ljava/util/HashMap;

    invoke-direct {p1}, Ljava/util/HashMap;-><init>()V

    iput-object p1, p0, Lcom/flurry/sdk/ft;->a:Ljava/util/Map;

    :cond_25
    iget-object p1, p0, Lcom/flurry/sdk/ft;->a:Ljava/util/Map;

    invoke-interface {p1}, Ljava/util/Map;->clear()V

    iget-object p1, p0, Lcom/flurry/sdk/ft;->a:Ljava/util/Map;

R8Bug.zip

902 KB

Download

Comments

ch...@google.com <ch...@google.com> Dec 12, 2023 12:45PM

Reassigned to ch...@google.com.

ch...@google.com <ch...@google.com> #2Dec 13, 2023 09:46AM

for example, many different devices return the same longitude and latitude.such as : longitude is 121.474000 and latitude is 31.230001.
i donnot understand why is the data the same?

ch...@google.com <ch...@google.com> #3Dec 13, 2023 10:00AM

the fractional part of the location data is exactly the same.

ap...@google.com <ap...@google.com> #4Dec 13, 2023 01:23PM

Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:

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:

https://developer.android.com/studio/debug/bug-report#bugreportdevice

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.

ap...@google.com <ap...@google.com> #5Dec 13, 2023 01:36PM

Marked as fixed.

Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.

ap...@google.com <ap...@google.com> #6Dec 13, 2023 02:02PM

I only aply permission android.permission.ACCESS_COARSE_LOCATION.I use android.location.Location in the program.
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

ap...@google.com <ap...@google.com> #7Dec 13, 2023 02:02PM

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

ap...@google.com <ap...@google.com> #8Dec 13, 2023 02:02PM

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.

ap...@google.com <ap...@google.com> #9Dec 13, 2023 02:30PM

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> #10Dec 13, 2023 02:30PM

Thank you very much! it is very useful to me . It solved my confusion.

ap...@google.com <ap...@google.com> #11Dec 13, 2023 02:30PM

Project: r8
Branch: 8.3

commit 80b695a3fd870c1a059562eb1d9e1773295aec58
Author: Christoffer Quist Adamsen <christofferqa@google.com>
Date: Wed Dec 13 15:26:30 2023

Fix incorrect instance-get canonicalization

Fixes:

b/315877832

Change-Id: I09db1a0e0cb1b873417a1fe55a3ca5d782e77455

M src/main/java/com/android/tools/r8/ir/optimize/ConstantCanonicalizer.java
M src/test/java/com/android/tools/r8/ir/optimize/canonicalization/EffectivelyFinalInstanceFieldCanonicalizationAfterConstructorInliningTest.java

https://r8-review.googlesource.com/87127

sg...@google.com <sg...@google.com> #12Dec 14, 2023 09:56AM

The fix has been merged to the 8.2 release branch in 8.2.42, and you can use that version by merging the following into settings.gradle or settings.gradle.kts:

pluginManagement {
    buildscript {
        repositories {
            mavenCentral()
            maven {
                url = uri("https://storage.googleapis.com/r8-releases/raw")
            }
        }
        dependencies {
            classpath("com.android.tools:r8:8.2.42")
        }
    }
}

The fix is scheduled for the next patch release, so please remember to remove this use of a specific R8 version again when updating AGP to a version with the fix.

an...@google.com <an...@google.com> #13Dec 26, 2023 06:01PM

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

Android Studio Iguana | 2023.2.1 Beta 1
Android Gradle Plugin 8.3.0-beta01

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

an...@google.com <an...@google.com> #14Jan 3, 2024 06:01PM

The fixes for this issue are now also available in:

Android Studio Hedgehog | 2023.1.1 Patch 1
Android Gradle Plugin 8.2.1

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

mk...@opera.com <mk...@opera.com> #15Jan 5, 2024 05:35AM

We encountered similar issue. Tried R8 8.2.42 as suggested in this thread and the issue is gone, but the minifyReleaseWithR8 task became super slow. Haven't done any detailed measures yet but just looking at logs from our CI the minifyReleaseWithR8 takes:

AGP 8.0.2 -> ~6 minutes
AGP 8.2.0 -> Varies between runs but is usually worse than in 8.0.2, I've seen numbers in between ~ 10-15 minutes. In rare cases timeouts after 20minutes which is the limit we currently have on CI
AGP 8.2.0 with R8 8.2.42 -> Never completes within 20minutes timeout on our CI

Message last modified on Jan 5, 2024 05:37AM

ch...@google.com <ch...@google.com> #16Jan 5, 2024 08:02AM

Thanks for the feedback. It would be great if you could file a separate issue for that.

Looking over the commits that went in between R8 version 8.2.33 (AGP 8.2.0) and R8 version 8.2.42, it is not really clear that anyone should cause an additional build speed regression. Perhaps R8 8.2.40 due to Allow enums with subtypes without enum flag to be unboxed?

Would it be possible for you to share a zip dump of the compiler inputs (containing the app's JVM class files, keep rules, etc.)? That way we should be able to reproduce the issue. You can share the dump privately with christofferqa@google.com and sgjesse@google.com.

You can generate a dump like this:

./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/dumps

Alternatively, it would be great if you could share some timings from compiling using different R8 versions (e.g., 8.0.X, 8.1.75, 8.2.33, 8.2.43). You should be able to dump timing info by issuing the following command:

./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.printtimes -Dcom.android.tools.r8.printtimes.minvalue=0

You can build using a specific R8 version without changing the AGP version by making the following changes to settings.gradle.

pluginManagement {
    buildscript {
        repositories {
            mavenCentral()
            maven {
                url = uri("https://storage.googleapis.com/r8-releases/raw")
            }
        }
        dependencies {
            classpath("com.android.tools:r8:8.2.43")
        }
    }
}

Message last modified on Jan 5, 2024 09:09AM