Status Update
Comments
mo...@gmail.com <mo...@gmail.com> #2
This one is beginning to be severe, after updating Kotlin to 1.6.0-RC2 the incidents have become more frequent (I hope they aren't related).
The only remedy is still to restart AS.
Still in Chipmunk 2021.2.1.3
mo...@gmail.com <mo...@gmail.com> #3
Hi Roar, thank you for the report. I see a few other similar looking bug reports so I'll prioritize this.
Please let me know if you notice a pattern in which the incidents happen.
mo...@gmail.com <mo...@gmail.com> #4
Roar, I tried playing with a small data binding project and I couldn't reproduce the issue. Do you know what triggers it? Like after a refactoring or some other action? A sample project would be very helpful to us too.
rm...@google.com <rm...@google.com> #5
office and one HP i5/16GB at home office, sme kotlin based project.
Happens mostly when changing binding related code like adding data members
in xml layouts, but also just out og the blue when opening code with
fragments and data bindings.
I'll send you an collection of my logs tomorrow.
I have experienced similar issues (approx 2-3 years ago, then I asked for a
"regenerate bindings"-button, but it was "pinned down" then (no hard
feelings for that then :) ).
BTW I have seen this issue sporadicly, but then I could click
Build->Generate sources gradle tasks to fix it, but now it will not fix it.
tor. 4. nov. 2021, 21:47 skrev <buganizer-system@google.com>:
st...@gmail.com <st...@gmail.com> #6
For the time being, you can get the binding back by going Build > Clean Project
instead of restarting Studio.
mo...@gmail.com <mo...@gmail.com> #7
mo...@gmail.com <mo...@gmail.com> #8
Good tip, I'll try that next time.
I am providing my zipped logged directory, so you have something to work on.
Pls send me an pm/email if you need access to the project.
RG
rp...@google.com <rp...@google.com>
ju...@google.com <ju...@google.com>
mo...@gmail.com <mo...@gmail.com> #9
well, it just happened again here. I'm now on
Android Studio Chipmunk | 2021.2.1 Canary 4 Build #AI-212.5284.40.2112.7863073, built on October 28, 2021 Runtime version: 11.0.12+7-b1504.28-7817840 amd64 VM: OpenJDK 64-Bit Server VM by Oracle Corporation Windows 10 10.0 GC: G1 Young Generation, G1 Old Generation Memory: 1280M Cores: 8 Registry: external.system.auto.import.disabled=true
With gradle set to using my system default JDK: openjdk version "17" 2021-09-14 OpenJDK Runtime Environment (build 17+35-2724) OpenJDK 64-Bit Server VM (build 17+35-2724, mixed mode, sharing)
and my project set to compileOptions { sourceCompatibility JavaVersion.VERSION_11 targetCompatibility JavaVersion.VERSION_11 coreLibraryDesugaringEnabled true }
Everything was fine until I started editing my styles; individual style.xml files and some attributes set in layouts. Don't think it matters, but I was editing 'textColor' attributes specifically; NOT adding or removing any elements. Running the app in the emulator in debug mode (but not actively using the debugger). Out of the blue, a java file I had open lost its view binding. Every other such file I open subsequently lost its vb. Looking in the 'generated' folder, all vb files are present and correct.
Dunno if it's relevant, but here is the idea.log from the timeframe:
2021-11-11 12:03:29,495 [5901837] INFO - .idea.res.ResourceUpdateTracer - Unresolved resource reference "@attr/colorOnBackgroun" in fastscroller\src\main\res\drawable\fastscroll_overlay_classic.xml
--- Resource update trace: ---
2021-11-11 12:03:29.495
2021-11-11 12:03:29,495 [5901837] INFO - .idea.res.ResourceUpdateTracer - Unresolved resource reference "@attr/colorOnBackgroun" in fastscroller\src\main\res\drawable\fastscroll_overlay_classic.xml
--- Resource update trace: ---
2021-11-11 12:03:29.495
2021-11-11 12:03:29,994 [5902336] ERROR - GradleBuildOutputUtil.kt - Exception 'java.lang.Throwable: Output listing build file is not available for output type Apk in IdeBuildTasksAndOutputInformationImpl(assembleTaskName=assembleDebug, assembleTaskOutputListingFile=null, bundleTaskName=null, bundleTaskOutputListingFile=null, apkFromBundleTaskName=null, apkFromBundleTaskOutputListingFile=null)' was reported 40 times 2021-11-11 12:03:36,955 [5909297] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 12:04:00,136 [5932478] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 12:04:00,464 [5932806] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 12:04:24,029 [5956371] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 12:04:46,179 [5978521] INFO - gs.CompletionMLRankingSettings - ML Completion enabled, experiment group=13 for: C/C++ 2021-11-11 12:04:46,179 [5978521] INFO - gs.CompletionMLRankingSettings - ML Completion enabled, experiment group=11 for: Kotlin 2021-11-11 12:04:46,240 [5978582] INFO - rationStore.ComponentStoreImpl - Saving Project(name=NeverTooManyBooks, containerState=COMPONENT_CREATED, componentStore=C:\Data\Code\NeverTooManyBooks)VcsDirectoryMappings took 18 ms 2021-11-11 12:04:55,595 [5987937] INFO - rationStore.ComponentStoreImpl - Saving Project(name=NeverTooManyBooks, containerState=COMPONENT_CREATED, componentStore=C:\Data\Code\NeverTooManyBooks)RenderSettings took 13 ms 2021-11-11 14:45:48,438 [15640780] INFO - rationStore.ComponentStoreImpl - Saving Project(name=NeverTooManyBooks, containerState=COMPONENT_CREATED, componentStore=C:\Data\Code\NeverTooManyBooks)GradleMigrationSettings took 29 ms 2021-11-11 14:45:58,299 [15650641] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 14:46:03,672 [15656014] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 14:46:38,793 [15691135] INFO - System.impl.PopupMenuPreloader - Popup menu 'Project View Popup Menu' preloaded at 'ProjectViewPopup' in 9 ms 2021-11-11 14:46:38,794 [15691136] INFO - System.impl.PopupMenuPreloader - Popup menu 'Project View Popup Menu' preloaded at 'ProjectViewPopup' in 9 ms 2021-11-11 14:46:47,988 [15700330] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 14:46:58,912 [15711254] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 14:48:08,870 [15781212] INFO - rationStore.ComponentStoreImpl - Saving appwhatsNew took 15 ms 2021-11-11 14:49:33,474 [15865816] WARN - itors.literals.LiteralsManager - Only Kotlin is supported for LiveLiterals 2021-11-11 14:52:51,578 [16063920] INFO - gs.CompletionMLRankingSettings - ML Completion enabled, experiment group=13 for: C/C++ 2021-11-11 14:52:51,578 [16063920] INFO - gs.CompletionMLRankingSettings - ML Completion enabled, experiment group=11 for: Kotlin 2021-11-11 14:56:07,503 [16259845] INFO - j.ide.actions.RevealFileAction - Exit code 1
again, not sure if it's relevant/related, but the "@attr/colorOnBackgroun" mentioned above is in fact ""?attr/colorOnBackground" (with a '?' and a 'd' at the end) in my code.
ju...@google.com <ju...@google.com> #10
Reporting my last "crashes" with bindings.
mo...@gmail.com <mo...@gmail.com> #11
ok... I'm now having to quit/restart studio after every layout edit
I basically have a bunch of layouts with the outer tag a ConstraintLayout. I'm copy/pasting a new root tag CoordinatorLayout in all of them. So for each file, I paste the new CoordinatorLayout top section, remove the namespace declaration from the ConstraintLayout and finally close the CoordinatorLayout tag at the bottom of the file. Now open the java file... yup... bindings are lost; restart Studio.
Edit: each layout is present twice: portrait + "land"
mo...@gmail.com <mo...@gmail.com> #12
Please se #6 above for short remedy.
ju...@google.com <ju...@google.com> #13
sure I saw #6; but for me restarting Studio is faster then a 'clean' and subsequent full-build.
I can't tell for sure (yet) but it seems to happen most/only when editing layouts which exist in both portrait + "land"
mo...@gmail.com <mo...@gmail.com> #14
Thanks for the updates guys and keep them coming.
FYI our team is stretched thin and with the holidays on the horizon, I don't think we can get to this until a few weeks from now. I do want to get this fixed for Android Studio Chipmunk. Thanks for your patience.
ju...@google.com <ju...@google.com> #15
I'm trying to get this 100% reproducible. Let me know if there are any extra debug flags that you want me to set.
ju...@google.com <ju...@google.com> #16
I now feel strongly for a "recalculate bindings button" or menu point.
mo...@gmail.com <mo...@gmail.com> #17
BTW, Clean Project mentioned in #6 doesn't always remedy.
I want to refer other issues where I have had similar problems:
Attaching logs.
Description
Android Studio 3.6 will often use the incorrect launch activity when starting a debug session when the source defines a debug variant AndroidManifest.xml file that simply uses tools:remove to remove the original MainActivity and replace it with another launch activity defined in the debug variant source.
The result is that when running the debug variant, Android Studio will produce the incorrect "adb shell am start" command:
adb shell am start -n "com.example.asbug/com.example.asbug.MainActivity" ...
which should really be
adb shell am start -n "com.example.asbug/com.example.asbug.DebugMainActivity" ...
The result is that the APK is installed correctly but the activity manager is unable to find the wrongly chosen "MainActivity" class to start the app (since that activity was correctly removed during the manifest merge).
The problem with this bug is that it doesn't happen all the time. I'll be able to run the debug variant with no problems for a day or two and then all of a sudden, launching in debug mode (using the debug variant) will complain that the launch activity "MainActivity" does not exist. Sometimes clearing my project folder of all temporary files and reloading from the Gradle file will fix the issue and sometimes that doesn't work.
I created a dummy test project for you based on an empty activity and added a debug variant manifest along with a DebugMainActivity class and it failed to use the correct replaced "DebugMainActivity" in the "adb shell am start ..." command. But once I tried to load the project in AndroidStudio 3.4.1 to see if it also had the problem (it worked fine) and then went back to try it again in 3.6, I couldn't duplicate the bug in my test project. So I won't be sending you that project since you can make one in under 2 minutes yourself if you need to.