I'm slowly starting to port my existing apps to Android Studio and Gradle. I have a few questions about it though before I get too far.
Is it possible to build a signed apk outside of Android Studio, from a command line, like you can with ant.
Is it possible to build a signed apk for every variant all in one go, again outside of the UI.
Finally, this is a situation that won't affect many people, but is there a limit on the number of variants you can realistically have. I am probably looking at having between 2000-4000 separate variants. Is this going to be a complete no go?
yes
yes
hmm that's quite a lot. I think there are going to be issues. For instance right now Gradle doesn't let us parallelise the compilation of the variants, so it's going to take forever to build. Also, you might run out of RAM when setting up the internal model that represent all the variants and their associated properties and tasks.
I guess you should just try it and see. Using simple groovy code you should be able to dynamically create 2000 flavors in an empty projects and then see if you can compile without problem.
Related
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.
Im looking for an automated way to update a counter for each time I compile a project. Im going to deploy several test versions of an app and need to keep track of what the testers are referring to.
Im also lazy soo it would be great to find a way of automatically add a build numbering system either by time stamp or by an incremented int.
I could do that in Emacs but for this project Im using Eclipse. Is there a good way of doing it there? I basically want to update a line in the strings.xml with a new value.
You could do all your personal day to day builds using the Eclipse GUI, then use Ant (operating on the same source files but producing output in a defined directory) for the alpha/beta releases. Android tools provides a build.xml which you can modify to include a build number task
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 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've used Eclipse and vim variously as development environments for Android applications and found both the Eclipse plugin and the command-line SDK tools to be of similar capability.
Since I haven't explored either in its entirety, however, I'd like to ask:
What advantages are there to using Eclipse over the command-line tools and vice-versa?
I could see:
(Eclipse) nice GUI for debugging
(ant/adb/android) more amenable to automation
(hybrid) you can have it all, can't you!?
I'm especially interested in specific features that may be a deal-breaker for one and move a developer in the direction of the other.
Using Eclipse as a development environment for Android doesn't preclude you from also building with Ant to hook into nightly builds or CI tools. You could even configure Eclipse to build using your Ant buildfile if you wanted. If you want some kind of CLI build tool, you might also consider Maven, as it also has plugins to enable building Android apps.
It has been some time (like six months) since I have used eclipse, so maybe it is better now, but I gave up on it because I found it to be very slow and buggy. Maybe it is the integration with ADT, but several times I spent hours hunting down problems that turned out to be fixed if I killed and restarted eclipse (and these problems were not fixed if I did a "clean" within eclipse). After doing that a few times, I felt like throwing the computer against the wall.
"ant clean" is much easier and faster than stopping and restarting eclipse.
Across my personal projects and multiple professional instances of building Android apps, I've always used both types of builds. You'll want to use Ant (or Maven, if you prefer) to set up continuous integration and automated testing. Trying to get that working with Eclipse (which I did a long time ago when the Android SDKs were first coming out) is a nightmare, while Ant/Maven is easily used from any of your favorite CI tools (I've usually used Hudson for this). If there's nothing unusual about your project, it'll be a snap to put together continuous integration, and off you go.
Meanwhile, for just day to day development work, using Eclipse to build your app locally works just fine. But that can easily be left up to the individual developer. I'd make the build that your CI system is running the canonical build, but I do use Eclipse for my normal development.
I'd use Eclipse until such time as you are happy with the debug build. Then you can set up Ant to produce the signed release build.
You can set it up to use the same source files as Eclipse but put the output binaries outside your workspace. You can also set it to use your release.keystore, sign it automatically and obfuscate the code all in one go.
I've set it up to do this. I open a command line (DOS box) move to the projects home directory (\dev\projects\Eclipse\Project1 say), I type "Ant release" and the apk ends up in \dev\projects\AntBuilds\Project1\bin as Project1-release.apk.
If you want the best of both worlds, you might want to look at the m2eclipse-android-integration Eclipse plug-in which allows you to use your command-line Maven build in the ADT/Eclipse environment as well:
https://code.google.com/a/eclipselabs.org/p/m2eclipse-android-integration/
Well for me im just a beginner, but I find eclipse much easier to work with. Android is a pretty complicated to get used to (for me) so having everything layed out in a GUI is preferable to command line. Plus SDK updates and such are easier to get.