Being a responsible devloper (sic) I like to add unit and instrumentation tests when I add or change code. For reasons Mockito disappeared from my Android instrumentation tests this morning. My project is set up as a library module and an application module that uses the library. Read on to find out how to fix issues like this.
This post is about how to build Javadocs for Android library projects with Gradle. More importantly it also tells you how to upload the Javadoc artifacts with the uploadArchives task of the Maven plugin. This post will walk you through how I got it to work.
Picasso is an awesome library for downloading and caching images. If the images that you need to download require authentication you can do that by specifying a custom Downloader class. If you do this you can no longer use the with method to initialise Picasso.
Properly testing app upgrades on Windows Phone is not as straightforward as it could be. When you deploy a XAP from the IDE or with the XapDeploy tool the build system will evaluate whether an incremental update is possible or if a full redeploy is required. A full redeploy will remove all of the app’s IsolatedStorage and make testing upgrades impossible unless we use the ISETool. Continue reading
I needed to launch one of my Android emulators from the terminal recently and I was surprised to see how slow it was, especially seeing as I had enabled host GPU acceleration and that the emulator an x86 one with HAXM enabled. I had never experienced any such issues when starting the same emulator from my IDE. The exact error that I received was this:
emulator: ERROR: Could not load OpenGLES emulation library: dlopen(libOpenglRender.dylib, 1): image not found
emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.
I had a suspicion that this library may have been lurking in the SDK somewhere so I had a peek and discovered where it was hiding.
$ find $ANDROID_HOME -name 'libOpenglRender.dylib'
The solution was to append the SDK’s lib path to OS X’s LD_LIBRARY_PATH before invoking the emulator.
Naturally you can put this line in your shell’s startup script and you won’t have to worry about this problem again.
I was setting up a Gradle-based Android project on Jenkins today. I had read in a few places that Gradle would be downloaded somehow after installing the corresponding plugin but the build was failing within seconds of starting. My SDK was fully up to date and I had already set ANDROID_HOME but the build was still complaining about not being able to find gradlew.
When I read the manual I discovered that gradlew, gradlew.bat (for our Windows friends) and the gradle/ directory in the project’s root are supposed to be committed to source control. The next build went beautifully smoothy!
I was greeted with this error today when I tried to run some tests on a Windows Phone project. To cut a long story short my test project’s configuration had somehow lost its Startup object, as you can see in this screenshot.
The remedy was simply to change the startup object to the relevant Xap. After this the tests started to run again.