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.

Make sure that the androidx.dev repository above is added to the definition of the repositories in that project, whether defined in that project, root build.gradle or settings.gradle.kts

Sadly it doesn't fix the original issue from comment#1, but it fixes the one from comment#8.

Can you add the following task to your build.gradle in the app module

import com.android.build.api.artifact.ScopedArtifact
import com.android.build.api.variant.ScopedArtifacts

import java.util.zip.ZipEntry
import java.util.zip.ZipFile

abstract class PrintClassesJars extends DefaultTask {
    private static String PROBLEMATIC_CLASS = "com/google/android/youtube/player/internal/u.class"

    @InputFiles
    abstract ListProperty<RegularFile> getAllJars()

    @InputFiles
    abstract ListProperty<Directory> getAllDirectories()

    @TaskAction
    void findJars() {
        getAllJars().get().forEach { file ->
            try (ZipFile zipFile = new ZipFile(file.asFile)) {
                Enumeration<? extends ZipEntry> zipFileEntries = zipFile.entries()
                while (zipFileEntries.hasMoreElements()) {
                    if (zipFileEntries.nextElement().getName() == PROBLEMATIC_CLASS) {
                        print("Found a jar packaging the class at " + file.asFile.getAbsolutePath())
                    }
                }
            }
        }

        getAllDirectories().get().forEach { dir ->
            dir.asFile.traverse(type: groovy.io.FileType.FILES) { file ->
                String relativePath = dir.asFile.toURI().relativize(file.toURI()).getPath()
                if (relativePath == PROBLEMATIC_CLASS) {
                    print("Found a directory containing the class at " + dir.asFile.getAbsolutePath())
                }
            }
        }
    }
}

androidComponents {
    onVariants(selector().all(), { variant ->
        TaskProvider taskProvider = project.tasks.register(
            variant.getName() + "PrintJars", PrintClassesJars.class
        )
        variant.artifacts.forScope(ScopedArtifacts.Scope.ALL)
                .use(taskProvider)
                .toGet(
                        ScopedArtifact.CLASSES.INSTANCE,
                        { it.allJars },
                        { it.allDirectories }
                )
    })
}

and then run :app:releasePrintJars and share the finding?

Thanks, there are two paths found. One points to the actual file in the project, the other refers to some gradle cache.

Found a jar packaging the class at (...)/.gradle/caches/transforms-3/609859a5ed3d35b3aad372e65a0712b8/transformed/YouTubeAndroidPlayerApi-jetified.jar
Found a jar packaging the class at (...)/work/mobile/android/libs/YouTubeAndroidPlayerApi-jetified.jar

Running the same on AGP-8.1.0-alpha11 finds only one path in the gradle cache

Found a jar packaging the class at (...).gradle/caches/transforms3/5a0d2eeed7e95fe38c5a827458e0139c/transformed/YouTubeAndroidPlayerApi-jetified.jar

Is the information from comment#14 helpful in any way to trace the root cause? If not is there anything else we can do to help?

Interesting, it seems that the jar is transformed with an artifact transform, but it's not clear which artifact transform is the culprit. Can you run ./gradlew :app:releasePrintJars --debug | grep YouTubeAndroidPlayerApi-jetified.jar and attach the result?

Also you can add the following to your build.gradle as a workaround, it'll make the build a bit slower but it can unblock AGP upgrade.

import com.android.build.api.artifact.ScopedArtifact
import com.android.build.api.variant.ScopedArtifacts

import java.util.jar.JarEntry
import java.util.jar.JarFile
import java.util.jar.JarOutputStream
import java.util.zip.ZipEntry
import java.util.zip.ZipFile

abstract class FilterOutTransformedLocalJar extends DefaultTask {
    private static String PROBLEMATIC_JAR_SUFFIX =
            "transformed/YouTubeAndroidPlayerApi-jetified.jar"

    @InputFiles
    abstract ListProperty<RegularFile> getAllJars()

    @InputFiles
    abstract ListProperty<Directory> getAllDirectories()

    @OutputFiles
    abstract RegularFileProperty getOutput()

    @TaskAction
    void filterJars() throws IOException {
        OutputStream jarOutput = new JarOutputStream(new BufferedOutputStream(new FileOutputStream(
                output.get().getAsFile()
        )))

        allJars.get().forEach { file ->
            if (!file.asFile.absolutePath.endsWith(PROBLEMATIC_JAR_SUFFIX)) {
                JarFile jarFile = new JarFile(file.asFile)
                for (Enumeration<JarEntry> e = jarFile.entries(); e.hasMoreElements();) {
                    JarEntry jarEntry = e.nextElement()
                    if (!jarEntry.isDirectory() && !jarEntry.name.startsWith("META-INF")) {
                        jarOutput.putNextEntry(new JarEntry(jarEntry.name))
                        jarFile.getInputStream(jarEntry).withCloseable {
                            jarOutput << it
                        }
                        jarOutput.closeEntry()
                    }
                }
                jarFile.close()
            }
        }

        allDirectories.get().forEach { directory ->
            directory.asFile.traverse(type: groovy.io.FileType.FILES) { file ->
                String relativePath = directory.asFile.toURI().relativize(file.toURI()).getPath()
                jarOutput.putNextEntry(new JarEntry(relativePath.replace(File.separatorChar, '/' as char)))
                new FileInputStream(file).withCloseable { inputStream ->
                    jarOutput << inputStream
                }
                jarOutput.closeEntry()
            }
        }
        jarOutput.close()
    }
}

androidComponents {
    onVariants(selector().all(), { variant ->
        TaskProvider taskProvider = project.tasks.register(
                variant.getName() + "FilterJar", FilterOutTransformedLocalJar.class
        )
        variant.artifacts.forScope(ScopedArtifacts.Scope.ALL)
                .use(taskProvider)
                .toTransform(
                    ScopedArtifact.CLASSES.INSTANCE,
                    { it.getAllJars() },
                    { it.getAllDirectories() },
                    { it.getOutput() }
                )
    })
}

Thanks for the potential workaround. Please find the output of the mentioned task with --debug flag.

Does the attached output give you any clue? I see plenty of transformations being done but i don't see any particular task that requests them.

Yes, the problem was with the AsmTransform, I assume you're applying hilt in that app project? I was able to reproduce the issue with an app module that contains dynamic feature deps, minification enabled, local jar dependency and an asm transformation that transforms all dependencies. I've also merged a fix.

Can you try with AGP 8.3.0-dev with the following artifacts repo and see if that fixes the problem?

maven {
    url = uri("https://androidx.dev/studio/builds/10746020/artifacts/artifacts/repository")
}

Yes, we do use hilt indeed.I tried to reproduce it by adding hilt to my toy project when I've seen some hilt related transformation along the executed transforms, it didn't reproduce to me but maybe I missed something.

The given fix works! Thanks for the effort put in finding the root cause. Is there any chance there will be an update to 8.1.2 including it anytime soon?

Great, thanks for confirming. Unfortunately, it's too late for the change to be included in 8.1.2. But it will be available in 8.2.0-beta04 and 8.3.0-alpha03.

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 Canary 3
• Android Gradle Plugin 8.3.0-alpha03

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

We encourage you to try the latest update.

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

This is still broken in Iguana stable when attempting to build release .aab (app bundle). Breakage observed with both AGP 8.1.0 and 8.2.0. Had to downgrade AGP to 8.0.2 to get release .aab to build.

As requested raised new issue 329134201