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.
Related
I want to use the ${sdk.dir} variable in my project.properties file, so I can check this into version control and use the same file on different setup machines.
My working setup looks like this:
My project.properties:
target=android-18
android.library.reference.1=..\\..\\..\\sdk\\extras\\android\\support\\v7\\appcompat
android.library.reference.2=..\\..\\..\\sdk\\extras\\google\\google_play_services\\libproject\\google-play-services_lib
My local.properties:
sdk.dir=C:\\adt-bundle-windows-x86_64-20130917\\sdk
this setup compiles with ant from the command line. but when I replace the ..\\..\\..\\with ${sdk.dir} I get the error:
project.properties how I want it to use:
target=android-18
android.library.reference.1=${sdk.dir}\\extras\\android\\support\\v7\\appcompat
android.library.reference.2=${sdk.dir}\\extras\\google\\google_play_services\\libproject\\google-play-services_lib
results in:
BUILD FAILED
C:\adt-bundle-windows-x86_64-20130917\sdk\tools\ant\build.xml:460:
Failed to resolve library path:
C:\adt-bundle-windows-x86_64-20130917\sdk\extras\android\support\v7\appcompat
so the variable ${sdk.dir} is replaced correctly but somehow it cannot be resolved. Any ideas?
update Edit
Using the Variable for the proGuard setup in the same file (project.properties) is working fine what so ever:
proguard.config=${sdk.dir}/tools/proguard/proguard-android.txt:proguard-project.txt
This doesn't solve your issue, per se, but I hope it will help you.
My issue was that I needed to reference the Google Play Services SDK as a library in my project. However, our app is built automatically on a separate box using Ant.
I found that library projects cannot be referenced using absolute paths; they must be relative to your project, as explained here:
Library project storage location
There are no specific requirements on where you should store a library project, relative to a dependent application project, as long as the application project can reference the library project by a relative link. What is important is that the main project can reference the library project through a relative link.
I used the ant.properties file to set the android.library.reference.1=../../../../Program Files/Android/android-sdk/Android/android-sdk/extras/google/google_play_services/libproject/google-play-services_lib library. This reference is solely for the build server and this path is relative to the library location on the build server.
For development, I use Eclipse. So, the library's relative path is referenced using the project.properties file and is relative to my development box. This means that whenever I trigger a build on the server (which uses Ant), the reference in the ant.properties is used as opposed to the project.properties file.
The ant.properties file is lower level and therefore will override anything written in the project.properties/local.properties files.
As you can see this is not the answer I am sure you're looking for, but it is a limitation of Ant. My final bit of advice is that you move away from Ant and use Gradle.
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 was asked to crate a simple app for android. The first one in fact that I'll be paid for, so I really don't want to screw it up :). One of the requirements was that the code must be obfuscated.
I learned the general idea of obfuscating, but I don't want to make any silly mistakes.
What precisely do I have to do to make the code obfuscated? Does exporting it as release do the job, or some other steps are required? Any remarks are also appreciated.
PS. I'm using Eclipse if it matters.
EDIT
From the article suggested in the anwsers:
To enable ProGuard so that it runs as part of an Ant or Eclipse build,
set the proguard.config property in the
/project.properties file. The path can be an absolute
path or a path relative to the project's root.
If you left the proguard.cfg file in its default location (the
project's root directory), you can specify its location like this:
proguard.config=proguard.cfg
I indeed have the project.properties file in my project's dir. But I don't have the proguard.cfg file. Instead I have the proguard-project.txt file. I guess it's a replacement.
project.properties:
This file is automatically generated by Android Tools.
Do not modify this file -- YOUR CHANGES WILL BE ERASED!
This file must be checked in Version Control Systems.
To customize properties used by the Ant build system edit
"ant.properties", and override values to adapt the script to your
project structure.
To enable ProGuard to shrink and obfuscate your code, uncomment this (available properties: sdk.dir, user.home):
proguard.config=${sdk.dir}\tools\proguard\proguard-android.txt:proguard-project.txt
Project target.
target=android-7
Originally everything but the last line is commented out.
In proguard-project.txt everything is commented out.
I guess I'm lost here, so I'd be very thankful If somebody could tell me step by step what I am supposed to do and also how to check if it actually works.
The article on the official dev site is out of date. Starting with SDK Tools r17 they changed the way the ProGuard configuration works. Basically they split what used to be proguard.cfg into two files (and also simply made them .txt files): proguard-android.txt and proguard-project.txt. proguard-android.txt resides in your {SDK dir}\tools\proguard directory and proguard-project.txt is in each of your project directories.
They split the file so that general configuration/flags that the Android team deems pretty standard will be in the proguard-android.txt file and can be updated (basically silently) with each SDK Tools revision. And then any developer/project specific flags, the developer can add to the proguard-project.txt file.
This is why you noticed everything in your proguard-project.txt file was commented out, because in general most people don't have any project specific needs, they just want to run ProGuard with standard settings and be done with it.
For reference (a very good explanation): http://tools.android.com/recent/proguardimprovements
Step-by-Step (day by day :P)
(Using Eclipse IDE) To enable ProGuard and it's shrinking and obfuscation using only the default settings:
First update your SDK Tools to newest (r19 at time of writing)
In project.properties uncomment the line that says:
proguard.config=${sdk.dir}\tools\proguard\proguard-android.txt:proguard-project.txt
If you created the project before r17 then you might not see the same things. If that's the case I suggest you create a new dummy project (after updating SDK Tools) and just copy over the proguard-project.txt and project.properties files.
That's it! ProGuard will now be enabled and it will run, but only on release builds (when you use Android Tools and export a signed/unsigned apk).
When you make a release build you'll notice that a new ProGuard folder will be created in your project folder. Within this folder you find four files with stuff like what classes/methods were kept or removed. Also note that when you obfuscate, you'll also obfuscate your stacktraces in the event of errors.
Edit: (9/4/12) Just wanted to update this answer to reflect changes in Tools r20.
The Android team has now added one additional proguard configuration file. It is proguard-android-optimize.txt and it also resides in the {SDK dir}\tools\proguard directory. This file is the same as the original proguard-android.txt config file, except it has proguard optimization turned on.
This additional file was added for convenience for those who wanted to turn on optimizations (maybe so they can do stuff like strip out Log calls, which requires optimizations be turned on). Now you can simply point to this file instead in your project.properties file like so:
proguard.config=${sdk.dir}\tools\proguard\proguard-android-optimize.txt:proguard-project.txt
As before, don't try to alter any of the proguard-android... config files. Any project specific flags should go in the proguard-project.txt file in your project folder.
I maintain an Android app and am not using Eclipse. I am not using Eclipse. I am using ant and build.xml and build.properties.
I have places my .jar file into the libs/ directory. My code compiles just dandy. But when I run it on the emulator, the output APK does not include the .jar, so I get a runtime stacktrace:
ERROR/AndroidRuntime(470): java.lang.NoClassDefFoundError: com.google.ads.AdView
my build.properties looks like this:
jar.libs.dir=libs
And the libs/ directory contains my .jar file.
What needs to be in build.xml so that the external .jar file is included in the APK?
Edit: In theory this answer should work, but it doesn't for me. Is it out of date? What gives? How to add external jar libraries to an android project from the command line
I just came over a similar problem and noticed that libraries should not be placed in "myprojectdir\lib". When I moved them to "myprojectdir\libs" everything started to work.
It turns out that I needed to upgrade the version of ant I was using to 1.8. During the compile process, I had been getting this error message:
Warning: Reference out.dex.jar.input.ref has not been set at runtime,
but was found duringbuild file parsing, attempting to resolve. Future
versions of Ant may support referencing ids defined in non-executed
targets.
I googled it, and found that I needed to upgrade Ant, and now I don't get this warning, and my application does not force close.
What needs to be in build.xml so that the external .jar file is included in the APK?
Just putting it in libs/ is sufficient.
my build.properties looks like this:
That line should not be necessary. It does not appear in my build.properties files that build successfully with JAR files.
If you use dexdump -f classes.dex from your project's bin/ directory, you will be able to determine whether com.google.ads.AdView made it in there. If it did not, then something is strange with your build scripts. If it did, then perhaps there is a dependent JAR that you are missing (though I would expect a VerifyError in that case).
You use 3rd party library, but you seem didn't run DX on it. Make sure that not only your code processed by DX tool (I assume Ant does it), but also all 3rd party libraries you use. You can look in 7Bee script I use to convert web applications to Android davlik format, so it can work for you too. You can find more about the script on Atjeews page.
Solution:
right click on the project in project tree and select Project
properties
select Java Build Path
select TAB Order
and Export
check GoogleAdMobAdsSdk-4.0.4.jar (or your
version SDK)
press OK
clean project by menu Project
-> Clean
rebuild project (Project – Build Automatically)
Is R.java file generated by Android SDK on each compile or only when new resources are added using Eclipse? Do I need to put it under version control or not?
The R.java file is generated during resource compilation by aapt tool. You shouldn't add it to source control system.
Also, you should have noted the gen folder where R.java is placed. Your version control system should ignore this folder altogether, not only R.java file inside it. Because this folder is deleted on clean build (not sure about eclipse, but ant script definitely deletes it).
When using Git to control Android projects I add
bin/*
gen/
to .gitignore
You don't need to put it under version control. I think it's on each compile, one every new resource or clean up project.. but need to test to be sure.
I have had projects with R in and out of source control. Both worked.
When the android SDK is loaded into eclipse, it will automatically generate the R.java file. In older versions of the adt, having an incorrect R.java file would give an error, but I believe this is fixed now, and it shouldn't matter either way. If you have the choice though, avoid checking it in.
I would add it to svn:ignore.