I'm not too familiar with the Android build process, so I'm sorry if this comes off as a really stupid question.
Anyway, I'm writing testing code utilizing ActivityInstrumentationTestCase2 and Robotium for an Android application by the company I work for.
The company is rather large, so the transition to Gradle is going very slow. I would like to use Gradle for my testing project for ease and future maintainability, but right now the application I'm testing is built using a combination of ANT scripts and manual intervention with all dependencies checked in as jars in the repository. I'm not at all involved in that process, but I know it's pretty hacked together.
From what I understand, Gradle cannot simply depend on and trigger the building of another existing Android project unless that project also utilizes Gradle. So unless I want to really get my hands dirty with the build process of our application (we have people who are literally hired to only deal with that), I'm out of luck.
What I do have access to, however, are debug builds of our application.
So my question is, is there some way that I can have Gradle use the compiled debug APK as a local file dependency, or can APKs not work like that?
APKs don't work like that; you can't depend on them, for a variety of reasons. The most important reason is that the code and resources are processed and compressed and much of the original information needed to build them is lost at that point.
You'll have a tough time getting it to work properly. If things that you depend on are pure Java libraries, then if you could get them in JAR format you could depend on them from a Gradle project pretty easily. But if they're Android projects containing resources and manifest entries and such, then there isn't a compiled file format you could obtain those libraries in that would be compatible with Gradle. Gradle supports the AAR format for Android libraries, but that format is generated by Gradle and nothing else.
Related
does exporting the libraries have something to do with JIT and compiling it into dex at runtime? I'm trying to make sure that my Android application has the smallest possible binary so that upgrades are not to big. Maybe someday Google will make upgrades partial instead of the whole APK.
Just now noticing these questions as the new ADT 22 has you manually export the "Android private libraries" now which used to be the libs folder and it would automatically export it anyway.
That reflects some of the changes that have been made in the build system. This is already how it used to be done in IntelliJ. It's all part of a bigger plan to make life easier with multiple builds and larger code-bases. I know it seems tedious now, but you'll see the advantages soon.
I've spent the last few days struggling with getting a system up and running for building multiple configurations of our Android NDK App. I am able to build the libraries fine; the issues I run into usually stem from keeping those libraries up to date when changing build configurations.
I need a system that is for the most part fully automated: the user should just change build configurations and everything just works!
How have you addressed build configurations and the issues with libraries not being properly rebuilt?
I've tried a bunch of different approaches to this, but they all seem to end up with issues that are out of my hands.
Initially we just outputted a Shared Object file with the same name regardless of Build Configuration (eg. game.so). The problem is, changing build configurations doesn't trigger the library to be rebuilt; you have to make a change to the source or build scripts. So people change from Debug to Release, run the app, and are unknowingly actually linking to the Debug version still.
So then we tried outputting the library to a unique Shared Object based on the build configuration. For example, the debug version is gamed.so. The release version is gamer.so. The problem is, the Java code has no concept of build configuration, so how do we know which version of the library to load (which is done from Java)?
Well to get around that we do a try/catch looping through all the possible versions of the library attempting to load them. When we find the one that exists, load it! Problem being that the old versions of the library do not get removed when deploying a new configuration to the phone. So if you have built and run both Debug and Release, both of those libraries are now on the phone! Which ever one you ask for first, it will find and load.
So anyway, this seems like something that must have been solved already, but I have found very little information online. Nothing that has met my needs.
My question is: how have you addressed build configurations and the issues with libraries not being properly rebuilt?
This is actually strange. I have always seen that install -r refreshes the /data/data/app.pack.age/lib directory. Which device do you use for development?
I am turning an project that I have been working on for while into a library project and I would like to know what can be left out of that project.
The library is only source code (no images or UI). What can be left out of the ManiFest.xml file, and can I safely remove all the drawable, values, layout, and layout folders? I know I will no be using those resources, and strings resources will be handled by the referencing project.
You can remove anything that is not directly referenced by your library project. It just has to be a viable Android project that compiles.
Pretty sure you can have a bare bones manifest file too. Since you cannot run a library project and you have to copy the anything that would be declared (e.g. activities, permissions, services, content providers etc) into the manifest that uses your library project anyway.
I started working with Android Library Project since r12, If I were you, I would highly consider waiting a little bit longer (until r17 release).
Android dev team started revamp the whole Library Project design during several recent release (probably since r14), and promise us a ultimate solution in next coming release. check out this blog for details. This leaves our continuous development in an extremely unstable stage at the moment, there are already numbers of threads posted on the internet, for example, this one complain about the compatibly with legacy Library Project, regardless of whether you use Ant, Maven or purely ADT manage your Library Project. From my own experience, I use Maven manage my Android Project, each time I upgrade my SDK since r14, Library Project is always the trouble maker. I would expect another tough landing when upgrade to r17, hopefully the last time.
If you insist, these are some development considerations you may need aware.
Hope this helps.
I have a published app that I use daily, installed on my phone. I also want/need to continue developing it, and I debug on the same phone (no emulator). Using eclipse, is the best solution for me to rename the updated package while I build and debug it so that I can continue to use the old version, or is there another way? If that is the solution, can I refactor a package name or do I have to change all of those manually?
I did search, and don't believe this is a duplicate as I do not want to publish multiple versions of the app. This would just be for me, and I am rooted if it would help my cause.
What has worked out great for me is using Android Library projects. I've got a Paid, Free and a dev version of my app which all use the same codebase.
My main codebase is an Android Library Project and I created other projects for the various versions. Then in your Application class, you differentiate between which version you're on to determine if you need different functionality. In your case, you'll just have a different package name.
Here's some links to get you started if you wanted to go that route. It's worked great for me, and I didn't want to go the route of Ant scripts:
http://developer.android.com/guide/developing/projects/projects-eclipse.html#SettingUpLibraryProject
http://blog.donnfelker.com/2010/08/05/howto-android-full-and-lite-versions/
http://www.marvinlabs.com/2011/01/sharing-code-full-lite-versions-application/
There's a refactor-Menu for renaming classes and functions, so the refactoring should be pretty easy. But I'd go the other way around and rename the stable application once on your phone instead of renaming every build you do - that way, you only have to rename the stable application once you want to update to a new stable version.
At university, we had a similar problem and built a small build-script, which would copy and rename libraries, etc. to the appropriate location (in our case, we wanted to handle iOS and Android-builds from the same source, so the build-script had to build some configuration files from configuration templates, too). Unfortunatly, Eclipse does not provide an easy way to define pre-build scripts via a project's options or something similar (as VisualStudio does).
You can do this easily with the maven Android plugin. Of course, it carries the additional overhead of having to use maven just for this purpose, but it's super easy, and you don't have to move ANYTHING around.
<properties>
<androidManifestFile-location>${project.build.directory}/AndroidManifest.xml</androidManifestFile-location>
<outputApk>${project.build.directory}/${ota-dir}/${application.name.forapk}-${project.version}.${project.packaging}</outputApk>
<debug-signing>false</debug-signing>
<android.renameManifestPackage>${target.package}</android.renameManifestPackage>
</properties>
As long as the ${target.package} keys are different between "installations", you can install the apps side by side.
I'm currently working on a large Android app using a massive amount of C++ code.
It compiles and runs, so far so good.
Unfortunately, every time I modify something in the structure of my native source (add/delete/rename/move a file), which happens pretty often, ndk-build rebuilds the whole source, even the untouched files.
Does anyone know how I can set up the Android NDK to build incrementally somehow?
Thanks in advance
I got fed up with the NDK build system, studied it for a bit, and wrote my own makefiles. This was not hard.
However, it was then pointed out to me that by doing this, I would have to take responsibility for tracking future changes to the platform, for example if it becomes necessary to ship binaries for additional processor types, I'd have to modify my homegrown build solution to do that too.
In other contexts, I've sometimes had projects with two build systems - one for quick experiments, another for deployable builds. The time spent updating both now and then was saved many times in the speed gain for daily work. Provided I had to do a real build at least every week or two, things never got very far out of consistency (and both build scripts were in the revision control system, so there was history to examine). Something like this could be done with a custom makefile for debug builds and still using the NDK build system for deployable packages.
(In one case of doing a lot of experiments at the edge of what the platform permits, I actually had my makefile pushing the updated .so onto the device and gave my application one of the discouraged hard-quit buttons, so I could restart it using an updated native library without even having to rebuild and reinstall the apk)