Is there a way of linking javadoc to libraries in AndroidStudio? I'm using the June 18 dev build of Android Studio, and my dependency for the android plugin is: com.android.tools.build:gradle:1.2.3.Gradle 2.4 is being used by the wrapper.
If, for example, I delete everything from ~/.gradle/caches and rebuild project then all libraries are downloaded. I resynch in AS and then by navigating eg. to class org.hamcrest.MatcherAssert AS allows me to download or choose sources. That gets me to sourcecode (as opposed to dissassembled code), but how to get linked external javadoc. Is this a bug? Is there a workaround?
https://code.google.com/p/android/issues/detail?id=59220
Related
I am trying to use a TabLayout in an Android project using Eclipse and Andmore but haven't been able to find a jar containing the required android.support.design.widget.TabLayout class.
Googling a bit, it seems I need the com.android.support:design:22.2.0 library. However, the latest version I can find in my SDK installation (under extras/android/support) is v17.
Where can I find this library (without having to migrate to Android Studio)?
Update your sdk using sdk manager.
With the help of a few other answers I finally managed to import everything. Putting it all together, just copyiing the jar into libs will not be sufficient. Here's how it works in Andmore (ADT should be similar but some options apparently differ):
Make sure your SDK is up to date. Specifically, you want the latest version of Extras > Android Support Library (should be version 22 or higher) and a matching version of Tools > Android SDK Build-tools.
If you have a copy of android-support-v4.jar in the libs folder of your app's source tree, replace it with a recent copy from <sdk>/extras/android/support/v7/appcompat/libs. (If you have other Android support JARs in that location, you may need to update those as well.)
Copy <sdk>/extras/android/support/v7/appcompat and <sdk>/extras/android/support/design into your workspace folder. (Not really necessary, but using a local copy will prevent polluting your SDK setup with Eclipse-generated files.
Select File > New... > Android Project.
Select Create project from existing source and select your copy of the appcompat folder. Be sure to select at least API 22 as a build target (I needed to use API 23, YMMV), and don't forget to give it a meaningful name.
When import has finished, open the properties of the new project, go to Android and check Is Library.
Repeat the same two steps to import the design library. After import, in its project properties, go to Android, and in Libraries add a reference to the appcompat project.
Open the properties of your app project, go to Android, and in Libraries add a reference to the design project.
I had to make some minor modifications to my source code as some resource identifiers are no longer constants as of API 14, requiring me to convert a switch statement to a series of ifs. After that, I could finally build my app.
This should work for other Android libraries as well – their locations are documented in http://developer.android.com/tools/support-library/features.html.
Edit: There may be an easier way: Both ADT and Andmore also have Android Tools > Add Support Library, which might make a few of the aforementioned steps easier, which installs the most recent version of the support library. But you still have to add them to your project by hand.
Got it. Everything's there if you update your SDK to the latest version, things are just a bit hidden in the folder tree. You'll need three JARs:
extras/android/support/v7/appcompat/libs/android-support-v4.jar (the file was already in my project but I upgraded it anyway – not sure if it was necessary)
extras/android/support/v7/appcompat/libs/android-support-v7-appcompat.jar
extras/android/support/design/libs/android-support-design.jar
Copy these three to your project's libs dir, refresh your project in Eclipse (cleaning won't hurt as well) and you should be good.
Library locations are documented in http://developer.android.com/tools/support-library/features.html
I am studying Look API (from Samsung Mobile SDK). To do this I have put sample from Samsung Mobile SDK to my app. There is nothing complex, just Activity is created and a texview from one of Look classes is instintiated.
When I run the app on a simulator (open smartclip activity) I got error from dalvikvm. From LogCat:
Could not find class 'com.samsung.android.sdk.look.smartclip.SlookSmartClip$1', referenced from method com.samsung.android.sdk.look.smartclip.SlookSmartClip.setDataExtractionListener
I use ADT bundle with Mobile SDK 1.0.2 (Look is 1.0.0).
Simulator device is Android 4.2.2 without Look support (but it does not matter as all files exported).
I verified that the project configured correctly to export the look.jar into resulting apk-file.
I have checked that all the external libraries are exproted to apk and have de-dexed the resulting classes.dex to verify that class SlookSmartClip$1 is actually there.
Maybe this question is more general to ADT 22 + 3rd party jar library problem. But almost always people do not export the files propertly, here I do not have this issue.
Do you know what is the problem?
PS: I tried to unchecked Android Private Library in export. After that the libraries are not appear in bin/dexedLibs and not in apk (classes.dex). After checking again (cleaning project all the time), they appear in bin/dedexedLibs and packaged into apk in classes.dex. I do not understand how dalvikvm cannot find them...
This error is generated only when library is not well included you need to add the lib jar provided by samsung to the project
right click project-> properties -> java build path -> libraries.
and add your jar
Google's instructions for using the Play Service API (for example) say:
Copy the /extras/google/google_play_services/libproject/google-play-services_lib library project into the source tree where you maintain your Android app projects.
Note: You should be referencing a copy of the library that you copied to your source tree—you should not reference the library from the Android SDK directory.
This seems ugly to me - why not reference it from the SDK directory? Is there some technical reason for this? Or is it so that you have explicit control over when it gets upgraded?
I'd like to point out that this is entirely a limitation of Eclipse, and it is indeed ugly.
The problem is that this library contains resources in addition to source code. Eclipse can only deal with libraries packaged as jar files, which, for the purposes of Android development, cannot contain resources.
So, in order for the library's resource to be compiled into the application, the library's source code, with the resources, must be added to your project.
If you move your build to Maven, and use an IDE that 'understands' Maven, then you can compile a library that contains resources as an 'apklib', and treat it as an external library, in a manner similar to a jar file.
The new Gradle-based build system is built on Maven primitives, but uses a different format for this, 'aar'. Hopefully, it will eventually also support apklib so that Maven builds and Gradle builds can inter-operate.
I just went through the exercise of converting an Android application to a Maven build, including the use of some apklibs. I can tell you that Eclipse with the m2eclipse plugin does not handle apklibs properly. Both IntelliJ and the new Google Android Studio (based on IntelliJ) do handle apklibs with no issues.
It's not about "Play Services Library" specifically. Just like any other libraries that the project makes use of, this library should be referenced from project's source tree.
In this case the external library is in the Android SDK directory and referencing from there is not a good practice too. So yes, it can be called "a technical reason".
Used libraries (Play Services library in this case) shouldn't be referenced from anywhere other than the project's source tree.
Today, I upgraded ADT to version 22. After that, my projet wouldn't compile resources at all. My "gen" folder was empty and as such all my java files that require "R" wouldn't compile.
After a few non-full time hours, I restarted the "Android SDK Manager" and this time, I noticed these:
- "Android SDK Platform Tools" (upgrade)
- "Android SDK built-tools" (new)
After installing those, I was finally able to fully compile my project.
ADT22 use Android Private Libraries show project/libs'jar, add Exported feature, if you wannt reference library projects' private libraries, you must check the Exported
https://plus.google.com/photos/117122118961369445953/albums/5878509263473846433/5878509268379848162?authkey=CL3Frb-S_qj-fQ
If you are using some libraries or/and dependencies with other projects, you may also experience errors at execution time. In my case I had problems with Sherlock "Unable to execute dex: Multiple dex files define Lcom/actionbarsherlock/R$attr" and with some other jar file I am using "VFY: unable to find class referenced in signature" In that case, you must go to project properties, Java Build Path section, and remove Android Dependencies and Android Private Libraries, both in the main project and also in the dependent projects like for example Sherlock. After that you perform Clean on all projects. Everything should be restored. That worked for me, after a hard battle!
I have modularised some simple classes into their own project for reuse elsewhere. These classes typically contain only fields and accessor methods (i.e. nothing Android specific).
They are later packaged up using ant's jar task and stored in a Maven repository.
In an Android project, I've stored said jar file into a libs directory and added to the build path. On running the emulator however, I get a "class not found" exception relating to my package. Other third party libraries (such as GSon) are being picked up fine.
Are there any specific steps required to make a jar file compatible with Android? (This reply seems to suggest otherwise). How can I debug this further?
No as long as you do not need e.g. classes from javax.* that are not in Android. If I were you I would consider looking at using the Android Maven Plugin for your build though. Check out the morseflash example from the official samples collection. It showcases exactly your scenario.
You only need an Android library project if your going to be reusing Android components and resources. In your case, I believe you added the project to the build path, but I'm sure your not exporting it as part of the dependent project.
So open the project properties, open up the Java Build Path options and make sure that you have your JAR selected as an exported dependency in the Order and Export tab.
UPDATE
This is what your entry should read:
<classpathentry exported="true" kind="lib" path="libs/tlvince-dao-0.1.0.jar"/>
I've also forked an updated version of your gist.
This issue was a result of compiling the jar to Java 7. Android does not support Java 7 (yet).
Compiling to Java 6 bytecode by setting target="1.6" in ant's javac task solved the issue.