Set up and run the Mail Sample Android Project for Office 365 PREVIEW SDK

Note: This post is outdated, as it uses the SDK from when the Office 365 APIs were in Preview. Now that the APIs are generally available, please refer to this other article I wrote more recently on how to set up the sample in Android Studio.

My previous post covered setting up the Office 365 Android SDK and configuring it within Eclipse/ADT. I also wrote about the import errors that you may see, and how to fix those. 

Now let's actually run the sample projects to see what the new Office 365 APIs can do!

Note: As of writing, the APIs are still in Preview. They shouldn't be used in production as we may make breaking changes before they are released. Expect irregularities, and teething problems as we work hard to make them ready for use in your production code. Send feedback to the team through our page on UserVoice.

Which sample do you run? Well, the Office 365 Android SDK Github repository contains 7 Android projects (excluding the Tests, which shouldn't matter to you much):

  • office365-base-sdk
  • office365-files-sdk
  • office365-lists-sdk
  • discovery-files-sample
  • exchange-sample
  • read-sp-list-sample
  • read-write-sp-list-sample

The intention of having 3 different SDK projects is so that you don't have to pick between all, or nothing. You can just bundle whichever is appropriate for your project, and cut out the other functionality you won't be using, thus keeping your app as lightweight as possible.

The intention of having 4 samples is that each one focuses on a different end-to-end scenario which might be useful to you. If you're writing a mail app, for example, you probably wouldn't want to worry too much about OneDrive for Business files.

Let's just scope our attention to the Mail sample project (i.e. exchange-sample) for this blog post.

All the import errors should have been solved if you've followed my previous post.

1. Register the app in Azure.

2. Go to the Constants class. Change the value of the CLIENT_ID string to your app's client ID in Azure. (Coming soon: A post on how to register your app on Azure). It should look something like this:

3. Run it on either the emulator or your device.


If so, it's because the SDK hasn't been updated yet to reflect the new naming structure of the updated Azure Active Directory Library for Android. Remember how we added .aad in the import statements for all the classes that use the ADAL? We also need to update AndroidManifest.xml. Make sure the reference to the AuthenticationActivity in adal looks like this:

4. Try running it again. The app should launch, and you'll see this:

Sign in with your organization ID, e.g., or You cannot sign in with a Microsoft Account (MSA). An MSA would look something like or

After signing in, you'll see a view asking you to approve granting certain permissions to the app:

Note: Don't be unduly worried by the long list of permissions you see above. That's because in my Azure Active Directory, I registered the app and gave it all the available permissions in the drop-down. You don't have to do that; you can probably get away with just giving the app a limited subset of permissions.

After you approve those permissions, you'll see your inbox:

Ta-da! The app pulls in email from the Exchange server and displays them to you. You can click on each email to see the entirety of the message.