Status Update
Comments
lu...@google.com <lu...@google.com>
[Deleted User] <[Deleted User]> #2
je...@google.com <je...@google.com>
zo...@gmail.com <zo...@gmail.com> #3
This specific ProviderTestCase2 API will be deprecated and an alternative API will be provided in the next version.
sm...@google.com <sm...@google.com> #4
Thanks for the feedback
This issue shouldn't cause any problems with building or running tests. Few questions on #3, I think this may be a different issue. How are you sharing your generic test code between the source sets? Do your instrumentation tests build and run correctly or are the generic code symbols unavailable and marked in red?
zo...@gmail.com <zo...@gmail.com> #5
In app build.gradle
file:
android {
compileSdkVersion 32
defaultConfig {
...
sourceSets {
test {
java.srcDirs += "$projectDir/src/testCommon"
}
androidTest {
java.srcDirs += "$projectDir/src/testCommon"
}
}
}
}
testCommon
directory has code like CoroutineTestRule
, etc. which should be shared with test and android test folders.
My tests are running, but they are failing:
java.lang.AssertionError: Activity never becomes requested state "[STARTED, DESTROYED, CREATED, RESUMED]" (last lifecycle transition = "PRE_ON_CREATE")
at androidx.test.core.app.ActivityScenario.waitForActivityToBecomeAnyOf(ActivityScenario.java:338)
at androidx.test.core.app.ActivityScenario.launchInternal(ActivityScenario.java:272)
at androidx.test.core.app.ActivityScenario.launch(ActivityScenario.java:226)
at com.zao.movielist.FragmentBaseTest.setUp(FragmentBaseTest.kt:136)
Now this may be something unrelated, but when I try to dig into my code and start problem solving I get a bunch of files not being found/marked as red (the common classes), hence why I'm suspicious. Something else might have changed too I guess, but it seems like this could be related.
I'm going to try and duplicate all of my common code in each folder to see if anything changes, it's just a lot of updates... will update.
ga...@google.com <ga...@google.com> #6
WRT sharing the same folder between unit tests and device tests, please note that is not supported in the IDE. A single source directory can belong to only 1 IDE module, and this setup does not follow that rule. On the build side, everything should work normally, but you'll compile these sources twice.
zo...@gmail.com <zo...@gmail.com> #7
Oh - I didn't realize that.
What's the recommended approach for sharing something like CoroutineTestRule
with both directories? Literally having two versions of the same file? Making a small common library and adding to test and androidTest dependency? Or something else?
ga...@google.com <ga...@google.com> #8
At the moment, pulling that out into a separate library is the way to go. Once we start supporting test fixtures in Kotlin Android projects, you can add CoroutineTestRule
to it in the current subproject.
j....@gmail.com <j....@gmail.com> #9
My setup is simple to explain: A "common" module is used by both an "android_tv" and "mobile" modules for those respective target applications. I've even gone so far as to try removing the android_tv module entirely from project and disk, yet it only reduced the number of warning instances. I've confirmed each module is using their own package namespaces, and that codes file's package line at top match their containing directories. I'm truly at a loss on what's causing this in my setup and how to make it happy again.
mi...@mikehardy.net <mi...@mikehardy.net> #10
Everything working fine with bumblebee/7.0.x-7.1.x
We're open source and not too big a repo, if it's useful you can clone and open it and you should see the warning
sm...@google.com <sm...@google.com> #11
The warnings appear whenever you have a project that uses KAPT with multiple build types or product flavors. These warnings shouldn't cause any issues with the functionality of the IDE aside from possibly not marking some KAPT source folders as generated.
The warnings are caused by both the Android and Kapt gradle plugins providing these generated source folder paths. We should have a fix for this in the first Chipmunk patch. Apologies for the inconvinence.
sm...@google.com <sm...@google.com> #12
Sorry, the duplicate path issue in the project from #10 seems to be different to the KAPT one. Will investigate and update once we know more.
sm...@google.com <sm...@google.com> #13
It appears the issue in #10 is due to use of the following:
sourceSets {
debug {
manifest.srcFile 'src/test/AndroidManifest.xml'
}
}
This causes the content root src/test
to be added to the main
module. This is a problem because content roots need to be directories and intellij doesn't allow the same root to belong to multiple modules (as #6 mentioned). src/test
is also a source root of test
so this warning is generated.
The reason this was working before is that in pre-chipmunk we ran Android studio import with the intellij options set to create a single module per Gradle project. This option has been removed from IDEA for a good number of compile
and test
. By default Android modules effectively have three different scopes (which roughly correspond to Gradle source sets per variant) main
, unitTest
and androidTest
. The mapping of these to intellij modules with this option require us to merge the dependencies of unitTest
and androidTest
. Also any custom source sets` need to be merged as well. This caused a lot of incorrect symbol resolution within the editors along with a host of other issues.
In chipmunk we switch to creating a module per (roughly) Gradle source set. This allows us to map the information correctly but unfortunately does result in sharing information between source sets such as in #5 or the snippet above becoming unsupported by the IDE.
(Note this is not strictly related to the issue in #1 and #2 regarding kapt paths, these are an issue in import process and should be fixed in the first Chipmunk patch)
mi...@mikehardy.net <mi...@mikehardy.net> #14
ma...@gmail.com <ma...@gmail.com> #15
Similar issue
Duplicating content roots detected.
Path [D:/AndroidProjects/Footprint/app/build/generated/ksp/devDebug/java] of module [Footprint.app.main] was removed from modules [Footprint.app.main]
Path [D:/AndroidProjects/Footprint/app/build/generated/ksp/devDebugUnitTest/java] of module [Footprint.app.unitTest] was removed from modules [Footprint.app.unitTest]
Path [D:/AndroidProjects/Footprint/app/build/generated/ksp/devDebugAndroidTest/java] of module [Footprint.app.androidTest] was removed from modules [Footprint.app.androidTest]
fa...@gmail.com <fa...@gmail.com> #16
sourceSets {
androidTest.java.srcDirs += "src/sharedTest/java"
test.java.srcDirs += "src/sharedTest/java"
}
It show "duplicate content root detected".
sm...@google.com <sm...@google.com> #17
Source sets can no longer contain shared roots as this is impossible to represent in the IDE.
Edit: removed misleading recommendation regarding test fixtures.
sm...@google.com <sm...@google.com> #18
This warning should no longer show for kapt and other generated source folders. You may still see this warning if you currently share sources between different source sets. This setup is no longer supported and should be migrated by moving shared code into a separate project and add dependencies for the source sets you need.
Edit: remove misleading information on test fixtures
ro...@ebay.com <ro...@ebay.com> #19
4b...@gmail.com <4b...@gmail.com> #20
Another issue is that test fixtures do not support lotion currently.
cj...@gmail.com <cj...@gmail.com> #21
mu...@gmail.com <mu...@gmail.com> #22
sharing test code was working fine before Chipmunk and it was broken after that. The recommended solution is to use testFixtures
, but that doesn't support Kotlin yet. So basically we can't share test code now until testFixtures
starts supporting Kotlin - which might take months to years.
Please provide an option to keep this working as before Chipmunk version until testFixtures
starts supporting Kotlin. It is already a lot of hassle to write tests for Android and this is adding so much friction.
So much that people will stop writing tests altogether.
sm...@google.com <sm...@google.com> #23
Apologies for my comments before. The recommended solution to this issue is not using test fixtures (this is not what they are intended for).
The current recommendation is to use a separate com.android.library
Gradle project to store any shared code required across test
and androidTest
.
Note: You will not be able to access things marked internal
which would have been accessible before.
Please see more information in:
pa...@gmail.com <pa...@gmail.com> #24
The current recommendation is to use a separate com.android.library Gradle project to store any shared code required across test and androidTest.
Does this work with test classes having @Test annotations? It's a strange way to structure tests.
Anyone who doesn't want to go with this library approach here's an idea:
- add a task that copies to sharedTest folder to /sharedUnitTest and /sharedAndroidTest folders (which you add as 2 separate, distinct srcDirs)
- using the generate...Sources lifecycle tasks (if they still exist), you can hook this task to execute at the right time always, including uptodate checks and all.
fa...@gmail.com <fa...@gmail.com> #25
I'm not sure it's a great idea to prevent shared folders from working on Studio before providing a valid alternative that's fully supported (Text Fixtures). As somebody already mentioned, this is another point of friction for testing and code reusability, and that's the last thing developers need from an IDE.
sm...@google.com <sm...@google.com> #26
#24 - This should work with @Test annotation methods, you can create a shared class and add classes that extend it to the test
and androidTest
source sets. You may need to add a dummy test method to the unit test class in order for Gradle to run the tests, but both should run all tests within the shared class.
I don't think using tasks to copy a shared folder will work well in the IDE, you will have to make sure you don't make any changes to the copied files which will be the only ones imported. Dependencies and symbol resolution will likely not work at all or be incorrect for the shared folder.
#25 - You can depend on production code from the library containing the shared code. There is an example project that shows the setup in app:main
<-- shared:main
<-- app:test
/app:androidTest
.
Test fixtures should not be used just to share code they are not an alternative. Shared folders have never worked correctly, the state before (when test
and androidTest
were merged) had many issues which were hard to identify and resolve. If it was working before in some setups this was by chance.
mu...@gmail.com <mu...@gmail.com> #27
#26 - You mentioned multiple times that test fixtures should not be used just to share code. Can you elaborate on this? I read the Gradle documention (that was linked in AGP release notes) sharedTest
directory.
An added advantage I see by using test fixtures is, that I can publish this shared/base code with aar and the consuming project also can utilize it.
sm...@google.com <sm...@google.com> #28
The Gradle docs cover the use cases well. If this is how you use a sharedTest
directory then it does make sense to leverage them.
However there are other use cases, for example sharing actual @Test
methods or internal code that you don't want published which it doesn't make sense to use testFixtures
for.
It's possible you may have both types of code that are currently being shared between source sets, my aim with the recommendation was to give something that covers all of these cases. If it makes sense to move parts of all of the shared code into test fixtures then as a bonus you get the sharing by default, but this shouldn't be thought of as a direct replacement.
de...@google.com <de...@google.com> #29
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 Dolphin Beta 2 (2021.3.1.11)
- Android Gradle Plugin 7.3.0-beta02
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!
mi...@gmail.com <mi...@gmail.com> #30
wa...@gmail.com <wa...@gmail.com> #31
I'm upgrading my AGP to 7.3.0-rc01, but code highlighting & navigation are still not working. My env:
- AGP: 7.3.0-rc01 or 7.2.2
- Studio: Electric Eel | 2022.1.1 Canary 9
- Gradle 7.5.1
- Kotlin 1.7.10
- With KSP used but without KAPT
You can repro this issue in
https://github.com/LawnchairLauncher/lawnchair
yu...@gmail.com <yu...@gmail.com> #32
ch...@gmail.com <ch...@gmail.com> #33
gd...@blissapplications.com <gd...@blissapplications.com> #34
AGP 7.3.0
Gradle 7.5.1
Kotlin 1.7.10
Has this problem.
os...@gmail.com <os...@gmail.com> #35
a3...@gmail.com <a3...@gmail.com> #36
ca...@gmail.com <ca...@gmail.com> #37
da...@sucharda.cz <da...@sucharda.cz> #38
Android Studio Electric Eel | 2022.1.1 Beta 1 (Build #AI-221.6008.13.2211.9039819, built on September 8, 2022)
AGP 7.3.0
Gradle 7.4.2
Kotlin 1.7.10
Has the same problem for me.
lu...@gmail.com <lu...@gmail.com> #39
I have the same problem.
Even step 14 of your codelab also gives the same error:
Basically the error is that the IDE flags with an error because it doesn't recognize the sharedTest path, however it's not an error that prevents the tests from running, but we don't have the ability to search from androidTest to the sharedTest folder.I attach the image
This is my IDE:
Android Studio Dolphin | 2021.3.1 Patch 1
Build #AI-213.7172.25.2113.9123335, built on September 29, 2022
Runtime version: 11.0.13+0-b1751.21-8125866 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11 10.0
jo...@olx.com <jo...@olx.com> #40
This issue still happens on Android Studio Giraffe | 2022.3.1 Canary 4
with AGP 7.4.1
and the Apollo GraphQL Gradle plugin.
mi...@gmail.com <mi...@gmail.com> #41
iv...@gmail.com <iv...@gmail.com> #42
wa...@gmail.com <wa...@gmail.com> #43
Android Studio Giraffe | 2022.3.1 Patch 4
Build #AI-223.8836.35.2231.11090377, built on November 14, 2023
Runtime version: 17.0.6+0-17.0.6b829.9-10027231 x86_64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.1.1
GC: G1 Young Generation, G1 Old Generation
Memory: 2048M
Cores: 16
Metal Rendering is ON
Registry:
external.system.auto.import.disabled=true
debugger.new.tool.window.layout=true
ide.text.editor.with.preview.show.floating.toolbar=false
ide.experimental.ui=true
Non-Bundled Plugins:
com.jetbrains.kmm (0.8.1(223)-26)
com.developerphil.adbidea (1.6.12)
ni...@gmail.com <ni...@gmail.com> #44
ga...@google.com <ga...@google.com> #45
Please see comments #18 and below for info on which problem was addressed in this bug.
To help us get to the bottom of issues you are hitting, can you please file new bugs (instructions:
pa...@outlook.com <pa...@outlook.com> #46
It is absurd to expect that we move every single resource into a shared separate project whenever we need to have access to those same resources in test folders. The proposed solution is a lazy cop out of a problem you guys decided to force without properly addressing the impact that will have for everyone that is affected by this.
Description
As written in the title, after updating Android Gradle plugin to version 7.2.0, the IDE starts to complain about duplicated content roots. Reverting back to 7.1.3 fixes it.