在Android Studio中使用"导入项目"来创建用于更改项目结构和生成Gradle文件的Eclipse项目,但是现在(我使用的是AS 0.5.3)它只生成IDEA文件(.iml,.idea)但不是Gradle,它也没有触及文件结构.
如何将Eclipse项目导入Android Studio？
更新:尝试在Eclipse中导出gradle文件不会为应用程序导出它们,它也不会在Android Studio中显示为模块.
在较新版本的Android Studio中,引入Eclipse/ADT项目的最佳方法是将其直接导入Android Studio; 我们曾建议您首先将它从Eclipse导出到Gradle,但我们还没有经常更新ADT以跟上Android Studio的步伐.
无论如何,如果您在启动Android Studio时从"文件"菜单或"欢迎"屏幕中选择"导入项目",它将引导您完成一个专门的向导,该向导将提示您打算将文件复制到新的目录结构中而不是就地导入它们,它将提供修复一些常见的东西,如将依赖项转换为Maven样式包含等.
看起来你并没有得到这种专业化的流程.我认为它可能无法将您导入的项目识别为ADT项目,并且它违反了旧的内置IntelliJ行为,该行为不了解Gradle.要使专门的导入工作,必须满足以下条件:
您导入的项目的根目录必须具有AndroidManifest.xml文件.
或者:
根目录必须包含Eclipse中的.project和.classpath文件
要么
根目录必须包含res和src目录.
如果您的项目很复杂,或许您没有将其指向要查看导入成功的根目录.
将Eclipse ADT插件更新到22.0或更高版本,然后转到File | 出口
现在转到Android然后单击Generate Gradle build files,然后它将为您生成gradle文件.
选择要导出的项目
点击立即完成
在Android Studio中,关闭当前打开的所有项目.您应该会看到"欢迎使用Android Studio"窗口.
单击导入项目.
找到从Eclipse导出的项目,展开它,选择它并单击"确定".
尝试以下步骤:1-单击Import project(Eclipse,ADT,...)
2-选择Eclipse项目的主目录
3-保留默认值.前两个选项是将jar文件更改为远程库(依赖项).这意味着在构建Android studio时尝试在本地系统或远程存储库中查找库.最后一个选项是导入后仅显示一个文件夹作为应用程序.
4-然后,您将看到更改摘要
5-然后,如果您看到Gradle项目同步失败,您应该转到项目视图(左上角).然后,您应该转到project-> app并打开build.gradle.
6-然后,您应该将compilesdkVersion和targetsdkVersion更改为您在buildToolsVersion中看到的当前版本(我的是23).例如,在我的项目中,我应该在两个地方改变17到23
7-如果在依赖项中看到错误,则应更改其版本.例如,在我的项目中,我需要检查我正在使用的android支持库版本.所以,我打开SDK管理器并转到底部查看版本.然后,我应该用我当前的版本替换我的Android工作室版本,然后从右上角再次单击"尝试"
我希望它有所帮助.
它在Android Studio中变得更简单您只需先选择即可
导入项目(eclipse .....)
然后选择你的文件夹基于eclipse的项目.如下所示
3.根据您使用的项目类型和库(ActionBarSherlock),您可能会提示特殊的导入向导,所以继续点击下一步然后完成.在这种情况下,它很简单
你完成了.
但有时调试或运行选项不起作用,错误消息显示如
"这个项目结构不是基于gradle或将其迁移到gradle"
要解决这个问题,关闭打开的eclipse项目并通过与导入项目(eclipse adt,gradle等)之前相同的过程重新打开相同的项目)这次android studio将添加所有必要的gradle文件和绿色调试选项也将起作用.我不小心做了这件事,但它确实有效,我希望它对你也有效.
自从发布此问题以来,Android Studio已得到改进,最新版本的Android Studio(截至本文撰写时,我们的版本为2.1.1)具有相当不错的Eclipse导入功能,因此将Eclipse项目直接导入Android Studio现在是最好的将项目从Eclipse迁移到Android Studio的方法.
我将在下面描述如何执行此操作,包括可能遇到的一些陷阱.我将特别介绍导入包含多个共享一个或多个项目库的应用程序的Eclipse工作区(到目前为止发布的方法似乎仅限于导入一个Eclipse应用程序项目及其项目库).虽然我没有处理所有可能的问题,但我会详细介绍其中的一些问题,我希望这些问题对于第一次自己完成此过程的人有所帮助.
我最近从Eclipse工作区导入了项目.该工作区包括四个库项目,每个库项目最多由九个项目共享.
一些背景:
Eclipse工作区包含多个项目,可能是库项目或应用程序.
Android Studio 项目类似于Eclipse 工作区,因为它可以包含库项目和应用程序.但是,库项目或应用程序由Android Studio中的"模块"表示,而它在Eclipse中由"项目"表示.
总而言之:Eclipse工作区将最终作为Android Studio项目,而工作区内的Eclipse项目最终将作为项目内的Android Studio模块.
您应该通过创建Android Studio项目(文件/新建/新项目)来启动导入过程.您可以为此项目提供与Eclipse工作区相同(或类似)的名称.该项目最终将包含您将导入的每个Eclipse项目(包括项目库)的所有模块.
导入过程不会更改原始Eclipse文件,只要将导入的文件放在不同的文件夹层次结构中,就应该为此项目选择一个不在原始Eclipse层次结构中的文件夹.例如,如果您的Eclipse项目都在一个名为Android的文件夹中,您可能会创建一个名为AStudio的兄弟文件夹.
然后,您的Android Studio项目可以创建为此新文件夹的子文件夹."新建项目"向导将提示您输入此顶级项目文件夹,该文件夹将在其中创建项目.
然后,Android Studio的新项目向导将要求您在创建项目时配置单个模块.起初这可能有点令人困惑,因为他们实际上从未告诉过你正在创建一个模块,但是你是; 您正在创建一个包含单个模块的项目.显然,每个项目都需要至少有一个模块,因此,由于您依靠Eclipse来提供模块,因此您的初始模块将是一个空置满足该正式需求的占位符.
因此,您可能希望为项目创建尽可能少的初始模块.因此,选择手机和平板电脑作为模块的类型,接受默认的最低SDK(API级别8),然后为您的模块选择添加无活动.
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.
当系统提示您输入源文件夹时,您应该输入Eclipse项目的文件夹(这是包含该项目的AndroidManifest.xml文件的文件夹).
然后导入向导将显示它打算创建的模块名称(类似于原始Eclipse项目的名称,但是使用小写的第一个字母,因为这是一个区分模块名称和项目名称的约定(从上层开始)大小写).通常可以接受此默认值.
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 - 默认情况下已选中.在这种情况下,您应该取消选中此框,以便导入程序将新导入的模块连接到已导入的库.可能接受Android Studio为您的模块创建的默认名称对于允许IDE查找和重用这些库模块非常重要.
接下来,导入器将提供用Gradle依赖项替换任何jar和库源,并为任何依赖模块创建camelCase模块名称,默认情况下检查所有这些选项.您通常应该选中这些选项并继续.但是,请阅读有关可能出现的问题的警告.请记住,您始终可以删除导入的模块(通过"项目结构"对话框)并重新开始导入过程.
我得到的下一个显示(YMMV)声称我的SDK安装中没有安装Android支持存储库.它提供了一个用于打开Android SDK Manager的按钮,用于安装它.但是,那个按钮对我不起作用.我手动将SDK管理器作为单独的应用程序打开,发现已经安装了Android支持存储库.然而,有一个更新.我安装了它,并在导入对话框中点击了"刷新"按钮,但没有做任何事情.所以,我继续进行,并且认为缺少此存储库似乎并没有损害导入过程(尽管我确实得到了有关它在以后不时丢失的消息,同时使用导入的代码,我能够安抚通过单击提供的更正问题的链接 - 至少是暂时的).
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:
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.
京公网安备 11010802040832号 | 京ICP备19059560号-6 