Develop Reference

error while generating apk in android studio after gradle build is successfull

while generating apk getting this error i have already tried upadting the pugins also as it was recommended
Annotation processors must be explicitly declared now.
The following dependencies on the compile classpath are found to contain annotation processor. Please add them to the annotationProcessor configuration.
- icepick-processor-3.2.0.jar (frankiesardo:icepick-processor:3.2.0)
- auto-service-1.0-rc2.jar (com.google.auto.service:auto-service:1.0-rc2)
Alternatively, set android.defaultConfig.javaCompileOptions.annotationProcessorOptions.includeCompileClasspath = true to continue with previous behavior. Note that this option is deprecated and will be removed in the future.
See https://developer.android.com/r/tools/annotation-processor-error-message.html for more details.

You should explicitly add annotation processors in gradle. Putting the following in your gradle dependencies should fix it:
annotationProcessor 'frankiesardo:icepick-processor:3.2.0'
annotationProcessor 'com.google.auto.service:auto-service:1.0-rc2'

Gradle dependency configuration : implementation vs api vs runtimeonly vs compileonly

Unable to understand the latest gradle dependency configurations which are introduced in Android Studio 3.0 i.e. implementation, api , compileonly and runtimeonly.

Please refer the link : Android Studio 3.0 New Gradle Configuration available at android developers official site.
Based on description mentioned in above link:
implementation: When your module configures an implementation dependency, it's letting Gradle know that the module does not want to
leak the dependency to other modules at compile time. That is, the
dependency is available to other modules only at runtime. Using this
dependency configuration instead of api or compile can result in
significant build time improvements because it reduces the amount of
projects that the build system needs to recompile. For example, if an
implementation dependency changes its API, Gradle recompiles only that
dependency and the modules that directly depend on it. Most app and
test modules should use this configuration.
api: When a module includes an api dependency, it's letting Gradle know that the module wants to transitively export that
dependency to other modules, so that it's available to them at both
runtime and compile time. This configuration behaves just like compile
(which is now deprecated), and you should typically use this only in
library modules. That's because, if an api dependency changes its
external API, Gradle recompiles all modules that have access to that
dependency at compile time. So, having a large number of api
dependencies can significantly increase build times. Unless you want
to expose a dependency's API to a separate test module, app modules
should instead use implementation dependencies.
compileOnly: Gradle adds the dependency to the compilation classpath only (it is not added to the build output). This is useful
when you're creating an Android library module and you need the
dependency during compilation, but it's optional to have present at
runtime. That is, if you use this configuration, then your library
module must include a runtime condition to check whether the
dependency is available, and then gracefully change its behavior so it
can still function if it's not provided. This helps reduce the size of
the final APK by not adding transient dependencies that aren't
critical. This configuration behaves just like provided (which is now
deprecated).
runtimeonly: Gradle adds the dependency to the build output only, for use during runtime. That is, it is not added to the compile
classpath. This configuration behaves just like apk (which is now
deprecated).

Android Studio 3 and Gradle 4.3 -> Library modules no longer process local JARs -> how to handle this?

Upgrade to Android Studio 3.0.0 mentions this, and doesn't elaborate on how to handle it:
Library modules no longer process local JARs. This is to speed up incremental builds that are caused by changes to a library module's code.
So I have a project with a library project in it. In my library project's build.gradle file I have this:
compile files('libs/com.somelib.somepackage.jar')
I changed compile to implementation and when I tried to run my app, all my classes that tried to access the import com.somelib.somepackage.SomeClass import statement threw an error that this package didnt exist.
I changed back to compile and I was able to build and run my app.
I want to comply to the new rules since compile is deprecated and will be removed with the next Gradle release, so how do I go about doing that?

If you are trying to access classes from the .jar that is included in the library project from the app project, you will have to use api instead of implementation otherwise the classes will only be accessible in the library project:
implementation files('libs/com.somelib.somepackage.jar')
should be
api files('libs/com.somelib/somepackage.jar')
As said by the documentation:
... When a module includes an api dependency, it's letting Gradle know
that the module wants to transitively export that dependency to other
modules, so that it's available to them at both runtime and compile
time ...
Reference:
https://developer.android.com/studio/build/gradle-plugin-3-0-0-migration.html#new_configurations

Facebook SDK Causes Warning in app Gradle File (Android Studio)

I am using the following dependency
compile 'com.facebook.android:facebook-android-sdk:4.+'
compile "com.android.support:support-v4:${rootProject.ext.supportLibVersion}"
compile "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
compile "com.android.support:design:${rootProject.ext.supportLibVersion}"
Where the ${rootProject.ext.supportLibVersion} part refers to the value "25.3.1". Now the issue is that Gradle says that there is a conflict due to the existence of multiple versions of the same support library (specifically 25.0.0 and 25.3.1). I run the Gradle dependency tree task and viewed it. I finally found the conflict and it's caused by the Facebook SDK which uses the following:
com.android.support:cardview-v7:25.0.0
com.android.support:customtabs:25.0.0#aar
How to solve this conflict? I know the app is working and everything but a crash may happen in runtime. I also want to get rid of the warning in the Gradle file.

Gradle dependencies difference between compile, apk project, compile project,provided,implementation project

Gradle dependencies difference between.
compile
apk project
compile project
provided project
implementation
My questions are
What's the difference between compile ,apk project, compile project,provided project here?

There's two separate things to discuss here: Dependency Configurations and Dependency Sources.
Dependency Configurations
Configurations help define the transitivity of a dependency, which in turn removes the pain of having to discover and specify the libraries your own project/library requires, including them automatically. This notion of configurations in gradle is very similar to that of Maven's scopes:
compile: Compile dependencies are available in all classpaths of a project. Furthermore, those dependencies are propagated to dependent projects. A compile-time dependency is generally required at runtime.
apk: Defines a runtime dependency. A dependency with this scope will not be required at compile time, but it will be for execution. This means that you can save time while compiling and still have the dependency available when your project actually runs. This is a good example of when to use an apk dependency.
provided: It means that this dependency is available on the runtime environment. As a consequence, this scope is only available on the compilation and test classpath, and is not transitive. It is not supported on Android projects, though you can workaround it by defining your own configuration as discussed here.
There are more configurations that you can encounter on Android, such as testCompile, which allows you to specify a compile-time dependency that will only be used for testing, say you want to use junit in your tests, then you would do as follows:
testCompile 'junit:junit:4.12'
Dependency Source
Once you understand the configurations available for you, you need to specify an actual dependency. Dependencies might be internal or external, you may rely on another library you are working on, as well as on publicly available libraries. Here's where the project keyword comes in, allowing you to specify a dependency to an internal module or library. By defining a dependency as compile project, you are adding that module or library as a transitive dependency to your project.
Assume you have a project messages with three modules (producer, consumer and shared), the project structure would look as follows:
messages/
build.gradle
settings.gradle
consumer/
build.gradle
producer/
build.gradle
shared/
build.gradle
Now assume that both consumer and producer store messages in json format and that you want to use google-gson for that purpose. Assume that both projects have some common source code that they depend on, your shared module. consumer's build.gradle could then define the following dependencies:
dependencies {
// Internal dependency to project shared
compile project (':shared')
// External dependency to publicly available library,
// through public repositories such as jcenter() or mavencentral()
compile 'com.google.code.gson:gson:1.7.2'
}
To sum up, it is the combination of both configurations and sources that enables you to declare dependencies as compile, compile project, apk project and more!