IssueTracker

As a workaround we added the following to our own manifest:
<provider
            tools:replace="android:authorities"
            android:name="com.google.android.gms.measurement.AppMeasurementContentProvider"
            android:authorities="${applicationId}.google_measurement_service"
            android:exported="false" />

You must have tools namespace defined in the xml.

I've also been affected by this!

@2 I also opened an issue with tools guys https://code.google.com/p/android/issues/detail?id=193567 . I'm not really sure which team should fix it. There's another workaround there that in my opinion is cleaner.

I've added
android {
    defaultConfig.applicationId = "my.package.id"
}

to my gradle file and it fixed that issue for me

Setting android.defaultConfig.applicationId in your gradle file is something that is expected to be set in Android projects. This is automatically added when you create a new Android project in Android Studio.

However when applicationId isn't present in the project gradle the play-services-measurement AAR package in its AndroidManifest.xml gets defaulted in. This creates a silent issue for the app developer as their is no warnings or errors when the app builds. Only after another app that was build the same way is also installed on the device is the issue known as the OP noted with the INSTALL_FAILED_CONFLICTING_PROVIDER error.

The fix is adding android.defaultConfig.applicationId to your app's gradle file as others have noted however, the play-services-measurement AAR or the build tools should be changed to throw an error if this is missing.

In cordova generated projects android.defaultConfig.applicationId is missing

I have already opened an issue with Cordova on this not being adding by default and have provided a work around to set android.defaultConfig.applicationId in the comments until Cordova fixes this.
https://issues.apache.org/jira/browse/CB-10014

Thanks for the solution in #4 - that worked for me!

Are these apps successfully uploading to the play store? And users of the apps are seeing this error?

I'm wondering if the play store checks for authorities uniqueness to ensure this doesn't happen on a wide scale.

#4 did the trick.

The users only see an errormessage with code 505, an errormessage that is given for other installation-failures as well.

Error persists in Google Play Services version 8.4.89 (2428711-230).

Two apps I use are in conflict as described above in original post.

RadPad and Glassdoor.

Uninstall one, the other will install.

Any workaround for us users?

#12, You can try using older version and send feedback to the developers and hope they will fix it fast

#4 is the perfect solution, you saved my day!

I'm desperately requesting your help.

I'm having some users complaining about Play Store Error 505.
I cannot apply solution #4 because my project is a library project, so I'm getting: "Error: Library projects cannot set applicationId."
My app is currently using Play Services 8.3.0. Does anyone know what else I can try? Thanks in advance!

#15, who is using your library? he should set the app id.
Do you declare authority provider in your lib?

I could reproduce and fix this issue. This is referred in the following thread:
https://goo.gl/UvjIVk

Good luck & thank you.

There's no gradle support in Intel-XDK yet, due to security issues. Is there another way around to solve this problem without gradle?
Many thanks,

#18, you probably solved it already, but if someone else will read it, there is a solution for the issue with Intel-XDK, in https://software.intel.com/en-us/forums/intel-xdk/topic/607293.
There is a special branch of the Pushwoosh plugin, to be used with Intel XDK (see Paul F answer)

Currently affecting Dashlane Beta and Crunchyroll for example. Can only have one of them installed :(

I look in to it see who or witch team can do that

Others are reporting that system apps on devices from LG and HTC also conflict. See https://groups.google.com/d/topic/dashlane-beta-channel/eC0yyivtxEg/discussion

Among others, the following apps are known to exhibit this issue:
* LG's NLP helper
* HTC Push Services
* Dashlane
* Crunchyroll
* Groundlink

This should be fixed at the framework level. Some projects have patched their Gradle configs to work around this problem, but others (notably Dashlane) stubbornly insist that it is a Google problem and not their responsibility to fix, despite the availability of simple workarounds.

[Comment deleted]

Closing issue due to inactivity.  Please comment if assistance is still needed for this issue.

no success on that issue :(

any luck?

comment#27 This issue is closed. You might have better luck opening a new one.

Thanks a lot! Currently, I'm testing 3.4.0 version. I will try 3.5.0 ASAP.

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.

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

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 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 12s https://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.

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

I have also Kotlin code in the project, but I'm using just java annotation process also.

@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.

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.

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.

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

@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.

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 ?

"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). See https://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.

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.

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.

Yes, the work to make Room incremental is tracked at Issue 112110217.

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.

>> 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 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 added few lines in the file but I don't understand why it needed to do full recompilation.

Might be due to https://github.com/gradle/gradle/issues/2767#issuecomment-323975456

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.

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

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