Fixed
Status Update
No update yet.
Comments
uc...@google.com
Current focus of Crostini/Linux VM is to support developer's environment, so lowering the priority.
je...@google.com
Lowering the priority because a feature is not for "development" limits the usefulness of Crostini. There are several Midi-compatible Linux applications that cannot be used on Chromebook/Crostini because of this limitation. If Crostini aims to be a fully true Linux implementation on the Chromebook hardware, we need to get past the "developer" bias. I would like to use Reaper DAW or LMMS DAW with my Midi devices, using my beloved Chromebook, but I cannot because of this lack of functionality. How can this be moved up in priority?
to...@gmail.com
Apologies for my uninformed question, but what does "Labels: sw-b-migration-candidate" in the previous comment mean? In my research, it seems to mean that it has been referred to the Google Issue Tracker, but is that a sign this might be considered for development?
to...@gmail.com
Please sort this out, it would be such an awesome and necessary feature
hu...@google.com
It would be nice if a USB MIDI device could be offered the ability to "pass through" the same way that some serial USB devices are granted the option.
hu...@google.com
As someone who works in the light and music industry, it would be great to be able to use MIDI controllers with the Linux apps that Crostini supports. Google has gone 95% of the way of opening up the Chromebook for more advance tasks - now please go the last mile and allow us to use USB peripherals such as MIDI devices so we can be more creative with our Chromebooks. 🙏
to...@gmail.com
is this where we voice support for this feature? I love Crostini! I'm a software dev, but I also produce space farts, would love to have some usb midi love in Crostini ♥.
hu...@google.com
Given the ongoing comments where people ask for MIDI support in Cronstini, wouldn't it be adequate to raise the priority for this feature?
to...@gmail.com
Yes please!!! I'm a dj and would like to use my hardware deck (a usb midi device) with my chromebook .
to...@gmail.com
Seriously yes please add this feature. It is 2024 and 3 years since the initial request. Can AI coding help to speed up this development?
hu...@google.com
My Current focus of Crostini/Linux VM is to run production sodtware available on Linux so that I can create music. Please figure out how to do this.
hu...@google.com
This is a necessary feature for most ppl in music related cases, given Chromebook already got all the capacity to run Linux softwares, lacking this feature and focus on "development" for what? Pop could run docker already
to...@gmail.com
Project: chromiumos/third_party/kernel
Branch: chromeos-6.6
Author: Emilie Roberts <
Link:
CHROMIUM: termina: enable USB audio/MIDI devices
Expand for full commit details
CHROMIUM: termina: enable USB audio/MIDI devices
Allow for USB audio and MIDI devices to be used. USB MIDI and
audio devices are able to be passed through to Linux in the
standard ChromeOS settings, but kernel support was not enabled.
This change enables the kernel flags needed for USB audio and
MIDI sequencer support.
BUG=b:260275869
TEST=Install qjackctl: `sudo apt install qjackctl`
Start qjackctl: `qjackctl`
Press Start
Open Graph, notice there are no MIDI devices
Plug in USB MIDI device (like AKAI MPK mini Mk II)
In ChromeOS settings, share the USB device with Linux
Wait 5 seconds
Notice that the USB MIDI device now appears in qjackctl graph
Change-Id: I4352a95e1ac7dbb60e9265c6e8e5550f57074a32
Signed-off-by: Emilie Roberts <hadrosaur@google.com>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6169942
Reviewed-by: maciek swiech <drmasquatch@google.com>
Reviewed-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-by: Junichi Uekawa <uekawa@chromium.org>
Files:
- M
chromeos/config/termina/base.config
Hash: 57406f61d18c1c4fd302b7f258dbf947062f55c9
Date: Wed Jan 15 13:32:00 2025
hu...@google.com
Does this mean that this enhancement will make it to the stable branch? When?
hu...@google.com
Thanks. Looking forwards to use this important feature.
to...@gmail.com
The kernel of my Chromebook is 5.15 (Intel processor). The Chromebook is an "Acer Chromebook CB 315-3H series Model NO. N1903" manufactured on 2021/05/19. I bought this Chromebook in 2022 for using the MIDI interface where as a result this request was made.
Can I update the kernel to 6.6? (I have not found any simple way online how to do that)
Or, will the solution be available for a kernel 5.15, too?
Or if NOT, what does mean? Buy new Chromebook???
Can I update the kernel to 6.6? (I have not found any simple way online how to do that)
Or, will the solution be available for a kernel 5.15, too?
Or if NOT, what does mean? Buy new Chromebook???
hu...@google.com
Confirming your findings: the Acer 315-3H is an octopus board (FYI consumer names to device names octopus was already on 6.6 when I posted #16.
Kernel updates for the host are tied to the OS and there is not a way to update it independently of the system. Kernel uprevs are non-trivial and have a large impact on the overall system. This is an older device and octopus boards tend to have lower specs (celerons, 4gb RAM), so we need to be particularly careful with performance, battery life, etc. when uprevv'ing. (If you're interested in hacking, you could try to
I'm not sure when and if we will uprev octopus to 6.x. Likely we will at some point, but I don't know when. We uprevved to 5.15 about a year ago so I would not expect this sooner than a year or so from now. Apologies that I don't have a clearer schedule.
In the meantime, MIDI devices should still work on your Chromebook in the Web and under Android (ie. not under linux). If there are apps on those platforms that serve your needs that might be an option until a kernel upgrade happens. I know it's not the same as having a full JACK patchbay, but I hope it might solve some of your use cases.
to...@gmail.com
Thank you for your immediate response and your deep insight, and thank you for your technical expertise and openness.
However, your answer is really frustrating. We are a company and wanted to launch our multimedia software through Linux to the emerging Chromebook market. Customers continuously ask for such a support.
Because of this customer requests to have our multimedia software running on a Chromebook we bought this ASUS Chromebook for certification only. We also decided for this ASUS Chromebook because according to our research back then this Chromebook will be supported until ~2030. At end of 2021 we had fully certified our software and then ran into the issue where external MIDI devices are not supported on Chromebook/Linux.
I opened a first issue which was closed by Google Development with the argument "Won'tFix(Closed)" because such a support is not in the interests of Google Development.
As a consequence, I wrote all my frustration on Nov 25, 2021 01:59AM into this new issue. As you can see from this long discussion here for more than 4 years, there is a real need for this feature. Thanks for taking action finally.
Of course, someone inside our company will be able to get a chromium OS image built together somehow. From an economical effort perspective it is not worth to do.
But none of our customers is willing nor able to perform a chromium image, nor we can recommend it as you don't recommend it. From our business view the problem is not that just our ASUS Chromebook has an issue but many other Chromebook on the market.
This is now the outcome after 4 years where this report was made. Hope you understand my frustration.
For now we can only pass this information to customers who ask for a Chromebook support and tell them that they need to check their Chromebook version.
Given the current market prices Chromebook vs cheap Windows 11 laptop, both are at the same price. If customers ask what we recommend we need to vote for a Windows 11 laptop and refer to this issue.
However, your answer is really frustrating. We are a company and wanted to launch our multimedia software through Linux to the emerging Chromebook market. Customers continuously ask for such a support.
Because of this customer requests to have our multimedia software running on a Chromebook we bought this ASUS Chromebook for certification only. We also decided for this ASUS Chromebook because according to our research back then this Chromebook will be supported until ~2030. At end of 2021 we had fully certified our software and then ran into the issue where external MIDI devices are not supported on Chromebook/Linux.
I opened a first issue which was closed by Google Development with the argument "Won'tFix(Closed)" because such a support is not in the interests of Google Development.
As a consequence, I wrote all my frustration on Nov 25, 2021 01:59AM into this new issue. As you can see from this long discussion here for more than 4 years, there is a real need for this feature. Thanks for taking action finally.
Of course, someone inside our company will be able to get a chromium OS image built together somehow. From an economical effort perspective it is not worth to do.
But none of our customers is willing nor able to perform a chromium image, nor we can recommend it as you don't recommend it. From our business view the problem is not that just our ASUS Chromebook has an issue but many other Chromebook on the market.
This is now the outcome after 4 years where this report was made. Hope you understand my frustration.
For now we can only pass this information to customers who ask for a Chromebook support and tell them that they need to check their Chromebook version.
Given the current market prices Chromebook vs cheap Windows 11 laptop, both are at the same price. If customers ask what we recommend we need to vote for a Windows 11 laptop and refer to this issue.
hu...@google.com
I love linux and it's potential for music creation and production. Unfortunately using Linux on ChromeOS for music is not an ideal path, especially for developers targeting consumers. We conceived it with software development in mind, and although it is capable of doing more, that remains the primary focus. We can't commit to a timeline for a kernel uprev to support this feature in octopus. Personally, I wish we could support you better as a linux music software creator, and I hope your work continues there for the linux community, but on these devices linux won't support midi until a kernel uprev. I can understand the frustration.
I agree that building and customising ChromiumOS would be a potential path for an interested hobbiest, but not for end users.
For the record, I just tested MIDI on Android and Web with an AKAI MPK mini keyboard on octopus and it works with no extra configuration. I'm not sure if it's in scope for your development team, but if Android is a potential distribution platform, it might be worth exploring and MIDI will work on these devices. Some linux toolkits like QT have an Android build target and so may require only minimal porting. You'd also be able to distribute on the many Android tablets, foldables, and phones.
to...@gmail.com
when will this be released to Google pixel go? looking forward to use it as a mobile music studio
to enable it do I need to delete and reinstall crostini vm? and qjack install is needed? any steps on how to enable it?
thanks in advance
to enable it do I need to delete and reinstall crostini vm? and qjack install is needed? any steps on how to enable it?
thanks in advance
to...@gmail.com
Project: chromiumos/third_party/kernel
Branch: chromeos-6.12
Author: Emilie Roberts <
Link:
CHROMIUM: termina: enable USB audio/MIDI devices
Expand for full commit details
CHROMIUM: termina: enable USB audio/MIDI devices
Allow for USB audio and MIDI devices to be used. USB MIDI and
audio devices are able to be passed through to Linux in the
standard ChromeOS settings, but kernel support was not enabled.
This change enables the kernel flags needed for USB audio and
MIDI sequencer support.
BUG=b:260275869
TEST=Install qjackctl: `sudo apt install qjackctl`
Start qjackctl: `qjackctl`
Press Start
Open Graph, notice there are no MIDI devices
Plug in USB MIDI device (like AKAI MPK mini Mk II)
In ChromeOS settings, share the USB device with Linux
Wait 5 seconds
Notice that the USB MIDI device now appears in qjackctl graph
Change-Id: I4352a95e1ac7dbb60e9265c6e8e5550f57074a32
Signed-off-by: Emilie Roberts <hadrosaur@google.com>
Signed-off-by: Daniel Verkamp <dverkamp@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/6317135
Reviewed-by: Dmitry Torokhov <dtor@chromium.org>
Files:
- M
chromeos/config/termina/base.config
Hash: f8446259e023526816499c6783764e1a14800f01
Date: Wed Jan 15 13:32:00 2025
hu...@google.com
REALLY excited to see movement here- that midi device support in linux crostini was added to kernal 6.6 (better late than never)! but unfortunate, my chromebook won't have midi support in linux for potentially a long time from now (still on 5.15 via this G7). understandable that there are so many considerations when updating these devices' kernals (midi being shadowed by much more major considerations). but im hopeful since the initial 4.14 of my chromebook was able to be updated to 5.15, that a leap to 6.6 will be able to happen.
if anyone has any links or information on when this kernal upgrade from 5.15 to 6.6 might be able to happen , please let us know here! thank you in advance.
if anyone has any links or information on when this kernal upgrade from 5.15 to 6.6 might be able to happen , please let us know here! thank you in advance.
to...@gmail.com
It's incremental data binding annotation processor already implemented in the latest 3.4 beta release of build plugin, please?
I'm expecting that in 3.3 not.
Thanks.
I'm expecting that in 3.3 not.
Thanks.
hu...@google.com
It is being scheduled for 3.5. I am expecting to release this feature to 3.5 canaries soon (within a week or two).
to...@gmail.com
Thanks a lot!
hu...@google.com
I am pleased to inform that data binding has become incremental, starting with AGP 3.5.0-alpha05. For safety we've put this feature behind a flag, currently off by default. To enable it, please set
android.databinding.incremental=true
in the Gradle properties file.
Relevant commit:https://android.googlesource.com/platform/tools/base/+/85292f7e7b41e741fe5354d31a30c97ec79d18a6
Please try out the feature and let us know how it goes. If we receive enough good feedback, we will enable it by default. I'm leaving this bug open to keep track of that.
android.databinding.incremental=true
in the Gradle properties file.
Relevant commit:
Please try out the feature and let us know how it goes. If we receive enough good feedback, we will enable it by default. I'm leaving this bug open to keep track of that.
to...@gmail.com
Thanks a lot! Currently, I'm testing 3.4.0 version. I will try 3.5.0 ASAP.
an...@gmail.com
In response to #29, any feedback yet from you or anyone else with this flag? If it works out, this could be a huge productivity gain. Will try for myself ASAP.
to...@gmail.com
I just tested it on a relatively small project and it looks good, here is incremental build, with one line changed
https://scans.gradle.com/s/bt2obrtrrrj2y/timeline?task=arbuq4molzx42
And here a clean compilation
https://scans.gradle.com/s/4talkldkc2qro/timeline?task=arbuq4molzx42
According to logs, it looks that incremental compilation was used. I'm using data binding, Glide, and Butterknife
But I need to test it on a bigger project, where compilation takes 30s
And here a clean compilation
According to logs, it looks that incremental compilation was used. I'm using data binding, Glide, and Butterknife
But I need to test it on a bigger project, where compilation takes 30s
pj...@gmail.com
I did a test on a big project and the incremental compiling didn't work.
https://scans.gradle.com/s/b3qs53n4silqa/timeline?task=cnfo4lpnihue4
I updated all annotation processors to versions which support incremental compiling and used 3.5.0-alpha05
I changed just two lines of code in java
I updated all annotation processors to versions which support incremental compiling and used 3.5.0-alpha05
I changed just two lines of code in java
to...@gmail.com
I also tested it on a large and very complex project already.
Here is build without any changes in the code, it takes just 8s
https://gradle.com/s/2xhpe7aamx7uw
And here I just commented out one line of code in the fragment, no method signature change
https://gradle.com/s/e7iuvbqttdxn2
It takes 40s, just compiling java code is 12shttps://scans.gradle.com/s/e7iuvbqttdxn2/timeline?task=a2moppdi3f2qu
In log is
Compiling with JDK Java compiler API.
Incremental compilation of 688 classes completed in 10.061 secs.
There is no information, that something prevents to incremental compilation
So hard to say if "compilation of 688 classes" means that it really compile all of them, because just one file was changed or it means the total class count.
When I delete build folder and turn off build cache, the build takes 1m 10s, and just the compilation takes 11.2s
https://scans.gradle.com/s/3qas6nl3ze3c6/timeline?task=a2moppdi3f2qu
So from this looks that 11s is time for full compilation, not an incremental one.
Btw. Do the build with deleted build folder and without build cache with the build plugin 3.3.1 takes 1m 31s.
So it looks that 3.5 brings 23% increase of speed build, but I did not enough measures to prove it. It is just from one build.
https://gradle.com/s/tdgnlpokgs5zi
All tests are from the command line, I did not run the build directly from IDE.
Here is build without any changes in the code, it takes just 8s
And here I just commented out one line of code in the fragment, no method signature change
It takes 40s, just compiling java code is 12s
In log is
Compiling with JDK Java compiler API.
Incremental compilation of 688 classes completed in 10.061 secs.
There is no information, that something prevents to incremental compilation
So hard to say if "compilation of 688 classes" means that it really compile all of them, because just one file was changed or it means the total class count.
When I delete build folder and turn off build cache, the build takes 1m 10s, and just the compilation takes 11.2s
So from this looks that 11s is time for full compilation, not an incremental one.
Btw. Do the build with deleted build folder and without build cache with the build plugin 3.3.1 takes 1m 31s.
So it looks that 3.5 brings 23% increase of speed build, but I did not enough measures to prove it. It is just from one build.
All tests are from the command line, I did not run the build directly from IDE.
pj...@gmail.com
I forgot to add that I'm using
apply plugin: "kotlin-android"
as some code is written in kotlin however I'm using java annotation processor - not kapt
apply plugin: "kotlin-android"
as some code is written in kotlin however I'm using java annotation processor - not kapt
to...@gmail.com
I have also Kotlin code in the project, but I'm using just java annotation process also.
hu...@google.com
@32, 34: Can you run with --info to see whether Java compile in your project is incremental and how many classes are recompiled?
@33, 35: "Incremental compilation of 688 classes completed in 10.061 secs." => This means that Java compile is incremental in your project. 688 of all the classes are actually recompiled. The number of recompiled classes depends on the nature of the change. You can try changing a class that is not used by any other class, and observe that the number of recompiled classes will be much lower.
If the number of recompiled classes is always high for you, can you run with --debug and attach the log here? It will show exactly what classes are recompiled, and we can debug from there. Note that it's enough to just run the Java compile task, and make sure you remove any confidential info if any from the log first.
@33, 35: "Incremental compilation of 688 classes completed in 10.061 secs." => This means that Java compile is incremental in your project. 688 of all the classes are actually recompiled. The number of recompiled classes depends on the nature of the change. You can try changing a class that is not used by any other class, and observe that the number of recompiled classes will be much lower.
If the number of recompiled classes is always high for you, can you run with --debug and attach the log here? It will show exactly what classes are recompiled, and we can debug from there. Note that it's enough to just run the Java compile task, and make sure you remove any confidential info if any from the log first.
to...@gmail.com
I changed one line in Activity class it is definitely not used in any other class. I will try it with debug and send log here later today.
pj...@gmail.com
From the huge log I extracted this
" Full recompilation is required because com.google.auto.value.processor.AutoValueProcessor is not incremental. Analysis took 5.306 secs. "
the dex task detected the single file change
"AnalyticsManager.dex:CHANGED"
I'm using AutoValue 1.6.3 and according to release notes it should be incremental
https://github.com/google/auto/releases/tag/auto-value-1.6.3
Gradle doesn't report it as "non-incremental" as it used to be with older version.
" Full recompilation is required because com.google.auto.value.processor.AutoValueProcessor is not incremental. Analysis took 5.306 secs. "
the dex task detected the single file change
"AnalyticsManager.dex:CHANGED"
I'm using AutoValue 1.6.3 and according to release notes it should be incremental
Gradle doesn't report it as "non-incremental" as it used to be with older version.
to...@gmail.com
I found just this
01:38:54.680 [INFO] [org.gradle.api.internal.tasks.compile.incremental.SelectiveCompiler] Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.251 secs.
I just added line
i.putExtra(ACTION, action);
to method creating Intent like this
Intent i = new Intent(activity, DashboardActivity.class);
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
activity.startActivity(i);
inside of DashboardActivity.java
01:38:54.680 [INFO] [org.gradle.api.internal.tasks.compile.incremental.SelectiveCompiler] Full recompilation is required because 'DashboardActivity.java' was changed. Analysis took 0.251 secs.
I just added line
i.putExtra(ACTION, action);
to method creating Intent like this
Intent i = new Intent(activity, DashboardActivity.class);
i.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
activity.startActivity(i);
inside of DashboardActivity.java
hu...@google.com
@38: AutoValue will not be incremental if one of its extensions is not incremental. Please follow the progress for AutoValue extensions here: https://github.com/google/auto/issues/673
@39: This appears to be a Gradle bug. Could you prepare a small project and file a bug with Gradle? You can also attach the project here, and I will try to see what's wrong.
@39: This appears to be a Gradle bug. Could you prepare a small project and file a bug with Gradle? You can also attach the project here, and I will try to see what's wrong.
pj...@gmail.com
I found that auto-value-parcel is not incremental. Author still didn't release the new version but with help of jitpack I managed to make all my dependencies support incremental compiling.
However when I change a single file the whole module is being recompiled
Task ':app:compileGrubhubStagingJavaWithJavac' is not up-to-date because:
Input property 'sources' file /Users/rudy/dev/projects/dinerapp-android/app/src/main/java/com/grubhub/dinerapp/android/order/search/searchResults/data/SearchResponseTransformer.java has changed.
Compiling with source level 1.8 and target level 1.8.
file or directory '/Users/rudy/dev/projects/dinerapp-android/app/libs', not found
Created classpath snapshot for incremental compilation in 0.005 secs.
Class dependency analysis for incremental compilation took 0.165 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 2923 classes completed in 28.813 secs.
Packing task ':app:compileGrubhubStagingJavaWithJavac'
Is there something I'm missing ?
However when I change a single file the whole module is being recompiled
Task ':app:compileGrubhubStagingJavaWithJavac' is not up-to-date because:
Input property 'sources' file /Users/rudy/dev/projects/dinerapp-android/app/src/main/java/com/grubhub/dinerapp/android/order/search/searchResults/data/SearchResponseTransformer.java has changed.
Compiling with source level 1.8 and target level 1.8.
file or directory '/Users/rudy/dev/projects/dinerapp-android/app/libs', not found
Created classpath snapshot for incremental compilation in 0.005 secs.
Class dependency analysis for incremental compilation took 0.165 secs.
Compiling with JDK Java compiler API.
Incremental compilation of 2923 classes completed in 28.813 secs.
Packing task ':app:compileGrubhubStagingJavaWithJavac'
Is there something I'm missing ?
hu...@google.com
"Incremental compilation of 2923 classes completed in 28.813 secs." => This indicates that the Java compile task in your project was already incremental; otherwise you would have seen a message like "Full recompilation is required because <something happened>".
When Java compile is incremental and you still see a lot of classes are recompiled, it usually means that the specific change that you make to the source file affects a lot of classes (especially if you make a change relating to constants). Seehttps://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_compile for more background.
If you change a different source file with a different type of change (e.g., adding a comment or modifying a method's body), you'll probably notice that the set of recompiled classes will be much smaller.
When Java compile is incremental and you still see a lot of classes are recompiled, it usually means that the specific change that you make to the source file affects a lot of classes (especially if you make a change relating to constants). See
If you change a different source file with a different type of change (e.g., adding a comment or modifying a method's body), you'll probably notice that the set of recompiled classes will be much smaller.
hu...@google.com
Starting with AGP 3.6.0-alpha02, we are enabling incremental data binding by default. Please let us know if you see more improvements in your build.
Change:https://android.googlesource.com/platform/tools/base/+/399103996d94d961fe82ca82cd0cffdfe3044f29
Since next week will be our last check-in date for 3.5.0-rc01, I feel that cherry-picking this change back to 3.5 is a bit risky.
@Jerome: Please let me know if you think cherry-picking to 3.5 still makes sense.
Change:
Since next week will be our last check-in date for 3.5.0-rc01, I feel that cherry-picking this change back to 3.5 is a bit risky.
@Jerome: Please let me know if you think cherry-picking to 3.5 still makes sense.
to...@gmail.com
Only blocking thing for me is still Room library, but it also looks that version with incremental support will be available really fast.
I meantime changed also java annotation processor to kapt. So I'm curious if I will still have an issue with it as I have so far like every minimal code change always caused full recompilation.
I meantime changed also java annotation processor to kapt. So I'm curious if I will still have an issue with it as I have so far like every minimal code change always caused full recompilation.
hu...@google.com
Yes, the work to make Room incremental is tracked at
Please open a new bug with us if you think your build is still not as fast as expected.
>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
Please open a new bug with us if you think your build is still not as fast as expected.
>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
to...@gmail.com
>> every minimal code change always caused full recompilation
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
I know, but not happen on small demo project, its happen only on the big one. I will investigate it more.
I would be very interested to find out, but as discussed above, would need a demo project to identify the issue.
I know, but not happen on small demo project, its happen only on the big one. I will investigate it more.
pj...@gmail.com
I updated project to use 3.5.0-rc03 and enabled android.databinding.incremental=true
I made change in single file and rerun the compilation. Got such output
"Full recompilation is required because 'AppUtils.java' was changed. Analysis took 0.162 secs."
I added few lines in the file but I don't understand why it needed to do full recompilation.
Is there a flag or other debug method that would tell me more about the case?
I made change in single file and rerun the compilation. Got such output
"Full recompilation is required because 'AppUtils.java' was changed. Analysis took 0.162 secs."
I added few lines in the file but I don't understand why it needed to do full recompilation.
Is there a flag or other debug method that would tell me more about the case?
[Deleted User] <[Deleted User]>
>>> I added few lines in the file but I don't understand why it needed to do full recompilation.
Might be due tohttps://github.com/gradle/gradle/issues/2767#issuecomment-323975456
Might be due to
hu...@google.com
Yes, that seems to explain it. A workaround is also posted on that bug: https://github.com/gradle/gradle/issues/2767#issuecomment-362192761
This situation has actually already been documented in the Gradle docs (https://docs.gradle.org/current/userguide/java_plugin.html#sec:incremental_compile ): "Since constants can be inlined, any change to [*** a class containing ***] a constant will result in Gradle recompiling all source files. For that reason, you should try to minimize the use of constants in your source code and replace them with static methods where possible". Note that the docs should probably say "any change to a class containing a constant" instead of "any change to a constant".
Here is the bug that tracks the work to improve this:https://github.com/gradle/gradle/issues/6482 .
This situation has actually already been documented in the Gradle docs (
Here is the bug that tracks the work to improve this:
[Deleted User] <[Deleted User]>
I commented[1] on the issue about the misleading documentation. Assuming we're right, it will be trivial to update the docs to reflect the full reality.
[1]https://github.com/gradle/gradle/issues/6482#issuecomment-522672671
[1]
ky...@gmail.com
guys anyone had the same issue C:\Users\Edgar\Desktop\GithubTask\app\build\generated\data_binding_base_class_source_out\debug\dataBindingGenBaseClassesDebug\out\android\com\githubtask\databinding\FragmentRepositoriesBinding.java:20: error: cannot find symbol
public final EditTextSearch etMainSearch;
^
symbol: class EditTextSearch
location: class FragmentRepositoriesBinding
public final EditTextSearch etMainSearch;
^
symbol: class EditTextSearch
location: class FragmentRepositoriesBinding
tu...@gmail.com
Comment has been deleted.
Description
I'm using annotation processor that support this feature already.
List of all is here
But in the build log is still this
"Incremental Java compilation disabled in variant ... as you are using an incompatible plugin"
Without any detailed explanation.
I tried to report it here
But according to Gradle team it comes directly from Android Build plugin.
And Xavier Ducrohet confirm it here:
I tried also to use
android.databinding.enableV2=true
And it doesn't help.
I'm creating this issue to track any further progress of this issue.
I think that incremental compilation can help a lot with our big projects, where just compilation on every run takes almost 40s because everything is recompiled every time.
Android Gradle Plugin: 3.2.0-alpha18
Gradle: 4.8