Category Archives: Operating Systems

Revisiting Android and support libraries (support-v4 and appcompat-v7)

I have previously written on this subject, but now I am using IntelliJ IDEA 13 with the latest Android SDK of this writing (September 2014) and when you create a project you might be greeted by an error message like the following:

Error:Gradle: A problem occurred configuring project ':projectname'.
> Could not resolve all dependencies for configuration ':projectname:_debugCompile'.
   > Could not find any version that matches com.android.support:support-v4:0.0.+.
     Required by:
         Projectname:projectname:unspecified
   > Could not find any version that matches com.android.support:appcompat-v7:19.+.
     Required by:
         Projectname:projectname:unspecified

The Android SDK has switched over to Gradle since I last wrote about it. In this case the default setup already searches the local libs directory under Projectname/projectname for any jars to compile with the build of the application. But if you would follow the instructions from my previous post the chance is high that you keep running into this problem. Aside from the installation of the Android Support Library, you will also need to install the Android Support Repository in order to make dependency resolution work. Do verify that your Projectname/local.properties contains a set property for sdk.dir that points to the root of your locally installed Android SDK.

Now, you might still run into problems. The thing is that in your Projectname/projectname/build.gradle you generally want to have the compile lines for support-v4 and appcompat-v7 match the version of your targetSdkVersion. So this might become:

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:support-v4:20.0.0'
    compile 'com.android.support:appcompat-v7:20.0.0'
}

These numbers can be found in the SDK under extras/android/m2repository/com/android/support under the respective entries for appcompat-v7 and support-v4. If you would use + for the version identifier, you run the chance of picking up the latest version, including release candidates and this might break your build. So in this case being explicit is better than depending on it implictly.

Edit: On second thought, it might be better to use 20.+ or 20.0.+ for the version identifier in order to automatically pick up bugfix releases down the line. Looking at the release notes of the support library it seems that Google is quite strict in sticking to semantic versioning.

TortoiseHG and wildcard certificates

Having resolved recent SSL certificate issues with Mercurial/TortoiseHG, I now encountered a similar issue with the wildcard certificate for *.google.com where getting a clone would result in a "SSL: Server certificate verify failed" error.

One way around this issue is to add the fingerprint for this certificate to your configuration. Currently for *.google.com this is 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8 and one way to get this from a Unix command line is with openssl s_client -connect code.google.com:443 < /dev/null 2> /dev/null | openssl x509 -in cert-code -fingerprint -noout -in /dev/stdin | tr "[:upper:]" "[:lower:]". This corresponds with Chrome’s certificate view’s thumbprint field, you just need to add colons.

Right click in Explorer, select TortoiseHG » Global Settings and then click Edit File and add the following:

[hostfingerprints]
code.google.com = 00:d5:88:35:29:b9:7f:03:92:60:c2:04:e4:b7:01:f0:07:53:15:a8

This should make Mercurial/TortoiseHG work, at least until the certificate expires and you need to update it with the latest fingerprint.

TortoiseHG and non-standard SSL certificates

For my own development I use Mercurial and TortoiseHG for my version control system. I also use, at the moment, a CAcert certificate to use HTTPS with my repositories. I am not sure what changed when, but apparently the certificates now get verified. So this causes obvious problems trying to push or pull due to "SSL: Server certificate verify failed" errors.

To make this work on a Windows 7 machine with TortoiseHG in stalled, first download the CAcert root PEM certificate and place it some permanent directory. Next open the TortoiseHG global settings (right click somewhere in Explorer and select TortoiseHG » Global Settings). In the window that opens click the Edit File button. If it does not exist yet create a section similar to this:

[web]
cacerts = C:\path\to\cacert-root.pem

Press Save and OK and any push and pull action with HTTPS URLs should work as they ought to.

Unbound unable to read root zone

After upgrading various ports on my FreeBSD system and days later a full world and kernel, a reboot showed me that unbound didn’t start. The system reported that:

error: reading root hints
/usr/local/etc/unbound/named.cache 88: Empty line was returned

It turns out that from ldns 1.6.13 to 1.6.14 there is an API change that caused problems for unbound. After upgrading ldns you also need to recompile unbound to pick up on these changes. If you do not, you will run into the problem above.

Pinning Eclipse to the Windows taskbar

I pin programs that I use frequently to the taskbar of Windows. So I was a bit surprised to see that the newer version of Eclipse, Juno, doesn’t seem to support this by default. After some searching I find out that you can force this by adjusting the eclipse.ini by starting the file with something akin to:

-vm
C:\Program Files\Java\jdk1.7.0_05\bin

Then after starting Eclipse with this in place, you can, once fully loaded and past the splash screen, pin Eclipse to the taskbar.

Steam indefinite update paused

So recently I had an issue with Steam where the Witcher 2 update got stuck at 99% and the status “Update Paused”. No matter what I tried with the pause/resume button, I couldn’t get it to budge from this status and actually update.

After a while I grabbed Process Explorer from the Microsoft website and checked the files that were being opened when I toggled this state. I noticed a reference to Steam\steamapps\downloading\20920\CookedPC\pack0.dzip. Then I also noticed a file reference to Steam\steamapp\logs\content.log. Upon checking that file I found a notice that it was trying to preallocate about 11 GB for this pack0.dzip. Checking my drive status, I saw that this particular drive letter only had about 9 GB left. Freeing up some space allowed the update process to actually start and finish, after which I got even more space back, since it seems Steam downloads these files and then replaces them, deleting the temporary one. So I guess the lesson learnt is that you should always have enough disk space free as the single largest file in any of your games.

Adding android.support.v4 to your Android application in IntelliJ IDEA

You can enable support for certain forward version features via the android.support namespace. In order to accomplish this you need to start the Android SDK Manager and make sure that under the Extras heading you select and install the Android Support package.

Once done you go into the directory extras/android/support/v4 and copy the android-support-v4.jar to your own project’s libs directory. Next go within IntelliJ IDEA to File » Project Structure and under Project Settings go to Modules, make sure your application is selected in the middle pane, then on the right side select the Dependencies tab. In the window below click the plus-icon and select Jars or directories. From the resulting window browse to your libs directory and select the android-support-v4.jar and press OK to close the window and add the jar-file to the dependencies of the project. Since you are now using certain constants from a newer version of Android the Module SDK needs to be changed to Android 4.0.3 Platform as well. Press Apply and close the Project Settings by pressing the OK button.

Android Galaxy S2 Skin and AVD

What I did to get the Galaxy S2 skin to work with the Android Virtual Device (AVD) was:

  1. download the skin from the Samsung Developer website, it’s under the Add-on SDKs,
  2. extract to a Galaxy_S2 directory,
  3. put the entire directory in the [Android-SDK directory]/platforms/android-10/skins directory,
  4. edit the manifest.ini and change api=9 to api=10,
  5. restart AVD Manager,
  6. under skin in the device configuration you should see Galaxy_S2 in the dropdown.