Adding srcs dir via Variant API not working as expected [352352252]

Fixed

Bug

Status Update

No update yet.

Description

da...@google.com

created issue #1

Jul 10, 2024 06:29PM

I want to add a new asset directory to the Android instrumentation tests via the Variant API, but it is not working as the DSL API. I have attached a sample project that reproduces the issue.

In the build.gradle.kts I have:

val androidComponents = extensions.findByType(AndroidComponentsExtension::class.java)
androidComponents!!.onVariants { variant ->
  if (variant is HasAndroidTest) {
    variant.androidTest?.sources?.assets?.addStaticSourceDirectory("$projectDir/schemas")
  }
}

but when I run my test that validates that the asset file is present, it fails:

❯ ./gradlew app:cAT --rerun-tasks

> Task :app:connectedDebugAndroidTest
Starting 1 tests on Pixel_8_API_33(AVD) - 13

dany.agp.bug.ExampleInstrumentedTest > checkAssetFile[Pixel_8_API_33(AVD) - 13] FAILED 
        java.io.FileNotFoundException: HelloWorld.txt
        at android.content.res.AssetManager.nativeOpenAsset(Native Method)
Tests on Pixel_8_API_33(AVD) - 13 failed: There was 1 failure(s).

Finished 1 tests on Pixel_8_API_33(AVD) - 13

> Task :app:connectedDebugAndroidTest FAILED

I can also see the APK is missing the files:

❯ unzip -l ./app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk | grep assets

if I comment out the Variant APIs lines above and instead use the 'older' DSL:

android {
  sourceSets {
    getByName("androidTest").assets.srcDir("$projectDir/schemas")
  }
}

then things work as expected:

❯ ./gradlew app:cAT --rerun-tasks                                                           

> Task :app:connectedDebugAndroidTest
Starting 1 tests on Pixel_8_API_33(AVD) - 13

Finished 1 tests on Pixel_8_API_33(AVD) - 13

BUILD SUCCESSFUL in 17s

and the APK also contains the expected asset files:

❯ unzip -l ./app/build/outputs/apk/androidTest/debug/app-debug-androidTest.apk | grep assets
        5  01-01-1981 01:01   assets/HelloWorld.txt

Let me know if you need any more information.

AGPAssetsDirBug.zip

106 KB

Download

Comments

sp...@google.com <sp...@google.com> #2Jul 10, 2024 06:49PM

Assigned to sp...@google.com.

deleted

da...@google.com <da...@google.com> #3Jul 10, 2024 06:55PM

(reposting under work account)

We have been hitting this issue constantly. Is it possible to configure those tasks to be non cacheable as a workaround or is that only possible inside of AGP?

sp...@google.com <sp...@google.com> #4Jul 10, 2024 07:01PM

Currently the only way to disable caching for dexing transforms is to patch AGP manually by providing a patched DexTransform.kt file in buildSrc. Please see https://issuetracker.google.com/169266011#comment27, section on "Workarounds" for an example.

da...@google.com <da...@google.com> #5Jul 10, 2024 07:20PM

Thanks. Ignoring potential build perf impacts, if we essentially commented out the processIncrementally block in DexingTransform.kt and always ran non-incrementally, would that workaround this issue?

sp...@google.com <sp...@google.com> #6Jul 10, 2024 07:23PM

Yes, always run the dex transform non-incrementally is another workaround.

sp...@google.com <sp...@google.com> #7Jul 11, 2024 05:32PM

Is it possible to do same patch with included build?

sp...@google.com <sp...@google.com> #8Jul 12, 2024 02:42PM

I guess so, could you give it a try?

sp...@google.com <sp...@google.com> #9Jul 22, 2024 07:39PM

Marked as fixed.

I've tried(not very neat) but it only work with buildSrc

Anyway, what about issue, I've tried a lot of attempts to fix and helped only turn off jacoco transformation `useJacocoTransformInstrumentation = false`.

What was changed in agp 7.4.x from 7.3.1 that break this?

an...@google.com <an...@google.com> #10Aug 6, 2024 10:15PM

Are you referring to https://issuetracker.google.com/266109833#comment2? That issue is different from this issue.

(Regarding What was changed in agp 7.4.x from 7.3.1 that break this?: I don't know, my theory is that some of your code has changed too when updating AGP, which exposed the Jacoco bug. Please post your comments in that issue if you'd like to continue discussing this.)

an...@google.com <an...@google.com> #11Aug 9, 2024 12:55AM

Edit: we were actually not applying the patch correctly, so this was user error.

We've been running with a patched version of DexingTransformer.kt for about a week but are still seeing the issue. First I tried commenting out @CacheableTransform on DexingNoClasspathTransform, but after devs were still experiencing the error, I tried reverting that change and instead applying what I'd suggested in comment #5, but we're still running into the issue.

Is there any other workaround or additional information I can provide to help debug? At first I thought it's perhaps the patched version of DexingTransformer.kt wasn't being picked up, but I confirmed that it was by throwing an exception inside of doTransform.