When i first created android project , project.properties file has been generated.
It contains the information about target-platform and dependencies.
I deleted that file and tried to run my project , My Project runs without errors.
So,
what is the use of project.properties file.
It has been mentioned in the comment that "This file should be checked in "Version Control Systems". why ?
As per Docs:
project.properties
This file contains project settings, such as the build target. This file is integral to the project, so maintain it in a source revision control system. To edit project properties in Eclipse, right-click the project folder and select Properties.
I contains all the versions details of your application like minimum version,target version details , library details whichever you are adding in your project. Your applications target version etc. If you modify this file directly it will reflect to your overall project.
Related
I use them often when configuring my project but mostly add snippers as instructed. I have absolutely no clue which file is for what exactly. Can anyone give a clear picture what each file is for.
So far I think
local.properties for environment paths like sdk/ndk location
settings.gradle for including all modules in project where each module has it's own build.gradle
gradle.properties ?
gradle-wrapper.properties ?
gradle.properties
Using gradle.properties to create universal variables
This solution is limited to Android projects as far as I know. In /gradle.properties you can define your universal or project level variables as such: Link
myBuildToolsVersion=20.0.0
myMinSdkVersion=10
myTargetSdkVersion=22
myCompileSdkVersion=22
gradle-wrapper.properties
Internally, Android Studio uses the version of Gradle that is defined in the wrapper configuration. That configuration can be found in gradle/wrapper/gradle-wrapper.properties. When Google decides that it is time to use a new version of Gradle, Android Studio will display a message nudging you to upgrade. All you need to do then is click the message and Android Studio will edit the properties file and synchronize the Gradle installation for you. Link
local.properties
The local.properties file goes in the project's root level.
This file should not be included in source control. After (incorrectly) including this in source control, then deleting the file locally, Android Studio re-created the file for me automatically.
Here is the example content of this file:
## This file is automatically generated by Android Studio.
# Do not modify this file -- YOUR CHANGES WILL BE ERASED!
#
# This file must *NOT* be checked into Version Control Systems,
# as it contains information specific to your local configuration.
#
# Location of the SDK. This is only used by Gradle.
# For customization when using a Version Control System, please read the
# header note.
#Thu Aug 14 14:49:26 PDT 2014
sdk.dir=C\:\\Program Files (x86)\\Android\\android-studio\\sdk
Note the sdk.dir= reference to the location of the Android Studio SDK installation (which may be different on different machines).
Link
settings.gradle
':lib' is a logical project path, which gets mapped to a physical path based on information provided in settings.gradle.
A multi-project build can have an arbitrary directory structure, which is configured in settings.gradle. No need to move directories around, unless you want to. Link
For more and more info about gradle you need to check below links which help you more know about gradle and gradle system. Gradle makes developer life easy for not taking to much headache about library updation , apk generation , import lib easily , product flavors and many more.
http://www.vogella.com/tutorials/Gradle/article.html
https://developer.android.com/studio/build/gradle-tips.html
Gradle includes two properties files, located in your root project directory, that you can use to specify settings for the Gradle build toolkit itself:
gradle.properties
This is where you can configure project-wide Gradle settings, such as the Gradle daemon's maximum heap size.
local.properties
Configures local environment properties for the build system, such as the path to the SDK installation. Because the content of this file is automatically generated by Android Studio and is specific to the local developer environment, you should not modify this file manually or check it into your version control system.
I'm using ActionBarSherlock as a library. We haven't included ABS into our repository so everyone participating our project must download and install it separately. ActioBarSherlock is an Android library project and I have got it running by opening it and my project in the same Eclipse's workspace (neither of those are copied into workspace, they both exists in another folder) and adding it into my project.properties by following this:
Referencing a library project.
That reference path is relative and since everyone might have ABS in different folder, we also have different paths in Eclipse's project.properties file as android.library.reference.1. Is there any way locally override that library path so that we can have project.properties in our repo but Eclipse will use locally some other path? Currently I have to manually fix that path after every time I pull from our repo because of different paths.
There exists other *.properties files but Eclipse ignores them:
local.properties
Customizable computer-specific properties for the build system. If you use Ant to build the project, this contains the path to the SDK installation. Because the content of the file is specific to the local installation of the SDK, the local.properties should not be maintained in a source revision control system. If you use Eclipse, this file is not used.
ant.properties
Customizable properties for the build system. You can edit this file to override default build settings used by Ant and also provide the location of your keystore and key alias so that the build tools can sign your application when building in release mode. This file is integral to the project, so maintain it in a source revision control system. If you use Eclipse, this file is not used.
Just have each person put it in projectroot/libs. The newer (ADT 17 and above, IIRC) versions of the ADT will automatically pick it up and compile it into your app. Note that the folder is libs, with an s, and not lib. Using /lib won't work.
Options:
project.properties: You could create a link in every users home folder, libs and have the path in the project.properties refer to ~/libs
Using a common library:
Create a library project called "common". In settings, have it export the jar. In your Android application, import the jar.
Personally I think configuring with maven would be best but the 2nd option was quickest.
What about if you ignore the project.properties in your repo? That way each user can keep their own and you won't need to override it all the time. I don't think you can override that locally.
Another option to simplify things is you can export the project as a JAR file instead of referencing it as a library project. If you don't need to modify ABS code you can right click the project -> java -> jar file and all the developers can keep that in the same place for the sake of simplicity.
Edit: This question is no longer needed for our project since we moved from Eclipse to Android Studio and Gradle build system. Eclipse with Maven should have worked too, as #bgs suggested.
Our previous approach:
Still looking for better alternative but so far we ended up keeping project.properties in our repo. project.properties does not get overridden if there is no changes to it when pulling. We also suggest in our README that users add this
[alias]
commit = commit -X project.properties
to their .hg/hgrc configuration file to prevent accidentally commiting changes of that file.
This method has at least one drawback: When merging, you might get error like this abort: cannot partially commit a merge (do not specify files or patterns) even when you commit your merge with hg commit -m 'merge'. If this happens, disable that alias temporarily.
I deleted a jar from my libs file and now I cannot build the project and the jar will not go away.
I've tried cleaning the project, fixing the android properties now I'm stuck.
Has anyone else had this problem?
Description Resource Path Location Type
Archive for required library: 'C:/apps/APP/libs/imagecrop.jar' in project 'APP' cannot be read or is not a valid ZIP file APP Build path Build Path Problem
Solution.
Don't use clean or "fix project properties"
Simply right click on the project and press "Refresh"..
You need to remove it from your build path. Right click your project, go to Properties->Build Path. The build path contains four tabs:
The Java Build Path properties page contains four tabs:
Source. The source and output folders. If you initially create a project without separate source and output folders, you can change it here. Multiple source folders can be used in one project; e.g., to separate application source code from unit tests.
Projects. Check-off other projects in the workspace whose output folders should be added to this build path.
Libraries. Location of other archive files required by this project.
Order and Export. Order in which projects and libraries appear in the build path and the default runtime classpath; e.g., use classes from a workspace project before using the same classes from an archive library.
Go to libraries tab and remove the jar file you deleted.
Also refresh your project by right click -> Refresh so it will realize you deleted jar file.
I stumbled across something I can't figure out myself.
I have an android project with a reference to a library project. Now, the weird thing is that it seems like my default.properties file is no longer needed. Android creates a project.properties file. So my questions is: what is the difference between the two? Isn't a project.properties file standard java and default.properties android specific? What do they do exactly?
I believe you've got an issue where (some of) your project files have become obsolete after an update to a newer Android SDK.
Run this command in your project directory (you'll need to have ${ANDROID_HOME}/tools in your path):
android update project -p .
It will output something similar to (As of SDK 15):
Updated and renamed default.properties to project.properties
Updated local.properties
No project name specified, using Activity name 'MainActivity'. If you wish to change it, edit the first line of build.xml.
Added file ./build.xml
Updated file ./proguard.cfg
My guess is that the Android team decided to become more standardized and to do away with their own deviations from standards.
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.