Version 1.4.4: bug fix for Android

Note: If you are an iOS user, you can disregard this message. iOS devices are humming along…

UPDATE 5/15: this version is now live in the Play Store.

Version 1.4.3 introduced a bug that causes Smoke Point to crash on a number of Android devices. If you are affected, my apologies for the inconvenience. If you’d like to understand the source of the bug, see “The boring details” below.

Version 1.4.4 fixes the bug and was submitted to the Play Store for review on June 11th. The review time on the Play Store is inconsistent: it can range from days to a week, or significantly longer in some cases. Nobody seems to understand why the long delays.

While the new version is in review, you can optionally download and install the 1.4.4 APK directly through this download link.

The boring details

Here is an explanation of the source of the bug, if you are interested. During the process of building an app so that it can be run on a real device, a developer will choose to build either a “debug” build or a “release” build. The differences are many, but in short, they represent the trade-off between having a small app that will download quickly and perform well when it is run (release), versus an app that has all the information embedded in it for a developer to use to understand what the app is doing at various places in the app, at a cost to size and performance (debug).

When doing active development, a developer tends to use the “debug” build because they don’t care as much about speed compared to understanding the detailed behavior of the app’s internals.

On the other hand, when submitting an app to an app store like the Google Play Store, they’ll send a “release” build. They want end users to be able to download the app quickly, which requires a small download size, and want the app to run quickly, which requires the compiler (the software that builds other software) to perform various optimizations.

When building Android apps, one of the steps to make an app smaller includes removing parts that the compiler believes aren’t ever used. In general, this is great: why download something to your phone that won’t be used ever? Well, in some cases, the compiler gets it wrong, and strips out something that was being used. That’s what happened in this case. When the software went to call on this missing piece of code, it could not continue, and had no choice but to crash. The fix is simple: tell the compiler to make an exception.

Lessons learned:

  1. Must build and run a release build prior to launch to verify that the compiler hasn’t been overly aggressive.
  2. Add a crash-detector and reporting tool to direct users experiencing issues in the future to resources to resolve them and keep them informed.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: