IssueTracker

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

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

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.

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.

Indeed this is done in LazyCfCode.java.

It looks as if the given input bytecode is invalid to me.

         0: aload_0
         1: getfield      #25                 // Field org/.../GF2nField.mDegree:I
         4: dup
         5: dup2
         6: istore_2
         7: multianewarray #36,  2            // class "[[I"
        11: iload_2
        12: multianewarray #36,  2            // class "[[I"

After the dup2, the stack is [mDegree:I, mDegree:I, mDegree:I, mDegree:I]. Then we istore_2 so before the first multianewarray we have [mDegree:I, mDegree:I, mDegree:I]. IIUC, multianewarray consumes two ints from the stack, so it leaves the stack as [mDegree:I, arr7:[[I]. Then we iload_2 and get [mDegree:I, arr7:[[I, mDegree:I], and then again do multianewarray, which should consume two ints from the stack, but only the uppermost value on the stack is an int.

zerny@ does this look right to you?

Repro project is in /google/data/rw/teams/r8/bugs/b335663479/repro.zip and dump at /google/data/rw/teams/r8/bugs/b335663479/dump.zip.

The Integer.MAX_VALUE is just to avoid computing the actual max. It should not cause an issue.

To the reporter: is this a coverage build or do you have some other plugin running that might transform the bytecode?

In your repro project I can find an original version of the code that does not have the issue:

javap -p -v -cp ./bc/mylibrary/libs/bcprov-jdk15to18-1.77-no-sign.jar org.bouncycastle.bangsun.pqc.legacy.math.linearalgebra.GF2nONBField
<snip>
int[][] invMatrix(int[][]);
    descriptor: ([[I)[[I
    flags: (0x0000)
    Code:
      stack=4, locals=6, args_size=2
         0: aload_0
         1: getfield      #29                 // Field mDegree:I
         4: aload_0
         5: getfield      #29                 // Field mDegree:I
         8: multianewarray #40,  2            // class "[[I"
        12: astore_2
        13: aload_1
        14: astore_2
        15: aload_0
        16: getfield      #29                 // Field mDegree:I
        19: aload_0
        20: getfield      #29                 // Field mDegree:I
        23: multianewarray #40,  2            // class "[[I"
<snip>

The subsequent input that is found in the dump.zip is incorrect however, and it appears that R8 is likely to blame. The code has a marker for an R8 classfile-to-classfile compilation:

#2 = String             #1            // ~~R8{\"backend\":\"cf\",\"compilation-mode\":\"release\",\"has-checksums\":false,\"pg-map-id\":\"1c75180\",\"r8-mode\":\"full\",\"version\":\"8.3.37\"}

I'll need to find the intermediate R8 compilation step for this to find out what is going on. I'll post back once I find out more.

Good catch. I didn't see this the first time, presumably because the build was cached so I didn't get the dump with -Dcom.android.tools.r8.dumpinputtodirectory.

Uploaded the R8 cf-to-cf dump to /google/data/rw/teams/r8/bugs/b335663479/r8-dump.zip. Feel free to assign this back to me.

I have a local repro and fix so I'll keep this one.

A fix for this has been released to the R8 branches. To use it locally you may amend your build.gradle(.kts) file with:

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

where <R8VERSION> is the appropriate version for your AGP version. For example, in AGP 8.4 use R8 version 8.4.26 or above.

For some reason the 8.4 cherry-pick is not linked in this issue. The fix CL for 8.4 is https://r8-review.git.corp.google.com/c/r8/+/91500

Great to hear. Thanks for filing the issue and for the great reproduction!

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 Jellyfish | 2023.3.1 Patch 1
• Android Gradle Plugin 8.4.1

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!