So on my quest to get Bluetooth LE running on my Raspberry PI AndrodThings (AT) platform I came across a few strange debugging oddities.

AndroidThings uses the same Android Studio for platform and application development just like it’s big brother phone Android. There are some differences thou, and its probably worth your wild to get familiar with these if you plan on doing any significant development. Here are a few things I discovered on my journey .

  1. The API’s are much reduced from the standard Android. This makes sense seeing AndroidThings targets a much more “resource constrained” device.  AT can run on low end platform like the iMX6UL. This is a low cost part with an ARM A7 core. Also, AT can run “headless”, meaning no display so all the baggage associated with higher end display’s removed. There is some good information on the Google site here.
  2. Permissions are also granted differently. Like big boy Android you can declare basic permissions in your apps manifest like the following:
<span class="tag"><manifest</span> <span class="atn">xmlns:android</span><span class="pun">=</span><span class="atv">"http://schemas.android.com/apk/res/android"</span><span class="pln">
    </span><span class="atn">package</span><span class="pun">=</span><span class="atv">"com.android.app.myapp"</span> <span class="tag">></span><span class="pln">
    </span><span class="tag"><uses-permission</span> <span class="atn">android:name</span><span class="pun">=</span><span class="atv">"android.permission.RECEIVE_SMS"</span> <span class="tag">/></span><span class="pln">
    ...
</span><span class="tag"></manifest></span>

Permission described in this way are called “normal” permissions. These are permissions that don’t pose much risk to the users privacy. Another set is called “dangerous” permission. Dangerous permissions are things like Internet access or location permission which can, potentially, comprise a users privacy. Granting dangerous permission usually involves another layer of security like explicitly asking the user to grant the permission at app install time or at run time via a dialog popup. Here is where AndrodThings diverges, because an AT device may not have a user interface the Google folks did things a little different. According to the documentation, you can describe both normal and dangerous permissions in the manifest and the dangerous permissions take effect “on the next device reboot”. There is no run time check necessary.

So I was trying to debug my AT Bluetooth app when I ran into this issue. I was trying to set a breakpoint and single-step through the Bluetooth connection process. Initially, it always complained because it did not have permissions so I had to reset it. But if I reset it, it would loose its debug connection. Sounds like a catch 22 situation. The only workaround I was able to make work was the following:

  1. Install and instance of the app.
  2. Reset the device and let the app run.
  3. Start another “debug” instance of the same app.

This seems to have solved the permission issue as I can now set breakpoints and step through the code without permission violation exceptions. I know this is not an ideal solution and logically having two of the same apps running is probably going to raise other issues.

If anyone knows a better way please drop me a comment.