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.

This is now fixed, and you can use R8 8.1.67 with AGP 8.1.1 (or 8.1.0). The fix did not make it into AGP 8.1.1, which shipped with Android Studio Giraffe Patch 1 yesterday.

For AGP 8.0.x use 8.0.64. For AGP 8.2.x use 8.2.26 which will go into Android Studio Hedgehog / AGP 8.2 Beta 2.

To use a specific R8 version (e.g. 8.1.67) merge 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.1.67")
        }
    }
}

Thank you for the report. Using -assumenosideeffects can have undesired effects at runtime

Sorry to jump on this issue, but since this is something that came up a few times but never ended in an official statement about it maybe now is the time to ask again.

I'm also using:

-assumenosideeffects class kotlin.jvm.internal.Intrinsics {
	public static void checkNotNull(...);
	public static void checkExpressionValueIsNotNull(...);
	public static void checkNotNullExpressionValue(...);
	public static void checkParameterIsNotNull(...);
	public static void checkNotNullParameter(...);
	public static void checkReturnedValueIsNotNull(...);
	public static void checkFieldIsNotNull(...);
	public static void throwUninitializedPropertyAccessException(...);
	public static void throwNpe(...);
	public static void throwJavaNpe(...);
	public static void throwAssert(...);
	public static void throwIllegalArgument(...);
	public static void throwIllegalState(...);
}

As even with R8 full mode it reduce the dex file by aprox 100 Kb.

What is the official R8 team position about those rules, there's often remarks they probably should not be used, but no definitive answer about yes or no.

Is there any possible side effect about those specific ones, that could overcome the dex size gain?

In general using -assumenosideeffects can be dangerous as it can unconditionally remove code.

In the case of the check* methods the null checks will be removed. In most cases that will just postpone the NPE until later when the null value is accessed. However, that might be way later in the program execution (e.g. the value is used to set a field which is then accessed in a completely different code path). So the code will have different behavior. In the case of a pure Kotlin project this should (almost) be safe, as nullability is checked at compile time.

It is also possible to have the Kotlin compiler not emitting null checks using something like this:

android {
    kotlinOptions {
        freeCompilerArgs = listOf(
            "-Xno-param-assertions",
            "-Xno-call-assertions",
            "-Xno-receiver-assertions"
        )
    }
}

However, that only works for the code which is compiled from source and not binary dependencies.

For the throw* I don't know when they are actually generated by the Kotlin compiler, so how removing these affects the application soundness I cannot say.

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 Hedgehog | 2023.1.1 Beta 3
• Android Gradle Plugin 8.2.0-beta03

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!

The fixes for this issue are now also available in:

• Android Studio Giraffe | 2022.3.1 Patch 2
• Android Gradle Plugin 8.1.2

We encourage you to try the latest update.

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