Archive for the ‘K-9 Mail’ Category
After a more in-depth look at ActiveSync support in K-9, I found there to be more issues than I had first thought. This post serves to point out the most major of the issues that I have to tackle before this will be ready to be released into the wild.
1. K-9 does not remember sync state after being restarted. The sync keys used by the Exchange server to know which folders and emails have been synced by the phone are not persisted. This may not be immediately obvious, but it causes K-9 to do a bunch of work it doesn’t need to, which will do a real number on your battery (as well as network usage). This problem has been solved.
2. K-9 does not use the Exchange server to send email. K-9 uses its own “special” outbox for sending email, and it does the sending. K-9 should be moving composed emails into the outbox on the Exchange server, to be sent by the server. UPDATE: My original thoughts here were incorrect. Sending is working correctly.
3. K-9 does not download headers first and then mail contents. It downloads everything in one go. This causes a major delay before mails begin to appear in your message list. I am not sure the ActiveSync protocol is designed for this type of usage. This issue will require further investigation and thought.
4. ActiveSync is designed to filter the number of emails fetched by date, according to pre-defined filters (such as “one month”). K-9 is currently designed to fetch mail differently. The user interface for ActiveSync accounts will need to be modified to match the design used by Exchange.
5. There are discrepancies in the truncation size options for emails between K-9 and Exchange. I am also not certain if it is possible to know if an email is not fully downloaded. This will require further investigation.
I will be tackling these issues 1 by 1 as time allows. At this point, I don’t really have any idea how long it will take me to complete them all.
UPDATES: I have found and addressed a number of additional areas where the design of ActiveSync does not really mesh well with the design of K-9. I won’t go into all the technical details. Syncing of email is now working pretty well. I am now able to use K-9 as my daily email application on my phone.
I have blogged in the past about the less than fortunate state of Exchange support in K-9. This is due to the fact that K-9 communicates with Exchange through and outdated and problematic protocol: WebDAV. WebDAV support is turned off by default in Exchange 2007, and completely removed in Exchange 2010. This of course implies that K-9 does not support Exchange 2010. Since I started working on K-9, I have had the desire to replace the use of WebDAV with the Exchange ActiveSync protocol, which is designed specifically for mobile devices. Unfortunately, this task was much too large for me to take on in my (non-existent) free time. Lucky for us Google sponsors the annual Summer of Code.
This year K-9 was granted 4 Summer of Code projects, including EAS support. The project was successful, and at this point we have “mostly working” EAS support in a branch of the K-9 repository on github. There are still a few small issues to work out, and a few small features to complete, but I currently use K-9 with EAS support for email on my phone. If you would like to build K-9 with EAS support for your own personal use, I am including step-by-step instructions for doing so (though as usual, I do assume some basic knowledge of source control and building java applications).
In order get the K-9 sources and complete a build, you will need a git client, a JDK, ant (you can also use eclipse, but I don’t include instructions for that), and the Android SDK (make sure it’s up to date). The first step is fetching the source:
git clone email@example.com:k9mail/k-9.git k9mail
This will clone the repository at firstname.lastname@example.org:k9mail/k-9.git into the directory k9mail. This fetches all branches in the K-9 repo, including the ms-eas branch where EAS support lives. The next step is to “checkout” the ms-eas branch:
git checkout -b ms-eas origin/ms-eas
This tells git to create a local branch named “ms-eas” that tracks the remote branch at origin/ms-eas, and switch to this new branch. Now you must build the K-9 source. First, create a file called ‘local.properties’ at the root of the source tree with the following entry:
Obviously, replace “/path/to/android-sdk” with the path to the Android SDK on your machine. The command to build is:
This will build a signed and zipaligned installer ready for installation on your device. Finally, plug your phone into your PC via USB and ensure it is recognized by adb. To install the freshly built K-9:
adb install -r bin/K9-debug.apk
If you have K-9 installed from the market, you must uninstall it first. Your new K-9 will be signed with a different key than the market version and Android will not let you install this new version if the keys don’t match. Alternatively, you can give the app a new name in AndroidManifest.xml, but that’s outside the scope of this blog post.
If you want to report issues, feel free to mail k-9-dev [at] googlegroups.com.
When I first bought my Droid Eris, around a year ago, it came loaded with HTC replacements for most of the stock Google apps, including the mail app, the dialer, mms, etc… The HTC mail app just worked – it supported Exchange, handled multiple in-boxes, and the notifications worked like a charm. Sadly, when I switched to a Froyo ROM, the HTC applications where no longer available and I was stuck with the stock Google apps. Well, as far as the mail application was concerned, this was a very bad thing. The Google mail app came with some significant bugs, and a notification system that was pretty much useless. So I set out to find an acceptable replacement for the HTC app.
This is when I found K-9. It was reviewed well, and boasted Exchange support, which is apparently hard to find on Android. I was saddened when I discovered the state of the Exchange support, which wasn’t great. Firstly, there was a bug in it that prevented it from working with the domain\username format. But alas, the project was open source and, being a developer, this was good news. So I took it upon myself to dive in and fix whatever bug(s) was preventing it from working correctly. I had no idea what I was in for at that point.
What was going to hopefully be a few line patch turned into 2,000 lines or so – and I was only half done at that point. By now I have completely rewritten the process of making the initial connection to Exchange and authenticating. After my initial patch was (reluctantly) reviewed and merged, the project head offered me the position of taking over as maintainer for Exchange support. I accepted, but warned him that I don’t have much free time these days. Either way, I have gained a lot of knowledge about how Exchange with OWA and WebDAV work, and am able to share that knowledge with you.
First, let me describe a little bit about how WebDAV access works. Each user has a mailbox, which by default can be accessed by a URL in the form: https://mail.company.com/Exchange/username. Tack ‘/Inbox’ on to that path, and you have the user’s inbox. You can type that into your browser and you will be kindly redirected to an OWA login page. If you were to send an HTTP GET request to that URL, you would find that the Exchange server responds with a 302 status code, which is a redirect. This is exactly what K-9 does when making its initial connection to your exchange server.
Assuming this request is “successful” (I won’t go into what qualifies as success), K-9 then attempts to authenticate you. Based on the initial response, this will either be through basic authentication or form-based authentication. The greater majority of Exchange servers are setup for form-based authentication, and this is the only configuration I have actually tested. Unless the user has overridden the default authentication path in their configuration (which is completely unnecessary), the path used is: https://mail.company.com/exchweb/bin/auth/owaauth.dll. If Exchange gives K-9 back authentication cookies on the response, the user is authenticated and K-9 retrieves the user’s list of folders. Otherwise, it tries a more brute-force approach. It will check the response for an HTML form target. If it does not find one, it will send a request to the redirect URL from our initial connection and check this response for an HTML form target. Assuming one of these searches yields a valid form target, it will then try to authenticate again using a URL constructed with this form target. For this reason, the user can enter complete junk into the ‘Authentication path’ field, and K-9 will still be able to authenticate the user (albeit less efficiently). I could have removed this field entirely, but chose not to just in case a user has a completely custom/bizarre Exchange configuration.
The only reason I have encountered for why a user would need to enter a value for one of the “advanced” configuration options is if their mailbox alias does not match their user name. Unfortunately, this was not the case for versions of K-9 prior to 3.400. For this reason, upgrading K-9 to the most recent version will break Exchange support for some users until their configuration is corrected. I didn’t really want to do this, but it was a necessary improvement so that these advanced options have a specific and deterministic affect on how K-9 connects to your Exchange server. I don’t want users spending hours “tinkering” with their options trying to get K-9 to work anymore.
To cap off this blog post, I’d like to show some screen shots of the updated screen for configuring an Exchange account. As of the writing of this post, these changes have not even been merged into trunk yet.
Let me know what you think.