Fixed
Status Update
No update yet.
Comments
vi...@google.com
Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.
di...@gmail.com
We have a build variant where `sharedUserId` is defined for both the build type and the flavor. The build type `tools:replace`s it, which works fine in builds and AS pre-4.0. Removing the declaration from the flavor fixes the issue, but I don't think that should be required.
di...@gmail.com
This repros in 4.0, but not 3.6. 139859267 has the same symptoms, but it seems to be closed as Fixed, and I'm seeing this in 4.0.
xa...@google.com
ju...@google.com
ju...@google.com
Hi there! Sorry for the delay.
I tried to reproduce your project setup and I did see the same issue in 3.6 Beta 3. I then updated to 3.6 Beta 4 and found I could no longer reproduce the issue. I was also unable to repro in 4.0 Canary 3.
I see that you reported this in 4.0 Canary 1. Could you update to the latest release and verify whether the issue has been resolved? If not, then maybe I just haven't duplicated your project setup correctly. Attached is the test project that I used.
I tried to reproduce your project setup and I did see the same issue in 3.6 Beta 3. I then updated to 3.6 Beta 4 and found I could no longer reproduce the issue. I was also unable to repro in 4.0 Canary 3.
I see that you reported this in 4.0 Canary 1. Could you update to the latest release and verify whether the issue has been resolved? If not, then maybe I just haven't duplicated your project setup correctly. Attached is the test project that I used.
ju...@google.com
Sorry, wrong project. *This* is the project I used to repro.
di...@gmail.com
I also have the issue on canary 2. Have not tried canary 3, will soon. Will also check out your project.
di...@gmail.com
Still repro'ing on canary 3 with my project.
di...@gmail.com
A slight modification to your project can repro the issue. Attached.
Changes:
• Added a manifest to the debug sourceset, tools:replace-ing sharedUserId
• Stopped tools:replace-ing sharedUserId in flav1 manifest
Changes:
• Added a manifest to the debug sourceset, tools:replace-ing sharedUserId
• Stopped tools:replace-ing sharedUserId in flav1 manifest
ju...@google.com
Ah, thanks so much for helping me reproduce your setup!
Currently, Studio looks for activities by computing the merged manifest based on the current state of your project. It's unable to find the activity because Studio's internal manifest merging fails (which you can verify by pulling up the flavor's manifest and switching to the Merged Manifest and seeing that there are errors). This is obviously wrong because Gradle merges the manifest just fine and uses the build type value for sharedUserId (verifying by analyzing the manifest in the resulting APK). This is the right thing to do because build type is higher priority than flavor (https://developer.android.com/studio/build/manifest-merge#merge_priorities ) and so we apply the debug manifest's tools:replace rule.
It seems that when we invoke Studio's internal manifest merger, we've accidentally given priority to the flavor manifest over the build type manifest, and so the merger sees a higher priority manifest with a different value for sharedUserId but no rule to tell the merger what to do, so it just spits out an error (which you can verify by adding tools:replace to the flavor manifest and noticing that the resulting merged manifest incorrectly has the flavor's value for sharedUserId).
Thank you for helping me find the regression. It shouldn't take long to isolate in the codebase, so hopefully we can have a fix up for this soon.
Currently, Studio looks for activities by computing the merged manifest based on the current state of your project. It's unable to find the activity because Studio's internal manifest merging fails (which you can verify by pulling up the flavor's manifest and switching to the Merged Manifest and seeing that there are errors). This is obviously wrong because Gradle merges the manifest just fine and uses the build type value for sharedUserId (verifying by analyzing the manifest in the resulting APK). This is the right thing to do because build type is higher priority than flavor (
It seems that when we invoke Studio's internal manifest merger, we've accidentally given priority to the flavor manifest over the build type manifest, and so the merger sees a higher priority manifest with a different value for sharedUserId but no rule to tell the merger what to do, so it just spits out an error (which you can verify by adding tools:replace to the flavor manifest and noticing that the resulting merged manifest incorrectly has the flavor's value for sharedUserId).
Thank you for helping me find the regression. It shouldn't take long to isolate in the codebase, so hopefully we can have a fix up for this soon.
di...@gmail.com
Appreciate the context!
yo...@gmail.com
This happened to me on 3.6 beta 4 as well.
yo...@gmail.com
When I did restart and invalidate, then problem went away.
ju...@google.com
Submitted the fix for the manifest priorities this morning, which means it should land in 4.0 canary 6. The test cases for the change use a stripped down version of the exact project you uploaded for repro, so I'm confident the issue will be resolved. Thank you for your patience!
> When I did restart and invalidate, then problem went away.
If this is the case, then it's likely that you're experiencing a different issue than the one OP pointed out (though with the same symptom of "Default activity not found").
Please follow up athttps://issuetracker.google.com/issues/139859267#comment19 and I'll take a look at your logs.
> When I did restart and invalidate, then problem went away.
If this is the case, then it's likely that you're experiencing a different issue than the one OP pointed out (though with the same symptom of "Default activity not found").
Please follow up at
di...@gmail.com
Wonderful, thanks! Will report back if anything's still broken in canary 6.
di...@gmail.com
Can confirm that it it's fixed in canary 5!
ju...@google.com
Thank you for verifying!
Description
`app`, `b`, and `c` all give an error: "no module specified".
`MyApp.app`, `MyApp.b`, and `MyApp.c` don't have that error. `MyApp.app` gives a different error: "Default Activity not found". `MyApp.b` and `MyApp.c` work with no problem.
If I try to manually select the activity in `MyApp.app`'s run configuration, the autocomplete sees my activities, but it still gives an error: "The activity 'SomeActivity' is not declared in AndroidManifest.xml".
I do have some sourceset-specific manifest stuff in `app`.
This issue does not happen when opening the same project with AS 3.5.1 or AS 3.6 beta 1.
Logs attached.
Build: AI-192.6817.14.36.5959023, 201910230206,
AI-192.6817.14.36.5959023, JRE 1.8.0_212-release-1586-b4-5784211x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.14.6, screens 1440x900; Retina
AS: 4.0 Canary 1; Kotlin plugin: 1.3.60-eap-76-Studio3.6-1; Android Gradle Plugin: 3.5.1; Gradle: 5.6.2; NDK: from local.properties: 21.0.5935234, latest from SDK: 21.0.5935234; LLDB: LLDB 3.1 (revision: 3.1.4508709); CMake: from local.properties: (not specified), latest from SDK: 3.10.2, from PATH: 3.15.3Source: user_sentiment_feedback