I'm trying to learn android development and I am initially confused by the different project structures between Eclipse and Android Studio. This makes it difficult to follow tutorials designed for Eclipse. Could anyone let me know why these differences exist? Should they exist?
For instance, if I were to locate the R.java file in the two different IDEs, the paths would look like this:
Eclipse: app\gen\com.example.app\R.java
Android Studio: app\build\source\r\debug\com.example.app\R.java
Why are these paths different? Why is my R.java located in a debug folder in Android Studio? This lead to some errors early on, and if anyone has any insight into these differences I would appreciate them.
The mystery: Android Studio's Project Structure and Build System
I don't know if this is because of the Gradle Build System (I'd wager it is), but I'll tell you what I've understood so far.
Update 4: 2014/09/11 Added Cheat Sheet for BuildTypes, Flavors and Variants(I finally feel confident to write this :D)
Update 3: 2014/09/11 Updated the comparison workspaces and projects to be precise
Update 2: 2014/04/17 Added more detail to AS project structure
Update 1: 2013/07/29 Added IntelliJ Project Structure
The IntelliJ's Project structure (shown at the end) is for IntelliJ with the android plugin. The Android Studio, however, has a project structure divided like so:
Structure: Projects and Modules
module in Android Studio is like a project in Eclipse
project in Android Studio is like a workspace in Eclipse (to be precise, a workspace with interdependent projects)
From the documentation (Android Studio is based on Intellij IDEA) :
Whatever you do in IntelliJ IDEA, you do that in the context of a
project. A project is an organizational unit that represents a
complete software solution.
Your finished product may be decomposed into a series of discrete,
isolated modules, but it's a project definition that brings them
together and ties them into a greater whole.
For Android, it means one project per app, and one module per library and per test app.
There are multiple issues if you try to build multiple apps within the same project. It's possible, but if you try (like I did), you will see that almost everything is designed to work with a single app per project.
For example, there is an option to "rebuild the project", which makes no sense with multiple apps, many other project settings would be useless, and the built-in VCS system isn't great when you have multiple repositories.
Structure: Folder Structure
Top Level Folders
1. Main Project
This would be entire project context (Eclipse Land: Like your workspace but limited to what's relevant to your project). Ex: HelloWorldProject if the name of the application you gave was HelloWorld
2. .idea
This where project specific metadata is stored by Android Studio (AS). (Eclipse Land: project.properties file)
3. Project Module
This is the actual project. ex: HelloWorld if your application name you gave was HelloWorld
4. gradle
This is where the gradle build system's jar wrapper i.e. this jar is how AS communicates with gradle installed in Windows (the OS in my case).
5. External Libraries
This is not actually a folder but a place where Referenced Libraries (Eclipse Land: Referenced Libraries) are shown. Here's where the Targeted Platform is shown etc.
[Side note: This where many of us in Eclipse Land used to delete the referenced libraries and Fix Project Properties to fix reference errors, remember?]
Project Folder in Detail
This is number #3 in the above list. Has the following sub dirs
1. build
This has all the complete output of the make process i.e. classes.dex, compiled classes and resources, etc.
In the Android Studio GUI, only a few folders are shown. The important part is that your R.java is found here under build/source/<flavor>/r/<build type(optional)>/<package>/R.java
2. libs
This is the standard libs folder that you see in eclipse land too
3. src
Here, you only see the java and res folder which correspond to the src folder and res folder in Eclipse Land. This is much welcomed simplification IMHO.
Note on Modules:
Modules are like Eclipse Land projects. Here the idea is that you have one application project (Module #3 in the list above) and several library projects(as separate Modules under the global project folder (#1 in the above list)) which the application project depends on. How these library projects can be re-used in other applications, I still haven't found out.
[Side note: The whole re-organization has some benefits like simplifications in src folder, but so many complications. The complications are mainly due VERY VERY thin documentation on this new project layout.]
The New Build System
User Guide for the new Build System
Explanation of flavors and buildTypes, etc - What is the hullabaloo about?
CheatSheet for flavors and buildTypes
BuildType: debug and release are buildTypes available by default on all projects. They are for building/compiling the SAME CODE to generate different APKs. For example on release APKs you would want to run proguard(for obfuscation), sign it with your key (as against the debug key), run optimizations (maybe via proguard or other tools), use slightly different packageNames (we use com.company.product for release and com.company.product.debug for debug), etc. We also use a debug flag (BuildConfig.DEBUG) to turn off logging to logcat (since it makes the app slow) on release builds. This makes for a faster debug build during development but also an optimized release build to put on play store.
Product Flavor: There are no default flavors available (or to be precise, the default flavor is blank/nameless). Flavors could be free version or paid version where they have DIFFERENT CODE. They share the same Main Code but different versions(or no versions) of a few source code files or resources.
BuildVariant: A buildVariant is what a generated APK actually corresponds to. They are named like so (in order) Product Flavor + Build Type = Build Variant.
Example 1: if you have free and paid as two flavors. The build variants you would get are:
Free - debug
Free - release
Paid - debug
Paid - release
So that is 4 possible APK configurations. A few configurations may not make sense in a particular project, but they are available.
Example 2: (for new projects/ no flavors) You have 2 buildVariants or APKs available, since the default flavor is nameless/blank:
debug
release
Compare this with Intellij's Project Structure if that helps:
The .idea (1) folder contains a number of subfolders, mainly with internal IntelliJ IDEA information.
The src (2) folder contains the MyActivity.java (3) file source code that implements the functionality of your application. The file belongs to the com.example package.
The res (4) folder contains various visual resources.
The layout/main.xml file (5) defines the appearance of the application constituted of resources of various types.
The values folder (6) is intended for storing .xml files that describe resources of various types. Presently, the folder contains a strings.xml file with String resources definitions. As you will see from the Adding a Color section, the layout folder can also contain, for example, a descriptor of colors.
The drawable folder (7) contains images.
The gen (8) folder contains the R.java (9) file that links the visual resources and the Java source code. As you will see from the sections below, IntelliJ IDEA supports tight integration between static resources and R.java. As soon as any resources are added or removed, the corresponding classes and class fields in R.java are automatically generated or removed accordingly. The R.java file also belongs to the com.example package.
Android Studio: app\build\source\r\debug\com.example.app\R.java
Why are these paths different? Why is my R.java located in a debug folder in Android Studio? This lead to some errors early on, and if anyone has any insight into these differences I would appreciate them.
Simply put, Android Studio is configured to build a debug Build Type on your system.
Eclipse/ADT is designed to support a single build at a time (from what I can tell). One of the primary goals of the new build system (from the user guide):
Make it easy to create several variants of an application,
either for multi-apk distribution or for different flavors of an application
So where as Eclipse/ADT could generate one R.java file, Android Studio supports multiple. The generated R.java is located in the debug folder because by default the new build system supports debug and release build types off the bat. If you changed your build variant (button, lower left hand corner of AS) to release AS will generate R.java in the release directory.
This might not mean anything for simple projects, but the support of Build Variants means a drastic simplification of the build process for many developers, including the project I'm working on.
Our project supports 4 flavors with 2 build types (debug and release), to support a total of 8 different APK combinations. And each of those combinations have slightly different configurations, so this build system really worked out for us. My android studio is installed on a different machine, but if memory serves my correctly the R.java file exists in build/source/<flavor>/r/<build type>/package/R.java. When our CI server builds the APK files it uses each of these R.java files to generate separate packages.
Google Discontinue the support for the Android Developer Tools
(ADT) in Eclipse is ending, per our announcement. You should migrate
your app development projects to Android Studio as soon as possible.
For more information on transitioning to Android Studio, see Migrating
to Android Studio.
So best for Android development tool for Android Studio only for all future support of Android M ---
For android Studio 3.0.1 and selected all features:
Android O latest
Android Auto
Android things
Android wear
Android TV
C++ support
Kotlin support
The structure in version 3.0.1 does not look at all like all other answers.
Recent structure is as displayed in 2018, Android Studio 3.0.1 01/2018.
Newbie kinda found something resembling to usable in feature sub-folder:
Update your Android Studio 3.0.1 01_2018:
ToolTip:
Related
I want to move all gradle build folders to one another folder/structure outside project, is that possible?
I use Android Studio + Gradle. It’s android multi module project, so there is a bunch of build folders:
project/.gradle (optional to move)
project/build
project/module1/build
project/module2/build
project/module3/build
What I want to do is move all this (cache/temp) folders to different location outside of project.
I expected, that I will set buildDir=Z:/build/ in my global gradle.properties (and something in project based local.properties what will identify project) and it will create same structure as in project folder on my Z:/ drive inside build folder, but it didn’t and build failed.
I think, that it try to create all modules + main build folder inside one folder (all together and some files are rewritten by modules), so it fails to build.
What is my goal? Move all temp/cache files to different hard drive or ramdisk (for all project, because I work on more projects at ± same time). Reasons for it is 1) speed of storage (ramdisk in my case is 20x faster than my SSD in laptop) and 2) Lifetime of primary SSD. I don’t see a reason why I should use primary SSD for infinite writing of tons of temp files when it can be stored on some SSD/Ramdisk allocated just for builds/cache/temp files.
My goal is structure like:
Z:\build\projectX\build
Z:\build\projectX\module1\build
Z:\build\projectX\module2\build
Z:\build\projectY\build
Z:\build\projectY\module1\build
Z:\build\projectY\module2\build
In worst case share same folder:
Z:\build\build
Z:\build\module1\build
Z:\build\module2\build
Preferred to not modify build.gradle files, because it's shared between more devs and other devs will not want to do same local changes as me. Location of build folder I expect should be just local change (same as on CI we don't want to move this folders anywhere)
Same question on Gradle forum
EDIT1:
Using buildDir=Z\:/build/ in gradle.properties file in project can work, but only for monolitical projects without modules (only one app module), with modules it fails on Duplicating content roots detected
So, Z:\build\ contains content of /project/app/build/, when it's multimodule project it mixing content from all modules build folders into one same folder and breaks build.
I've never made a program into an executable before, and I've been looking into how to do this for some time now. When I try to put it into a jar everything works fine but when I try to run it nothing happens.
How do I make my game into an executable so it can be run (on windows, not android)
I feel like I am not Linking it to the libraries or something... Not sure.
Thanks!
Edit:
I should add I get the error
JAR export finished with warnings. See details for additional information.
duplicate entry: com/badlogic/gdx/utils/arial-15.fnt
duplicate entry: com/badlogic/gdx/utils/arial-15.fnt
duplicate entry: com/badlogic/gdx/utils/arial-15.png
duplicate entry: com/badlogic/gdx/utils/arial-15.png
Jar export finished with problems.
See details for additional information.
Your problem is that when you use eclipse export as Executable jar file it does not include the assets (graphical, sounds ...) that you used in your gdx project. What you can do manually is either copy your assets folder right next to the generated jar file or include your assets folder in your jar file with your favorite zip management tool.
Another way would be to use this same eclipse export wizard and check "Save as ANT script" and then edit the generated ant file to include all the files and folders needed by your app.
Hope this helps
This is an old question, but if you are using a new version of LibGDX and Gradle you can use the command line to make an executable.
There are several commands, but these are for packaging:
Desktop
gradlew desktop:dist
Android (unsigned)
gradlew android:assembleRelease
iOS
gradlew ios:createIPA
Web
gradlew html:dist
Read more at https://github.com/libgdx/libgdx/wiki/Gradle-on-the-Commandline
I'm assuming your application is setup as the libgdx wiki page suggests (with a "main project" and separate "desktop" and "android" projects that share the sources from the "main" project).
Since your app is written in Java, it requires a JVM to run on a desktop. You have to decide if you want to package that up, or rely on a JVM already being installed by the user. I believe packaging up the JVM with Java class files is very complicated and raises a host of other issues (and it becomes very platform specific). So, I believe most libgdx-based games get distributed as an executable Jar file, which means the user must already have Java. (It works for Minecraft, so its probably good enough for you, too. :)
Eclipse makes that really easy: File -> Export ... -> Java -> Executable Jar File. There may be additional steps required to include assets like your app's images and sounds into this .jar file. (My game is currently "asset free", so I don't have any experience with this part.)
You might also consider side-stepping the desktop executable, and packaging your game as an applet and running it in a web browser so there is very little "installation" required by the folks you want to show it to. Here's a walkthrough for making an applet from a libgdx-based game. (I haven't actually tried this myself yet, but I do have a libgdx-based game that I'm planning on doing this for.)
If you're using Android Studio, you can create a custom configuration to distribute from within the program.
On the Run dropdown list select edit configurations.
Click the "+". Select Gradle.
On the right half of that screen give your configuration a Name.
Gradle Project: Use the browse button to select your desktop application. This will look something like (project name):desktop
Tasks: type "desktop:dist"
Apply.
Close the configuration editor and select your new configuration from the dropdown. Hit run and it should build your project.
Your new Jar file should be located in (ProjectName)/desktop/build/libs
After updating to ADT 14/15 I started having a couple problems with our build.
With one Android based libraries (call it Framework) which is added into the actual android project app (call it App). The Framework project has a couple jar files in its own lib folder which is added to its own build path. Those same jar files are required to be added to the App's build path as well.
So jar files on the Framework build path
Framework/libs roboguice
Framework/libs gson
Those same jar files on the App build path
Framework/libs roboguice
Framework/libs gson
Also the Framework.apk is added via the Android Library panel in the App's project properties.
Both projects are targeting the same Android.
Now when I build the project I seem to have resolved the errors however when running it, at times I receive the Missing Framework.apk in the console window.
So based on this scenario any thoughts on how to correct this build? I have a feeling its still setup incorrectly.
This should help you out!
http://android-developers.blogspot.com/2011/10/changes-to-library-projects-in-android.html
I noticed that when I convert an existing Android Application project to an Android Library project by checking the "is Library" checkbox, nothing changes in the project's source code or XML files.
So what really happens when the "is Library" checkbox is checked? What changes internally, in the package and/or project files? Where can I learn more about this?
To better explain my question:
What I am interested to know (mainly
for troubleshooting purposes) is
what differentiates an Application package from a Library
package "under the cover"?
Is the fact that a project is
"Library Project" marked
somewhere? If so, where does it
mark it (obviously not in the source
files and not even in the res XML
files)
From the Managing Projects from the Command Line page:
The create lib-project command creates
a standard project structure that
includes preset property that
indicates to the build system that the
project is a library. It does this by
adding this line to the project's
default.properties file:
android.library=true
In other words, it's a property that is utilized by the build system and not by the operating system.
UPDATE: I'm on my iPhone so I won't type out a whole paraphrase, but here's a pretty good blog article discussing the differences between a Java JAR and an Android Library Project, including how the dex tools add the resources and dex code to the .apk:
http://devmaze.wordpress.com/2011/05/22/android-application-android-libraries-and-jar-libraries/
From the devsite: http://developer.android.com/guide/developing/projects/projects-eclipse.html
You can also designate an Android
project as a library project, which
allows it to be shared with other
projects that depend on it. Once an
Android project is designated as a
library project, it cannot be
installed onto a device.
A library project isn't packaged as a seperate redistributable file as you're used to with a jar. It's merged with the the apk file of your application.
The page you linked to mentions it in the Referencing a library project section.
As soon as the Properties dialog closes, Eclipse rebuilds the project, including the contents of the library project.
I am a C# developer and getting started with Android. I am attempting to duplicate a couple applications I already have in VS. The project is made of 2 executables and 1 common assembly. The 2 executables contain the application specific logic while the common contains centralized forms and logic (such as login form). I am using Eclipse. So how can I accomplish this layout?
Thanks
In Eclipse, with your project selected in the Navigation or Package Explorer view:
Project -> Properties -> Java Build Path
Here you can add references to Libraries (jar files which I believe are similar in concept to C# assemblies) or other projects you have open in Eclipse.
So create as many projects in Eclipse as you want for your application's layout, and in the main Android project (the one where your application's Manifest file exists) reference those other projects, or the jar files you exported from those projects, in the Java Build Path.