We have a project with some library (and native) dependencies, like this:
Native SDK ← Library (Wrapper) ← Main Project
To start with, this structure cannot be changed, as we are reusing the parts. The problem I am facing is passing the 65k reference limit. This, of course, has a workaround - enable ProGuard. With it enabled, the project compiles.
Since we are transitioning to the Android's default testing framework, we need to add some more dependencies to the testing config, so in dependencies we now have:
compile 'com.google.android.gms:play-services-base:7.5.0'
compile 'com.google.android.gms:play-services-gcm:7.5.0'
compile 'com.google.android.gms:play-services-safetynet:7.5.0'
compile 'com.android.support:appcompat-v7:22.2.1'
compile 'com.android.support:recyclerview-v7:22.2.1'
compile files('libs/small-library1.jar')
compile files('libs/small-library2.jar')
compile files('libs/small-library3.jar')
compile files('libs/medium-library1.jar')
compile files('libs/medium-library2.jar')
compile files('libs/medium-library3.jar')
compile files('libs/huge-library1.jar')
compile files('libs/huge-library2.jar')
androidTestCompile 'com.android.support.test:runner:0.3'
androidTestCompile 'com.android.support.test:rules:0.3'
androidTestCompile 'com.android.support.test.espresso:espresso-core:2.2'
We are using SDK (API) 22, so everything is pretty much at the latest version. The problem is, our native SDK has a bunch of code in the protobuf layer, and the library wrapper is big. With all other JARs, we are too high over the 65k limit (but as I said, ProGuard fixes this barely). Multi-dex is out of the question as it works well only on Android 5.0+.
We're trying to reduce the codebase, but even then, Android Tests are failing with method reference overflow issues (i.e. not compiling).
Is there any way to enable ProGuard for tests as well?
One option is to change your test build using testBuildType to the release build or another build variant that has ProGuard enabled. See Gradle User Guide. You can also try the solution here, but I have not tried that myself.
Related
gradle sync keeps failing with my android studio. need help
https://github.com/linkedin/dexmaker This is the open source i am trying to use called dexmaker.
I tried to download by using
androidTestCompile 'com.linkedin.dexmaker:dexmaker-mockito-inline:2.21.0'
but it gets errors like this
Failed to resolve: com.linkedin.dexmaker:dexmaker-mockito-inline:2.21.1
I finally tried
androidTestCompile 'com.linkedin.dexmaker:dexmaker-mockito-inline:2.19.1'
this works but in my java code
The problem is even though i succeeded on syncing gradle, i still can't use the opensource.
DexMaker dexMaker = new DexMaker();
DexMaker gets red lines and if i click it it says
cannot resolve symbol 'DexMaker'
what's the problem?
I'm not sure, but as I understand your situation:
You add dependency using androidTestCompile directive. That means that this package will become available only inside android test classes. For more understanding each dependency could be added in three ways: compile, testCompile and androidTestCompile.
compile : Dependency is available everywhere in your application code.
testCompile : Dependency available only in regular tests.
androidTestCompile : Dependency available only in android tests.
So if you want that dependency to be available in your application - replace androidTestCompile with compile. But I not sure, that you SHOULD do that, cause that library is for tests.
P.S. Using compile directives is deprecated and you should use implementation, testImplementation and androidTestImplementation.
How would I translate those to implementation or api?
Fx. what should I replace those with?
compile project(':jabraServiceApi')
compile files('libs/samsung-digital-health-healthdata-1.2.1.jar')
Maybe compile project and compile files are still supported and should stay as they are?
Gradle 3.4 introduced new Java Library plugin configurations configurations that allow you to control whether a dependency is published to the compile and runtime classpaths of projects that consume that library. The Android plugin is adopting these new dependency configurations, and migrating large projects to use them can drastically reduce build times. The following table helps you understand which configurations you should use.
I already give the answer here please check compile configuration is now deprecated .
Android Studio 2.2.2
Compile SDK Android 7.1.1
Build Tools: 25.0.0
Gradle version: 2.14.1
Min SDK: 19
Target SDK: 25
I encountered an issue with jackson-dataformat-xml-2.8.5.jar when attempting to execute this:
JacksonXmlModule module = new JacksonXmlModule();
ObjectMapper xmlMapper = new XmlMapper(); //This line
throws the following exception
E/AndroidRuntime: FATAL EXCEPTION: Thread-418
Process: cb.myAppName, PID: 29744
java.lang.VerifyError: com/fasterxml/jackson/dataformat/xml/XmlFactory
at com.fasterxml.jackson.dataformat.xml.XmlMapper.<init>(XmlMapper.java:49)
at cb.myAppName.Core.GenerateReturnXMLFile(Core.java:863)
at cb.myAppName.RouteScreenActivity$4.run(RouteScreenActivity.java:305)
at java.lang.Thread.run(Thread.java:841)
From what I researched, it has to do with a binary incompatibility that was introduced in Jackson 1.3. As stated by Tatu Saloranta in his old blog which sadly is no longer online.
I have always valued compatibility quite highly, at least for any "non
beta" release (1.0 and above). As a result, the idea has been that any
1.x release would be simple plug-and-play over previous one. This does work for patch releases; but it turns out that not all minor releases
have worked this way. For example, versions 1.2 and 1.3 have some
unexpected incompatibilities.
Problem is this: although most commonly binary compatibility is a
harder goal than source compatibility -- that is, if you break source
compatibility, you are almost guaranteed to break binary compatibility
-- it is not strictly so. Specifically, it is quite possible to make certain changes that are source compatible, but that are NOT binary
compatible.
Specific case in point is that of changing a method that returns
nothing ("void method") into method that returns something does not
break compilation. But it does actually break binary compatibility.
UGH.
And this is exactly what happened when I decided that it would be nice
to make ObjectMapper follow "fluent" pattern, to allow for chaining of
configuration method calls. This would be nice, if it was not this
"hidden" API change...
Not quite sure how to correct this though since i'm fairly new to android development.
I already made sure to use same version of Jackson across the board as you can see in my list of dependencies from the app/build.gradle, is there something else I may be missing?
dependencies {
compile fileTree(include: ['*.jar'], exclude: ['com.symbol.emdk.jar'], dir: 'libs')
compile files('../libs/json-20151123.jar')
provided files('../libs/com.symbol.emdk.jar')
compile files('../libs/slf4j-api-1.7.6.jar')
compile files('../libs/logback-android-1.1.1-4.jar')
compile files('../libs/sun.misc.BASE64Decoder.jar')
compile files('../libs/ZSDK_ANDROID_API.jar')
compile 'com.android.support:appcompat-v7:22.2.1'
compile 'com.android.support:support-v7:22.2.0'
compile 'com.google.code.ksoap2-android:ksoap2-android:3.6.0'
compile 'com.google.code.gson:gson:2.4'
compile 'org.apache.directory.studio:org.apache.commons.io:2.4'
compile 'org.joda:joda-money:0.11'
compile 'org.apache.directory.studio:org.apache.commons.lang:2.6'
compile 'com.google.android.gms:play-services-appindexing:9.8.0'
compile 'org.greenrobot:eventbus:3.0.0'
compile 'com.fasterxml.jackson.core:jackson-core:2.8.5'
compile 'com.fasterxml.jackson.core:jackson-databind:2.8.5'
compile 'com.fasterxml.jackson.datatype:jackson-datatype-joda:2.8.5'
compile 'com.fasterxml.jackson.dataformat:jackson-dataformat-xml:2.8.5'
compile 'com.github.gcacace:signature-pad:1.2.0'
}
As per the official FasterXML Jackson github page, the extension i'm using should be supported...
XML: supports XML; provides both streaming and databind
implementations. Similar to JAXB' "code-first" mode (no support for
"XML Schema first", but can use JAXB beans)
https://github.com/FasterXML/jackson-dataformat-xml
This issue was also reported on the project's github page but no real solution was reached. -- github.com/FasterXML/jackson-dataformat-xml/issues/116
UPDATE: I used jarjar on the following dependencies:
compile files('../libs/cb-joda-time-2.9.6.jar')
compile files('../libs/cb-joda-money-0.12.jar')
compile files('../libs/cb-jackson-dataformat-xml-2.8.5.jar')
compile files('../libs/cb-jackson-datatype-joda-2.8.5.jar')
compile files('../libs/cb-java-json-0.13.0.jar')
compile files('../libs/cb-json-20160212.jar')
Also upgraded every single dependency to latest version as well as my appcompat and support api.
The error continues -
java.lang.VerifyError: cb/com/fasterxml/jackson/dataformat/xml/XmlFactory
at cb.com.fasterxml.jackson.dataformat.xml.XmlMapper.<init>(XmlMapper.java:49)
Hopefully someone can shine some light on this, not sure what is causing this...
After some research and tips from user aha I was able to further identify how to correct this. I haven't had time to test it since I ended up taking a different route and using SimpleXML library instead which works great for what I needed to do.
I will update this answer with more details when I do get around to testing it but here are some ways to attempt and correct this:
Include Stax as a dependency: github.com/FasterXML/jackson-dataformat-xml#android-quirks
Execute gradle dependencies. Gradle will then display the actual dependency tree that it has used to compile and package your app. The generated dependency tree might be different than the dependencies you'd declared, e.g. because of transitive dependencies. -Thanks aha
This is the original issue at github: github.com/FasterXML/jackson-dataformat-xml/issues/116
I work with Android and I use some libraries on dependencies (build.gandle).
example:
dependencies {
compile fileTree(include: ['*.jar'], dir: 'libs')
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.2.0'
compile 'info.hoang8f:fbutton:1.0.5'
compile 'com.nineoldandroids:library:2.4.0'
compile 'com.daimajia.easing:library:1.0.1#aar'
compile 'com.daimajia.androidanimations:library:1.1.3#aar'
compile 'com.android.support:support-v4:23.2.0'
compile 'com.google.android.gms:play-services-ads:8.4.0'
}
I'm new in xamarin development and I wanna know if there something which i can use my android libraries on xamarin
thank you
I think you can make use of Xamarin.GradleBindings, Visual Studio extension, creates Xamarin Android Binding projects from external dependencies ids via gradle.
How do java developers add dependencies to their projects? Yes that's right, via gradle (something like this or that). As you can see some java-projects use those dependencies a lot (all you want to write is already written) so it'd be nice to use those huge amount of 3rd party libraries in your Xamarin project, right? I believe this Add-in for Visual Studio 2013 (and lately for Xamarin Studio) will help you with it:
Step 1: Execute the command over "References" folder
Step 2: Set an external dependency id and a name for Xamarin Android Binding Project (will be generated). This dialog will allow you to specify custom repositories as well soon.
The Plugin executes gradle scripts and receives dependencies list (including transitive ones). At this step you can select or deselect needed binaries (transitive dependencies are deselected by default).NOTE: you'd better use "Xamarin Components" or directly NuGet for Support dependencies(v4, RecyclerView, AppCompact, etc..).
Step 3: The binding project will be generated but you still may have to fix some issues via Metadata.xml because the Add-in is not smart enough.
Step 4: Now you are ready to use them! i.e. the Material Dialogs:
Reference :
https://visualstudiogallery.msdn.microsoft.com/3a3257c7-473a-4790-9610-9a561eed0b8c
https://github.com/cfraz89/xamarin-gradle-plugins
In Gradle in Android Studio I noticed providing a dependency scope is optional. For example:
dependencies {
compile fileTree(dir: 'libs', include: ['*.jar'])
testCompile 'junit:junit:4.12'
compile 'com.android.support:appcompat-v7:23.1.1'
compile 'com.android.support:design:23.1.1'
'org.hamcrest:hamcrest-core:1.3'
'org.hamcrest:hamcrest-library:1.3'
}
Notice the very last two libraries don't have a compile scope attached. I left it blank and I was still able to sync gradle. What is the default scope if nothing is specified here ?
The scope is actually a label for a given dependency configuration. It depends very much on the gradle plugins you are using (i.e.: java plugin or android plugin).
If you don't add any configuration label, it will be saved as an unlabeled dependency.
Most of the time if you need a implementation dependency and do not add the label, your build will break. If it doesn't break it could be because:
You were not actually needing the dependency
You are using a gradle plugin that handles nicely unlabeled dependencies
Or (more probably), the dependency is already on your build cache or partial build and therefore the compiler is still able to find the classes, but will break if you clean the project.
Related documentation on dependency configuration for gradle
There is a small update to Logain's answer. compile is deprecated now. implementation can be used to replace it.
https://docs.gradle.org/current/userguide/java_plugin.html#sec:java_plugin_and_dependency_management