I have two Android projects, one shared library and the app. Now I want to compile the app with dependency to the library. In Eclipse, it works very well. After that, I upload it via git to my repository and trigger Jenkins to build both projects.
My problem is, that the error occurs: "sdk/android-sdk-linux/tools/ant/build.xml:440: ../shared-lib resolve to a path with no project.properties file for project". That's clear, because in Jenkins the jobs are stored different than under Eclipse.
Another problem is, that Eclipse compiled the shared to ".jar" and Ant compiled it to "classes.jar" (is named in sdk/android-sdk-linux/tools/ant/build.xml).
Ant scripts should allow you to include whatever files you need. In your case I will suggest you move the reference to the shared-lib to local.properties file (this file should also be read by the ant script generated by update-project. Keep the adequate path for jenkins in the repository and modify the file locally for the local built. In the file in the repository you will need to have something like:
android.library.reference.1=../classes.jar
EDIT By the way the suggestion of the second properties file is just because this file is really meant to store location-specific properties.
I fixed it with copy files. The first project builds my shared-lib.jar. The other projects (phone and tablet) copy this file (shared-lib.jar) to there libs-folder and build correctly. But now I have different projects.propertieson the server and my dev-client. This one is not checked in into git.
Related
if I have a project with many library projects linked, could I improve build performances by packaging each of them in an AAR and including it in the main project ? Or this will not make any difference since that when the compiler need to assemble the apk it need to package everything together anyway?
Thanks to any one who will give me some clarifcation about performance differences between the 2 approach
I don't think you will save any build time by wrapping an existing .jar file into a .aar file and using that instead of the original .jar file.
As this SO post notes, .aar files are basically just zip files which may contain a jar file and some android resources.
Also, because .aar files are not precompiled into Dalvik byte code, the build process for your apk file must still carry out that step at least once. So, you won't save dexing time just by wrapping the .jar file into a .aar file either.
If you build a typical Android Studio project (with some Android library dependencies specified in the gradle build file) you can see the directory underneath app/build/intermediates/exploded-aar where these files have been unzipped. That work must still be done by your build machine even though you are using a .aar file.
Finally, as you pointed out, the .apk packaging work must still be done at the end of the build.
I believe the Library projects (which you are using) is the best way to go because of two reasons:
The library project gives the direct access to the code base of the libraries which can be compiled and packaged together with the main app code
In case, multiple .aar files are referenced within the project, then during the apk creation the unpacking, merging of resources and Manifest file will increase the build time.
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 am trying to add SQLCipher to my project. I am able to link the jar files to the project but there is problem linking the .so files provided.
Due to that I am getting UnSatisfiedLinkError when i try to open the DB.
Can anyone please let me know the best possible way to add .so files to the project and get it running.
In addition to jar files you need to include .so files. In my project I have:
jar files in project_root/libs/
.so files in project_root/libs/armeabi/
Also make sure that you have added the .jar files properly. Go to Project Properties -> Java Build Path -> Libraries tab make sure commonc-codec.jar, gueva-r09.jar, sqlcipher.jar are added there.
EDIT
1) Add a single sqlcipher.jar and a few .so’s to the application libs directory
2) Update the import path from android.database.sqlite.* to info.guardianproject.database.sqlite.* in any source files that reference it. The original android.database.Cursor can still be used unchanged.
3) Init the database in onCreate() and pass a variable argument to the open database method with a password*:
SQLiteDatabase.loadLibs(this); //first init the db libraries with the context
SQLiteOpenHelper.getWritableDatabase(“thisismysecret”):
Can you use the adb shell command to verify what files are being deployed to your simulator after it has been unpacked. I have seen an issue where the .so files are not packaged up in the .apk file before, which is due to the IDE not pointing to the correct native library path for your application.
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)
I have an existing project that builds fine using my IDE. I'd like to use the "android update" command to generate an ant buildfile for this project.
The buildfile is generated fine, but the build fails because it's not building with some jarfiles I have in my libs directory.
I'd like to figure out the proper way to tell ant to build with some external jar files in my libs directory. How should I do this? Is it a property in build.properties? Do I need to modify build.xml somehow? Or is there a different solution entirely?
but the build fails because it's not
building with some jarfiles I have in
my libs directory.
And your error message is...what? I suspect you may be misinterpreting the error message.
I'd like to figure out the proper way
to tell ant to build with some
external jar files in my libs
directory. How should I do this?
Just put them in libs/, as Ant will add everything in there to your build path. See this project, and this project, and this project for examples.
I spent some time trying to get the Facebook API to work with ant. The trick for me was to add this to my default.properties files.
android.library.reference.1=../Facebook
Where ../Facebook contains AndroidManifest.xml, etc. The real key being the relative path. Don't use an absolute path because Ant seems to treat your project directory as the root.
This should hold true for other library projects that you are including from source code.
I was dealing with similar issue. I'm building Android project on Jenkins using standard Ant build.xml (generated by Android SDK). I also have reference to another Java project with some shared domain classes. In Eclipse there is no problem with it. The domain project is a project reference. However on Jenkins this domain.jar is built by Maven and it was not accessible by Android project.
I have finally solved it by adding this at the end of build.xml:
<target name="-pre-build">
<copy todir="${jar.libs.dir}">
<fileset
dir="../path-to-another-project/target"
includes="*.jar" />
</copy>
</target>
This copies all jars from the target directory of another project into "libs" directory of my Android project. The -pre-build Ant target is automatically called before Android compilation starts.
I agree with Mark, however, if you're planning to modify your build script further - than you need to make it custom. Bring tasks from android/platforms/android-PLATFORMVERSION/templates/android_rules.xml to your build.xml and modify whatever you want to modify. Including location for external libs.