Using "Import Project" in Android Studio for an Eclipse project used to change the project structure and generate Gradle files, but right now (I'm using AS 0.5.3) it's only generating IDEA files (.iml, .idea) but not Gradle and it's not touching the file structure either.
How do you import an Eclipse project into Android Studio now?
Update: Trying to export gradle files in Eclipse won't export them for the app, it doesn't show up as a module in Android Studio either.
In newer versions of Android Studio, the best way to bring in an Eclipse/ADT (Android Development Tool) project is to import it directly into Android Studio; we used to recommend you export it from Eclipse to Gradle first, but we haven't been updating ADT often enough to keep pace with Android Studio.
In any event, if you choose "Import Project" from the File menu or from the Welcome screen when you launch Android Studio, it should take you through a specialized wizard that will prompt you that it intends to copy the files into a new directory structure instead of importing them in-place, and it will offer to fix up some common things like converting dependencies into Maven-style includes and such.
It doesn't seem like you're getting this specialized flow. I think it may not be recognizing your imported project as an ADT project, and it's defaulting to the old built-into-IntelliJ behavior which doesn't know about Gradle. To get the specialized import working, the following must be true:
The root directory of the project you import must have an AndroidManifest.xml file.
Either:
The root directory must contain the .project and .classpath files from Eclipse
or
The root directory must contain res and src directories.
If your project is complex, perhaps you're not pointing it as the root directory it wants to see for the import to succeed.
Export from Eclipse
Update your Eclipse ADT Plugin to 22.0 or higher, then go to File | Export
Go to Android now then click on Generate Gradle build files, then it would generate gradle file for you.
Select your project you want to export
Click on finish now
Import into Android Studio
In Android Studio, close any projects currently open. You should see the Welcome to Android Studio window.
Click Import Project.
Locate the project you exported from Eclipse, expand it, select it and click OK.
Try these steps:
1- click on Import project (Eclipse, ADT, ...)
2- Choose main directory of your Eclipse project
3- Keep the defaults. The first two options is for changing jar files into remote libraries (dependencies). It mean while building Android studio try to find library in local system or remote repositories. The last option is for showing only one folder as app after importing.
4- Then, you will see the summary of changes
5- Then, if you see Gradle project sync failed, you should go to project view (top left corner). Then, you should go to your project-> app and open build.gradle.
6- Then, you should change your compilesdkVersion and targetsdkVersion to your current version that you see in buildToolsVersion (mine is 23). For example, in my project I should change 17 to 23 in two places
7- If you see an error in your dependencies, you should change the version of it. For example, in my project I need to check which version of android support library I am using. So, I open the SDK manager and go to bottom to see the version. Then, I should replace my Android studio version with my current version and click try again from top right corner
I hope it helps.
Its Got simpler with Android Studio
All you need is to first choose
import project(eclipse.....)
then choose your folder eclipse based project.like this one below
3.based on the type of project and library you used like (ActionBarSherlock) you may prompted special import wizard so go ahead and click next then finish.
in this case it was simple one
4.And you are done.
but sometimes the debug or Run options do not work and a error msg shows like
"this project structure is not gradle based or migrate it to gradle"
something
to solve this
close the opened eclipse project and reopen same project through the same process as we did before with import project (eclipse adt,gradle,etc)) this time android studio gonna add all necessary gradle files and green debug option will work too.
i have did this somehow accidentally but it worked, i just hope it works for you too.
Android Studio has been improved since this question was posted, and the latest versions of Android Studio (as of this writing, we are at 2.1.1) have fairly good Eclipse importing capabilities, so importing Eclipse projects directly into Android Studio is now the best approach for migrating projects from Eclipse into Android Studio.
I will describe how to do this below, including a few of the pitfalls that one might encounter. I will deal in particular with importing an Eclipse workspace that contains multiple apps sharing one or more project libraries (the approaches posted thus far seem limited to importing just one Eclipse app project and its project libraries). While I don't deal with every possible issue, I do go into a lot of detail regarding some of them, which I hope will be helpful to those going through this process for the first time themselves.
I recently imported the projects from an Eclipse workspace. This workspace included four library projects that were shared between up to nine projects each.
Some background:
An Eclipse workspace contains multiple projects, which may be library projects or apps.
An Android Studio project is analogous to an Eclipse workspace, in that it can contain both library projects and apps. However, a library project or an app is represented by a "module" in Android Studio, whereas it is represented by a "project" in Eclipse.
So, to summarize: Eclipse workspaces will end up as Android Studio projects, and Eclipse projects inside a workspace will end up as Android Studio modules inside a project.
You should start the import process by creating an Android Studio project (File / New / New Project). You might give this project the same (or similar) name as you gave your Eclipse workspace. This project will eventually hold all of your modules, one each for each Eclipse project (including project libraries) that you will import.
The import process does not change your original Eclipse files, so long as you place the imported files in a different folder hierarchy, so you should choose a folder for this project that is not in your original Eclipse hierarchy. For example, if your Eclipse projects are all in a folder called Android, you might create a sibling folder called AStudio.
Your Android Studio project can then be created as a sub-folder of this new folder. The New Project wizard will prompt you to enter this top-level project folder, into which it will create your project.
Android Studio's new project wizard will then ask you to configure a single module at the time you create the project. This can be a little confusing at first, because they never actually tell you that you are creating a module, but you are; you are creating a project with a single module in it. Apparently, every project is required to have at least one module, so, since you are relying on Eclipse to provide your modules, your initial module will be a placeholder to vacuously satisfy that formal requirement.
Thus, you probably will want to create an initial module for your project that does as little as possible. Therefore, select Phone and Tablet as the type of your module, accept the default minimum SDK (API level 8), and select Add No Activity for your module.
Next, select one of the Eclipse app projects in your workspace that requires the largest number of libraries as your first project to import. The advantage of doing this is that when you import that project, all the library projects that it uses (directly, or indirectly, if some of your library projects themselves require other library projects) will get imported along with it as part of the importing process.
Each of these imported projects will get its own module within your Android Studio project. All of these modules will be siblings of one another (both in your project hierarchy, and in the folder hierarchy where their files are placed), just as if you had imported the modules separately. However, the dependencies between the modules will be created for you (in your app's build.gradle files) as part of the importing process.
Note that after you finish importing, testing and debugging this "most dependent" Eclipse project and its supporting library projects, you will go on to import a second Eclipse app project (if you have a second one in your workspace) and its library project modules (with those imported earlier getting found by the import wizard as existing modules and re-used for this new module, rather than being duplicated).
So, you should never have to import even a single library project from Eclipse directly; they will all be brought in indirectly, based on their dependencies upon app projects that you import. This is assuming that all of your library projects in the workspace are created to serve the needs of one or more app projects in that same workspace.
To perform the import of this first app project, back in Android Studio, while you are in the project that you just created, select File / New / New Module. You might think that you should be using File / New / Import Module, but no, you should not, because if you do that, Android Studio will create a new project to hold your imported module, and it will import your module to that project. You actually could create your first module that way, but then the second through Nth modules would still require that you use this other method (for importing a module into an existing project), and so I think that just starting with an "empty" project (or rather, one with its own vacuous, do-nothing placeholder module), and then importing each of your Eclipse projects as a new module into that project (i.e., the approach we are taking here), may be less confusing.
So, you are going to take your practically-empty new project, and perform a File / New / New Module in it. The wizard that this invokes will give you a choice of what kind of module you want to create. You must select "Import Eclipse ADT Project." That is what accesses the wizard that knows how to convert an Eclipse project into an Android Studio module (along with the library modules on which it depends) within your current Android Studio project.
When prompted for a source folder, you should enter the folder for your Eclipse project (this is the folder that contains that project's AndroidManifest.xml file).
The import wizard will then display the module name that it intends to create (similar to your original Eclipse project's name, but with a lower-case first letter because that is a convention that distinguishes module names from project names (which start with an upper-case letter). It usually works pretty well to accept this default.
Below the module name is a section titled "Additional required modules." This will list every library required by the module you are importing (or by any of its libraries, etc.). Since this is the first module you are importing, none of these will already be in your project, so each of them will have its Import box checked by default. You should leave these checked because you need these modules. (Note that when you import later Eclipse app projects, if a library that they need has already been imported, those libraries will still appear here, but there will be a note that "Project already contains module with this name," and the Import box will be un-checked by default. In that case, you should leave the box unchecked, so that the importer will hook up your newly-imported module(s) to the libraries that have already been imported. It may be that accepting the default names that Android Studio creates for your modules will be important for allowing the IDE to find and re-use these library modules.
Next, the importer will offer to replace any jars and library sources with Gradle dependencies, and to create camelCase module names for any dependent modules, checking all those options by default. You should generally leave these options checked and continue. Read the warning, though, about possible problems. Remember that you can always delete an imported module or modules (via the Project Structure dialog) and start the import process over again.
The next display that I got (YMMV) claims that the Android Support Repository is not installed in my SDK installation. It provides a button to open the Android SDK Manager for purposes of installing it. However, that button did not work for me. I manually opened the SDK manager as a separate app, and found that the Android Support Repository was already installed. There was an update, however. I installed that, and tapped the Refresh button in the import dialog, but that did nothing. So, I proceeded, and the perceived lack of this Repository did not seem to hurt the importing process (although I did get messages regarding it being missing from time to time later on, while working with the imported code, which I was able to appease by clicking a supplied link that corrected the problem - at least temporarily). Eventually this problem went away when I installed an update to the repository, so you may not experience it at all.
At this point, you will click Finish, and after a bit it should create your modules and build them. If all goes well, you should get a BUILD SUCCESSFUL message in your Gradle Console.
One quirk is that if the build fails, you may not see your imported modules in the Project hierarchy. It seems that you need to get to the first valid build before the new modules will appear there (my experience, anyway). You may still be able to see the new modules in the File / Project Structure dialog (e.g., if you want to delete them and start your import over).
Remember that since you are not changing your original Eclipse projects, you can always delete the modules that you have just imported (if importing goes badly), and start all over again. You can even make changes to the Eclipse side after deleting your Android Studio modules, if that will make importing go better the second time (so long as you preserve your fallback ability to build your existing source under Eclipse). As you'll see when we discuss version control below, it may be necessary for you to retain your ability to build under Eclipse, because the project structure is changed under Android Studio, so if you need to go back to a commit that precedes your move to Android Studio (e.g., to make a bug fix), you will want to have the ability to build that earlier commit in Eclipse.
To delete a module, you must select File / Project Structure, then select the module from the left side of the dialog, and then hit the delete key. For some reason, I was not able to delete a module directly in the Project hierarchy; it had to be done using this Project Structure dialog.
The import wizard generates an import-summary.txt file containing a detailed list of any issues it may have encountered, along with actions taken to resolve them. You should read it carefully, as it may provide clues as to what is happening if you have trouble building or running the imported code. It will also help you to find things that the importer moves around to accommodate the different structure of Android Studio projects.
If all does not go well, then have at look at these possible problems that you may encounter, along with solutions for those problems:
Generally speaking, there are two main kinds of problems that I encountered:
Proguard problems
Manifest problems
When Proguard is messed up, the (obfuscated) names of methods in your libraries may not match the names being used to invoke them from your app, and you will get compiler errors like "error: cannot find symbol class ..."
In Eclipse, Proguard stuff is pretty much ignored for library projects, with the Proguard stuff for any app project that you are building determining the obfuscation, etc. for not just itself, but for processing all of the libraries on which it depends. And that is generally what you want.
In Android Studio, however, you need to make some changes to attain this same effect. Basically, in the build.gradle files for each of your library project modules, you will want something like this:
buildTypes {
release {
minifyEnabled false
consumerProguardFiles 'proguard.cfg'
}
}
Where proguard.cfg is your library module's own proguard configuration file.
The term "consumer" in "consumerProguardFiles" apparently refers to the app module that is using this library module. So the proguard commands from that app are used in preference to those of the library module itself, and apparently this results in obfuscations that are coordinated and compatible, so that all calls from the app module to its library modules are made with matching symbols.
These "consumerProguardFiles" entries are not created automatically during the import process (at least that was my own experience) so you will want to make sure to edit that into your library modules' build.gradle files if they are not created for you during importing.
If you wanted to distribute your library projects separately, with obfuscation, then you would need an individual proguard file for them; I have not done this myself, and so that is beyond the scope of this answer.
In the app module, you will want something like this:
buildTypes {
release {
minifyEnabled true
proguardFiles 'proguard.cfg'
}
}
(BTW, as of this writing, while my apps are running just fine, I have not yet directly confirmed that things are actually getting obfuscated using this approach, so do check this yourself - e.g., by using a decompiler like apktool. I will be checking this later on, and will edit this answer when I get that info).
The second kind of problem is due to the fact that Eclipse pretty much ignores the manifest files for library projects when compiling an app project that uses those library projects, while in Android Studio, there is an interleaving of the two that apparently does not consistently prioritize the app's manifest over those of its libraries.
I encountered this because I had a library manifest that listed (just for documentation purposes) an abstract Activity class as the main activity. There was a class derived from this abstract class in my app that was declared in the manifest of each app that used the library.
In Eclipse, this never caused any problems, because the library manifests were ignored. But in Android Studio, I ended up with that abstract class as my activity class for the app, which caused a run-time error when the code made an attempt to instantiate that abstract class.
You have two choices in this case:
Use tools syntax to override specific library manifest stuff in your app manifest - for example:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.goalstate.WordGames.FullBoard.trialsuite"
xmlns:tools="http://schemas.android.com/tools"
.
.
<application
tools:replace="android:name"
or,
Strip out practically everything from your library modules' manifests, and rely upon the app module's manifest to provide every value. Note that you do need to have a manifest for each library module, but not much more is required than the header and a bare manifest element with just a package attribute in it.
I tried both and ended up with approach 2., above, as the simpler method. However, if you wanted to distribute your library modules separately, you would need to create a more meaningful manifest file that reflects each library module's own individual requirements.
There is probably a more "correct" way to do this which puts requirements (e.g., permissions) for each library in the library manifest itself, and allows the automatic interleaving process to combine these with those declared for the app. However, given that Eclipse ignores the manifests for libraries, it seems safer at least initially to rely entirely on the app manifests and just strip the library manifests down to the bare bones.
Be aware that some of the project properties, and also the manifest attributes, from your Eclipse project will have been used to construct portions of your build.gradle files. Specifically, your compileSdkVersion in build.gradle is set to the project build version from the Eclipse project properties, applicationId is the package name from your app's manifest, and minSdkVersion and targetSdkVersion are also copied from the app's manifest file. The dependencies section of build.gradle comes from the library project dependencies in your project's properties.
Note that this may make some of your AndroidManifest.xml values redundant and quite possibly residual (i.e., unused). This could create confusion. My understanding is that the build.gradle values are the ones that actually have an effect, and that the manifest values like targetSdkVersion are not used any more for purposes of building. However, they may still be used by app stores such as Google Play; I don't know for certain one way or the other, so at this point I am just maintaining them in tandem.
Besides the above two kinds of issue, there are more routine things like importing a project that has a project build level of 22 when you have only installed SDK level 23 in Android Studio. In that situation, it is probably better to edit your app module's build.gradle file to move compileSdkVersion from 22 (the imported value) to 23, than it would be to install the SDK for level 22, but either approach should work.
Throughout this entire process, when something does not build properly and you make a change to try to address it, you might want to try Build / Rebuild Project and/or Tools / Android / Sync Project with Gradle Files, and/or File / Invalidate Caches/Restart, to make sure that your changes have been fully incorporated. I don't know exactly when these are truly necessary, because I don't know how much is done incrementally when you haven't yet had a successful build, but I performed them all fairly regularly as a kind of superstitious ritual, and I'm fairly certain that it helped. For example, when I got a Resources$NotFound runtime error that appeared to be from an inability to find the launch icon resource, I tried all three, and the problem was fixed.
When you have performed the above for your first Eclipse project and have attained a successful build, then with luck, you can select your app module from the dropdown at the top of the Android Studio display to the left of the play button, then click the play button itself, then select a device or Android Virtual Device, and the app should be loaded for running.
Likewise, you should be able to create a signed copy of your app using the Build / Generate Signed APK feature. Note that some import-related errors may appear when running your signed copy that do not appear when using the play button, so you need to confirm that both are working before deciding that your import is complete.
Following this, you will probably want to turn on version control. I am using git myself, but there are a number of other options available.
Version control is mostly beyond the scope of this answer, but there are a few things that are affected by the importing process. First, in Eclipse you might have your various projects in various folders stuck all over the place, but when you import into Android Studio, all modules will be created as direct child folders of your main project folder. So if you had a separate git folder for each project in Eclipse, or for related groups of projects organized under a parent folder for each group (as I did), that is not going to translate very well to Android Studio.
My knowledge of this is limited as I have not worked with version control yet in Android Studio, so maybe there is a way around this, but it appears that all version control in Android Studio is unified at the project level, and so all of your modules will be under a single git archive.
This means that you may need to abandon your old git archive and start fresh with a new archive for your imported source code. And that means that you will want to keep your old git archive around, so that it can be used with Eclipse to perform any needed bug fixes, etc., at least for a while. And you also will want it to preserve a history of your project.
If you are fortunate enough to have had all of your projects organized under a single Eclipse workspace, and if you were using a single git archive for those projects, then it is possible that you might just copy your old git archive from in and under your Eclipse workspace folder to in and under your Android Studio project folder. Then, you could edit any still-relevant .gitignore items from you Eclipse project into the auto-generated .gitignore file for your Android Studio project, and let git figure out what has been changed during the importing process (and some things will have been moved around - for example, the manifest file is no longer at the top level of your module). Others have reported that git is pretty good at figuring out what has changed; I have not tried this myself.
But even if you did this, going back to a commit that precedes your move from Eclipse to Android Studio would be going back to a set of files that would only make sense from inside Eclipse. So it sounds, well, "difficult" to work with. Especially since Eclipse will still be pointing to its original set of project folders.
I personally had multiple git archives for my various sets of related projects, and so I decided to just make a clean break and start git over again in Android Studio. If you had to do this, it could affect your planning, because you would want to be at a very stable point in your code development before making the move in that case, since you will lose some accessibility to that older code within your version control system (e.g., ability to merge with post-import code) once you have made the move to Android Studio.
The part of this answer that pertains to git is partly speculative, since I have not actually worked with version control yet on my imported project files, but I wanted to include it to give some idea of the challenges, and I plan to update my answer after I have worked more with version control inside Android Studio.
According to http://tools.android.com/tech-docs/new-build-system/migrating-from-eclipse-projects,
You have a couple of choices
- simply importing
- pre-exporting first from Eclipse.
Pre-exporting from eclipse may be the better choice if your project contains a lot of relationships that are Eclipse-specific. A.S. cannot 'translate' everything Eclipse can produce. If you want to continue using Eclipse as well as A.S. on this project code, this is the better choice. If you choose this method, please read the above link, there are some important pre-requisites.
Simply importing into AS will let AS 'translate' and rearrange the project, and is the recommended method, especially if you have no intention of returning to Eclipse. In this case, you let the A.S. wizard do everything and you dont need to manually generate gradle files.
In addition to the answer by Scott Barta above, you may still have import problems if there are references to Eclipse workspace library files, with e.g.
/workspace/android-support-v7-appcompat
being a common one.
In this case the import will halt until you provide a reference (and if you've cloned from a git repo, it probably won't be there) and even pointing to your own install (e.g. something like /android-sdk-macosx/extras/android/m2repository/com/android/support/appcompat-v7) won't be recognised and will halt the import, leaving you in no-man's land.
To get around this, look for refs in the project.properties or .classpath files that came in from the Eclipse project and remove/comment them out, e.g.
<classpathentry combineaccessrules="false" kind="src" path="/android-support-v7-appcompat"/>
That will get you past the import stage and you can then add these refs in your build.gradle (Module:app) as indicated in the Android tutorial, like below:
dependencies {
compile 'com.android.support:appcompat-v7:22.2.0'
}
Here is a simpler way to migrate:
Start off with a sample Android Studio project.
Open android studio and create a new project (or) just download a ‘sample’ studio project here: https://github.com/AppLozic/eclipse-to-android-studio-migration.
Now, open the downloaded project in Android Studio by following the below instructions.
Import eclipse project modules into Android Studio.
Select File -> New -> Import Module
Image title
Next, select the path of the eclipse project and import the modules. In case, if you see the message “Failed to sync Gradle project,” then click on “Install Build Tools and sync project…”
Now, remove the sample project modules by following the below simple steps:
Open settings.gradle and remove “include ‘:app’”
Right click on “app” module and “Delete” it.
Now, what we have is the Eclipse project open in Android studio with the Gradle build.
Here are few other links which might help you:
http://developer.android.com/sdk/installing/migrate.html
Source: http://www.applozic.com/blog/migrating-project-from-eclipse-to-studio/
Simple steps:
1.Go to Android Studio.
2.Close all open projects if any.
3.There will be an option which says import non Android Studio Projects(Eclipse ect).
4.Click on it and choose ur project
Thats't it enjoy!!!
Stop installing android studio 3.0.1 and go back 2.3.3 ( Stable version) . Check for the stable version and you can find them a lot
All you have to do uninstall and go back to the other version. Yes it asks to create gradle file seperately which is completely new to me!
Failure is the stepping stone for success..
The best way to bring in an Eclipse/ADT project is to import it directly into Android Studio. At first GO to Eclipse project & delete the project.properties file.
After that, open the Android studio Tool & import Eclipse project(Eclipse ADT, Gradle etc).
I have come across a strange error. I have an Android project that uses external libraries, in particular:
android-support-v4.jar (for Fragment support in Android 1.6)
GoogleAdMobAdsSdk-4.3.1.jar (for ads)
The project ran fine until I updated some aspects of the plugin (can't recall the specifics as I did not pay too much attention to it) and after that, whenever I try to use any class from the above .jar files (or any of its subclasses, even ones defined by me), I would get a java.lang.NoClassDefFoundError. I could not find the answer after much searching, so I am really stumped.
I believe this problem is related to how my IDE is set up and it has little to do with actual code, so I will not post any unless if it's absolutely necessary.
You need to read this - Dealing with dependencies in Android projects.
This link is also useful - ClassDefNotFoundError with ADT 17
Basically, create a folder called libs and place all of your jar files inside. The recent update will automatically take care of the rest for you. You don't need to edit your path anymore.
Android does not support Java1.7 up to now. Jars built with compliance level 1.7 cannot be used in Android Applications. Rebuild your Java project with compliance level 5.0 or 6.0 before exporting the jar file.
I found this post via google and answers above didn't solve my problem. Hope what I say will be helpful to others.
If you see NoClassDefFoundError after upgrading to ADT 22, try this in Eclipse:
Go to Project Properties → Java Build Path → Order and Export tab.
Check the Android Private Libraries option.
Also a warning to others who have updated to r17 with many dependencies. I had a another referenced project on my build path and it still did not work after following ALL the directions on this r17 issue on the internet.
Found out after an hour that my referenced project used an older version of an external Jar than my main project did. When trying to compile the main project, Eclipse would give up due to this jar version difference and I never noticed the warning message in Console.
Solution was to copy the newer version external jar file to the referenced project's libs directory.
Wow - such a productivity killer.....
I ran into this error today too, because of updating to the Android SDK, r17. What the links that #aneal pointed out do not discuss is how to handle external runtime libraries (such as those imported under their own heading - not an imported user library).
The easiest way to solve this problem is to change the build order in the build path. Simply right click on your project and select Properties. From here, select Java Build Path. At the top of the display, choose the tab order and export and move GoogleAdMobAdsSdk-4.3.1.jar above Android X (replacing x with the version you are using). Next, clean your project and run it. You should be good to go!
The way I solved it was by : Right clicking on the project and selecting build path. Select configure build path in the selections that appear. After that see if your libraries are there in the libraries folder and then select the order and export tab and over there select all your jar files. Then select ok and run your project.
If you're using Eclipse with Maven IDE (m2e) go to "Java Build Path" then "Order and Export" and finally check the item "Maven Dependencies" and pull it down to the BOTTOM of the list. You should do the same with project references in the same workspace.
Every time I setup the project in a new computer that happens.
Ever since upgrading my current projects to use the new R14 Tools in Eclipse, I'm now unable to debug any code that exists in my library projects.
When I hit a break point in my library project code, instead of Eclipse opening the original source file, it opens up the read-only copy of the source file contained within the JAR with the message "Source not found".
I've searched around for a solution to this, but have yet to come across anything. Does anybody else have any suggestions? It's quite a pain not being able to debug.
EDIT
The issue has came back and I'm no longer able to debug. I haven't changed any project settings around or anything. Very frustrating.
Tried all of the above and it did not work for me, however the workaround detailed here did.
http://code.google.com/p/android/issues/detail?id=20731
Start debugging, and run until you hit a breakpoint (and precisely get a .class file instead of the .java you would like to have)
Right click in the Debug view of the Debug perspective (for example on the call stack), and choose "Edit Source Lookup Path"
Add all your projects above "Default", via "Add..." > "Java project" > "Select All"
(I'm using ADT 15.0.2 preview from http://tools.android.com/download)
After having this issue as well and doing a little research, I came across this thread and another one that tipped me off. I was pulling my hair out already.
It turns out that the problem is with the build order of your projects (mine was anyway). Since ADT/SDK v14 changed the way library projects are referenced, the build order needs to be correct. Make sure all of the libraries your app uses are built first. I just moved the "src" and "gen" folders for each of my projects to the bottom and now it builds the library first and I am able to debug it and view the source of my library files through the main project.
In case someone doesn't know where to do this, in Eclipse, right click on your project and "Build Path" and then click "Configure Build Path". Then, on the "Order and Export" tab, move the two folders for your project to the bottom of the list below your libraries. I did this for all of my projects and the library projects.
You can also do it globally in Eclipse from Windows->Preferences->General->Workspace->Build Order and moving your library projects to the top. I think the build order defined in each project will override this though, so you may want to do it in both places to solve the issue now and for future projects.
I had the same problem in a project today. The project consists of an app which has two library dependencies. I could not see code during debugging and when using auto-completion when overriding methods Eclipse was unable to deduce proper argument names.
First of all, the problem manifested itself by showing the the 'gen' folder was used as the one that contained the source. To check whether this is the same issue go to your app project, open the Android dependencies and have a look at the properties of the your library dependencies. Location path said /libraryprojectname/gen.
If this is also your problem then go to the 'Order and Export' tab of each library project and move the 'gen' item below the 'src' item. As soon as you click OK Eclipse will work a bit and when you check the Android dependency properties the location path should say: /libraryprojectname/src. Open click the dependency and open any class inside the jar. It should show the source.
I am using ADT plugin 20.0.3 with Android SDK Tools 20.0.3 and Android SDK Platform Tools 14.
The following worked for me on Eclipse Juno:
In Project Properties/Java Build Path:
In the Projects tab, added my library projects.
In the Order and Export tab, moved my library projects to the top, and checked them
Not sure if it's relevant, but Android SDK tools is rev 20.0.3 and Android SDK platform tools is 14.
I assume you are opeining library project and there you put brakepoint.
Try this: On main project open Library Projects->[yourlibrary.jar]->[yourfile.class] from Package Explorer, and then in .class file put brakepoints.
This works for me at least :)
Sometimes this happens to me. Not sure about the reason but the way I solve is:
Remove the main project from eclipse. -- Closs Eclipse -- Delete the jar file in the library project -- Open Eclipse -- Wait for the library project to compile -- Import the main project
This problem also occurs with release 21 of ADT inside Juno. As a workaround, in the "debug" view of the debug perspective (where you see threads and method invocation traces), right click and edit source lookup path.
This is a two-part question about adding a third-party library (JAR) to an Android project in Eclipse.
The first part of the question is, when I try to add a third-party JAR (library) to my Android project I first get the problem of
Error parsing XML: unbound prefix
because I'm trying to use a class from that JAR (and need the prefix somehow defined). What's going on?
Second, (after fixing that--the answer is given below), my application doesn't work on Android and I discover via the debugger (LogCat) that the class I'm attempting to consume doesn't exist.
Caused by:
java.lang.ClassNotFoundException:
com.github.droidfu.widgets.WebImageView...
Why, when I get no compilation or linker error in Eclipse, does it have this problem on the emulator?
These two questions are rhetorical for I'm going to answer them myself below. Other posts in this forum creep up to the problem and elsewhere there is discussion, but I feel that I can be more explicitly helpful for the next guy to come along.
Now for the missing class problem.
I'm an Eclipse Java EE developer and have been in the habit for many years of adding third-party libraries via the "User Library" mechanism in Build Path. Of course, there are at least 3 ways to add a third-party library, the one I use is the most elegant, in my humble opinion.
This will not work, however, for Android, whose Dalvik "JVM" cannot handle an ordinary Java-compiled class, but must have it converted to a special format. This does not happen when you add a library in the way I'm wont to do it.
Instead, follow the (widely available) instructions for importing the third-party library, then adding it using Build Path (which makes it known to Eclipse for compilation purposes). Here is the step-by-step:
Download the library to your host
development system.
Create a new folder, libs, in
your Eclipse/Android project.
Right-click libs and choose
Import -> General -> File System,
then Next, Browse in the filesystem
to find the library's parent
directory (i.e.: where you
downloaded it to).
Click OK, then click the
directory name (not the checkbox) in
the left pane, then check the
relevant JAR in the right pane. This
puts the library into your project
(physically).
Right-click on your project,
choose Build Path -> Configure Build
Path, then click the Libraries tab,
then Add JARs..., navigate to your
new JAR in the libs directory and
add it. (This, incidentally, is the moment at which your new JAR is converted for use on Android.)
NOTE
Step 5 may not be needed, if the lib is already included in your build path. Just ensure that its existence first before adding it.
What you've done here accomplishes two things:
Includes a Dalvik-converted JAR
in your Android project.
Makes Java definitions available
to Eclipse in order to find the
third-party classes when developing (that is, compiling)
your project's source code.
Ensure that your 3rd party jars are in your projects "libs" folder and they will be put in the .apk when you package your application. You may see runtime errors on the device if something in the jar is not supported, but other than that I have had great success with this.
Setting up a Library Project
A library project is a standard Android project, so you can create a new one in the same way as you would a new application project.
When you are creating the library project, you can select any application name, package, and set other fields as needed, as shown in figure 1.
Next, set the project's properties to indicate that it is a library project:
In the Package Explorer, right-click the library project and select Properties.
In the Properties window, select the "Android" properties group at left and locate the Library properties at right.
Select the "is Library" checkbox and click Apply.
Click OK to close the Properties window.
The new project is now marked as a library project. You can begin moving source code and resources into it, as described in the sections below.
If you are using the ADT version 22, you need to check the android dependencies and android private libraries in the order&Export tab in the project build path
First, the problem of the missing prefix.
If you consume something in your layout file that comes from a third party, you may need to consume its prefix as well, something like "droidfu:" which occurs in several places in the XML construct below:
<com.github.droidfu.widgets.WebImageView android:id="#+id/webimage"
android:layout_width="75dip"
android:layout_height="75dip"
android:background="#CCC"
droidfu:autoLoad="true"
droidfu:imageUrl="http://www.android.com/images/opensourceprojec.gif"
droidfu:progressDrawable="..."
/>
This comes out of the JAR, but you'll also need to add the new "xmlns:droidfu"
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:droidfu="http://github.com/droidfu/schema"
...>
or you get the unbound prefix error. For me, this was a failure to copy and paste all of the supplied example from the third-party library's pages.
Error parsing XML: unbound prefix
Resource '/playteddy/res' does not exist.
I got the above two errors and finally I solved it.
Right click your project -> properties -> java build path -> googleadmobadsdk (select and put it top), then you run and problem solved. It is solved my runtime error.
Put the source in a folder outside yourt workspace.
Rightclick in the project-explorer, and select "Import..."
Import the project in your workspace as an Android project.
Try to build it, and make sure it is marked as a library project.
Also make sure it is build with Google API support, if not you will get compile errors.
Then, in right click on your main project in the project explorer.
Select properties, then select Android on the left.
In the library section below, click "Add"..
The mapview-balloons library should now be available to add to your project..
Go to build path in eclipse, then click order and export, then check the library/jar, and then click the up button to move it to the top of the list to compile it first.