Here's the issue: We have a team of 4 people working on a few Android libraries and apps dependent on those libraries. Some of us are on Windows 7, others are on OS X, and we use GitHub. Several times a day, we each have to change the Android Library paths because the project.properties files stores platform dependent paths (that is, it uses \ as a Windows path separator and / as an OS X path separator.) It's really annoying and we waste a good deal of time on it.
Does anyone have a decent solution for this? It seems to me that surely there must exist something like the CPP where we can throw an ifdef into project.properties and have it automatically fix paths to match our OS whenever we pull from github or something.
Oh, and to be clear, we're frequently adding and removing libraries, or changing which libraries depend on each other, and all of us modify all of the libraries on a regular basis... so simply adding project.properties to gitignore wouldn't work very well, because we'd still have to regularly modify the libraries to make sure we have all the correct things included.
The last project that I worked with, we would modify the paths for our system and add the file to our .gitignore. It was a mature product so the paths rarely changed.
Related
I would like to use a shared library, that is compiled for arm64, on Android. I have my .so file inside a aarch64-linux-gnu folder, but for other libraries I have instead a aarch64-linux-android folder.
Please can these libraries compiled for aarch64-linux-gnu run on an arm64 Android device? What do these names stand for precisely? I know that aarch64 refers to the arm64 processor architecture but I don't know how the operating system is related here.
Thank you!
Android and ARM my have some libraries that are the same. Basically the SO file has to be able to find all the libraries it was linked against to run, and the versions need to match up so nothing breaks. This is risky, and it is generally safest to compile the entire program on your target machine. You can see if everything can be located/what is missing using:
ldd /path/to/file.so
this will give you a list of libraries and where the file thinks they are - or ??? if it can't find it. You need to double check and see if the results of this look OK.
Even if all dependencies are found, mismatch in versions or architecture will cause the program to break at run-time. You need to extensively test the use of the externally linked library and even then you may miss some cases that break your program. For this reason I would try and get the source code if possible, and re-compile everything on the target machine.
I need to compile libmysqlclient and librtlstr for Android (in fact I could find rtlsdr, but since I need mysqlclient the issue is still there).
I followed several guides but most of them present the instruction written here http://mortoray.com/2012/08/21/android-ndk-cross-compile-setup-libpng-and-freetype/
Anyway, the package I download did not contain any configure file so I don't know how to continue.
Because the purpose of this file should only be the creation of the makefile, maybe there is a way solve this.
So my questions are:
1) Is this the right approach? Are there others easier?
2) Does a general configure file exist so that I can download and use it?
3)If not, how does the makefile has to be written? This way I should be able to overcome the abscence of configure file
I need those libraries to port a c code (which needs them) to android building an executable that I'll run on my phone (so I already have the standalone toolchain from the NDK), if it helps
1) This is right approach (may be a little bit simplified, I'm using more steps to build) for libraries, which use automake. Much easier, if library uses Cmake (must contain CMakeLists.txt), because you need only NDK. Example: cmake -DANDROID_NDK=path/to/ndk -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=armeabi-v7a -DANDROID_PLATFORM=android-21 ..
2) No, also you need provide additional files (for example, Makefile.in)
3) This libraries have to use one of tools such CMake, automake etc, just Makefile or project for some IDE. So, try to find out, what of this use your libraries
I have a mature app that needs to have an SDK brought in that wraps the camera and makes it do some spiffy processing while it's running. The SDK has come to me in the form of some aar files but my app still lives in Eclipse. Because of my massive, steaming pile of a branding structure and deadlines for this integration the uncertain timeline required to fully migrate to Android Studio will not work (for now) so I'm going for converting the aars and using them in my app via Eclipse.
The problem I'm having is that I need to kick off the activity in the library but even though I fixed up all my build time reference problems, when running the app once I get to the point that is supposed to kick off the activity I get this error.
I've read through and double checked dozens of how-tos explaining how to consume the aar files and I think I've followed every step including:
Unzip the aar files and dress them up as individual library projects, including the file structure with the resources, the manifest, and the .jar
Make the project that needs the libraries add them as such
Add the .jars contained in the library projects to the build path (this step was not listed in most articles, and wasn't necessary for the project to build, but nevertheless it did not help my problem)
Declare the activity in your AndroidManifest.xml that the library brings in and declares in its AndroidManifest.xml
As I've said, everything looks good at build time, so I'm not sure what else to check. Because I'm reading that Gradle and Android Studio mashes manifests together really well, I have a hunch that it's something I'm supposed to regulate between the manifests but I don't know what it could be if that is it. I've wondered if I'm declaring the 3rd party's activity properly, but I'm not sure how to test it because the only way I can think to test it is to provide gibberish for the namespace but even then there are no complaints. I've also tried dissecting the .apk to look at the .dex file but I could not decipher anything useful.
My guess is that the library may not be building properly in eclipse - even before it's being added as a dependency to the application project.
Try looking at out/classes/* and making sure you have a .class file for the activity in question. I think the .class should actually be in the library as well as end up in the application project's out/ dir also.
If there are any native files (x.so) (as I would imagine there might be for spiffy camera stuff), you can look for the x.so files being included in the out/ dirs of both the library and application projects as well as the library.jar file.
Another option to maybe consider for this use case: https://github.com/ksoichiro/gradle-eclipse-aar-plugin
It seems that our app had a bad version of the appcompat-v7 support library. The .jars in it were different sizes than the one that comes with the SDK and several resources were missing. I have no idea how we ended up that way or where this bad version came from. Once I replaced it, things went great.
Later, I did encounter the need to drop in the .so files into the libraries I made that came out of the .aar files as Stad Kurdziel said in his answer, but that was causing a different error (the exception explicitly states that the .so is missing) and I arrived at the solution independently.
I am interested in integrating Scala (or some other non-Java JVM-language) into the android platform. I am not referring to writing an android application with Scala, that I did early early on, but actually hooking into the build process that builds the android platform source tree. I imagine this will be a matter of hooking into the makefiles and such. Does anyone have insight into this?
What I have so far:
The platform source treefrom git://android.git.kernel.org/platform/manifest.git built in its virgin form, guided by "[Download and build the Google Android][1]"
build/core/combo/scalac.mk # Configures scala compiler related variables, included by config.mk
Added definitions in build/core/definitions.mk for an all-subdir-scala-files and an all-scala-files-under
Added definition in definitions.mk to build scala files such that they are included in the package
What's left:
Include scala-library.jar
Ensure changes to -bootclasspath has not broken anything
Figure out how to handle case where scala classes depend on java classes and visa versa
Major cleanup of code
Testing!
Figure out what to do (other than just posting them here) with the changes I've made
Looks like I'm almost there!!!
Some notes from the past
Latest: I have found where the Java source files are compiled! In definitions.mk, see 'define transform-java-to-classes.jar'. The latest idea is to write a transform-scala-to-classes definition and then have it store those classes in the directly that gets packaged. I will call transform-scala-to-class right before this step in transform-java-to-classes.jar. Support for eclipse and cygwin will for now be dropped as it clutters up the code with workarounds and therefore increases my chances of failure.
The build process starts out by the root Makefile running build/core/main.mk
build/core/main.mk includes build/core/config.mk which includes build/core/combo/javac.mk which sets HOST_JAVAC, TARGET_JAVAC, and COMMON_JAVAC. COMMON_JAVAC is the "Java compiler command with common arguments," by the look of it the other two variables get these values by default, unless in a special environment (openjdk or eclipse). COMMON_JAVAC is not used outside this file. The other two are only used in build/core/definitions.mk.
build/core/java_library.mk (included by config.mk) seems to only be concerned with building jars. This is out of the scope of us caring. Any interaction with jars presupposes class files which presuppose that we were already successful in building our scala files.
There are checks in main.mk regarding the version of java. We will ignore these and assume that our version of scala is compatible. Right now (in combo/scalac.mk) I am using the same --target arg used in javac.mk. This should perhaps be stored in a variable.
main.mk also includes build/core/definitions.mk which in turns defines some useful functions. The one we care about here is all-java-files-under and all-subdir-java-files. The latter is used in Android.mk files to find java files. The former is used in the implementation of the latter. I will write Scala equivalents of them.
To figure out how the build process works, I am now running make with -n and others. I got this idea from the stackoverflow article "[Tool for debugging makefiles][2]". I am also investigating debugging with remake.
build/core/{config.mk, definitions.mk} gives us light as to which make files/commands are used to do what.
As a possible way of hacking in support on a per project bases, additional code could most likely be added to the project's Android.mk file. From platform/build/core/build-system.html we read "Android.mk is the standard name for the makefile fragments that control the building of a given module. Only the top directory should have a file named "Makefile"." You could create a new target like "scala-build" and run that (make PackageName scala-build) before the final make. One could perhaps also hide it sneakily in a variable assignment, mitigating the need for a target to be called explicitly.
Another way (far far more hackish) is to hijack the command being used for javac. This is set in build/core/combo/javac.mk. Your project's Android.mk will have to include *.scala files in LOCAL_SRC_FILES along with the *.java files.
Guys on reddit say, there's a tutorial on integration Scala into Android with ant here.
I have seen samples for Mercurial ignore files for Visual Studio, amongst others.
I've just started playing around with Android development, and I also use this time to experimenting with Mercurial. So my question is: does anyone have a good example of a .hgignore file to use for Eclipse and Android development?
For starters I've got the following myself:
# use glob syntax
syntax: glob
# Ignore patterns
.metadata\
bin\
gen\
Are there any other ignore patterns that should be included? Should for instance the Eclipse files .classpath and .project be omitted from version control as well?
-- Edit below --
I haven't quite gotten the answers I hoped for yet, so I'll put out a bounty and try to specify a bit clearer what I'm looking for.
After experimenting a bit myself, I seem to have found that the suggested .hgignore listed above seems to be sufficient. The only addition I've made, is one line with .settings (this was a folder that appeared after I ran Android Tools -> Fix Project Properties). I've also found that (as mentioned by Ry4an) that the Eclipse files .classpath and .project should not be excluded.
I am however uncertain that this small ignore file will be sufficient when I get to projects a bit bigger than the basic tutorials (if it actually is all good, please explain why, and you'll get the credit). So to summarize what I'm looking for:
I want a concrete example for a .hgignore file for an Android project under Eclipse
The ignore file should be so that whenever I check out a copy of the repository at a new location, it should work straight away (i.e. without having to mess with paths and references, add missing files etc.)
Please also explain why your include file looks like it does (I want to understand why certain files/directories are excluded (and why some definitely should be included))
If you include OS specific excludes, please also state so (I'm running on Windows 7 btw.)
The eclipse files should definitely be added. The general guideline is to add:
everything that is hand written/typed
the minimal subset of everything else necessary to build the project
That last one is where your judgement comes in. It clearly excludes the .jar files you build yourself and your final .apk, but does it include third party .jar's you use? Some people do include them, but better is to include a configuration file for a dependency manager like 'ivy' which lets the next builder download the requirements they need automatically.
After auto-creating a project in my tools of choice, I'll just do a command like this:
hg status --unknown --no-status >> .hgignore
which adds the list of all unknown files to .hgignore. Then I go in and remove things I wants saved (ex: .project) and wildcard files that will grow siblings (ex: **.class)
There's a very nice sample .hgignore for Android at http://androidfragments.blogspot.com/2011/11/hgignore-for-android.html
Here is my hgignore:
syntax: regexp
\.DS_Store
.swo
.swp
.metadata/
/bin/
Whether it's a good one or not is a separate issue
well if its android projects than
local.properties should also be ignored
I have found a good example of .hgignore. It works for me.
#Mercurial Ignore Rules for Android
#Save as .hgignore in the repository base directory and add it to source control.
syntax: glob
*.class
*.apk
*.dex
*.ap_
*.suo
syntax: regexp
^(.*[\\/])?gen[\\/].*
^(.*[\\/])?bin[\\/].*
^(.*[\\/])?obj[\\/].*
^(.*[\\/])?log[\\/].*
^(.*[\\/])?obf[\\/].*
^(.*[\\/])?jars[\\/].*
^(.*[\\/])?jar-sources[\\/].*
^(.*[\\/])?javadoc[\\/].*
^(.*[\\/])?\.svn[\\/].*
^(.*[\\/])?\.metadata[\\/].*
^(.*[\\/])?\.settings[\\/].*
Source: http://androidfragments.blogspot.ru/2011/11/hgignore-for-android.html