The one with new beacons

• New SDK for configuring Location and Proximity beacons
  • supports more sensors (temperature, motion, light)
  • advertising multiple packet types
  • new power modes (dark-to-sleep, scheduled advertising)
  • controls GPIO line
• Improved monitoring using batch mode and hardware filtering.
• Fix bug with empty beacons list when monitoring secure regions.
• Support for observing Estimote Telemetry packets.
• Support for observing Estimote Location packets.
• More information can be found in following docs:
  • Scanning and monitoring
  • Beacon connection
  • Multiple advertisers in Location Beacons
  • Using telemetry packets
• Old API is still there, so it should not break any code, however it will be deprecated and might be removed later.

The one with scanning and RSSI fixes

• Packet parser errors are logged and should not crash whole application.
• Fixed threading issue that cause scanning to continue when service was stopped (on some devices).
• onExitRegion should be now working on devices with pre-Lollipop Androids.
• Fixed (#135): Fails getting RSSI on Android >=5.0 (Samsung Galaxies)
• Fixed (#137): IllegalStateException when starting monitoring on SDK 0.9.6

Available in Maven Central:

dependencies {
  compile 'com.estimote:sdk:0.9.7@aar'
}

The one with ScanStatusListener

• Added ScanStatusListner to BeaconManager. This allows to find you when scanning really started and when it stopped. User may switch the Bluetooth off and then turn it on when
  application is running. This listener allows to track this events and react properly to them (eg. gray out device list). See ListBeaconsActivity to see sample code.

    beaconManager.setScanStatusListener(new BeaconManager.ScanStatusListener() {
      @Override public void onScanStart() {
        // Unlock UI
        list.setEnabled(true);
        list.setAlpha(1.0f);
      }
  
      @Override public void onScanStop() {
        // Lock UI
        list.setEnabled(false);
        list.setAlpha(0.5f);
      }
    });

• Fixed (#134): java.lang.NullPointerException when using SDK on Emulator

Available in Maven Central:

dependencies {
  compile 'com.estimote:sdk:0.9.6@aar'
}

The one with Lollipop BLE scanning API

• This release uses new Lollipop BLE scanning API. Previous API is still supported on older phones. It uses features like batch scanning and hardware filtering (if particular device supports them). No need to change your code, those features are enabled automatically (when they are available).

The one with Marshmallow permissions

• This release features support for Android Marshmallow runtime permissions and helps you meet all the requirements necessary for beacon detection (Bluetooth, Location, runtime permissions).
• Full description of all requirements for beacon detection are described in JavaDoc for SystemRequirementsChecker.
• Demos have been updated to target API 23 (M) and uses SystemRequirementsChecker to meet all requirements.
• From time to time SDK will put warning in device logs what is missing.
• We did great progress towards monitoring (#130). AlarmManager is now registered as global broadcast receiver which will substantially help with reliability.

New tools

• SystemRequirementsChecker: use the check method to determine which requirements are not met for beacon detection
• SystemRequirementsChecker: use the checkWithDefaultDialogs method in your activity for a convenient way to ask for all permissions and rights. It's all handled by the SDK, and should be of great help if you want to get up and running quickly.
• SystemRequirementsHelper: a grab bag of static methods to determine status of Bluetooth, Location Services, granted required permissions

Available in Maven Central:

dependencies {
  compile 'com.estimote:sdk:0.9.4@aar'
}

The one with fetching beacon details

Bug fix:

• EstimoteCloud#fetchBeaconDetails(UUID, major, minor, callback) under certain circumstances could yield beacon not found.

The one with signal filtering

New:

• Beacon signal filtering for smoothing RSSI readings. What does it mean for you? The RSSI values returned by RangingListener#onBeaconsDiscovered are much more stable now, which should enable you to predict proximity to a beacon more accurately and without having to write complex filtering algorithms yourself. The dinner's on us*.

  * The dinner is not really on us, but the RSSI smoothing code is.

• You can add and remove multiple callbacks in BeaconConnection (new methods addConnectionCallback, removeConnectionCallback, clearCallbacks).

• Added EstimoteCloud#fetchBeaconDetails(UUID, major, minor, callback) method to fetch details of your beacon in Estimote Cloud using UUID, major, minor values.

Bug fixes:

• Secure UUID introduced in v0.9 got lots of good improvements. Fixes #127 and #124.

Breaking changes:

• Removed Beacon#getName method. It was name of the Bluetooth device and was often confused with name given to a beacon in Estimote Cloud. Beacon's name can be fetched using EstimoteCloud#fetchBeaconDetails method.

Available in Maven Central:

dependencies {
  compile 'com.estimote:sdk:0.9.2@aar'
}

The one with initialise fixes

• Fixes problem when not initialising SDK caused problems with ranging & monitoring.

• Available in Maven Central.

  dependencies {
    compile 'com.estimote:sdk:0.9.1@aar'
  }

The one with Secure UUID

• This release brings Secure UUID – a security mechanism to protect your beacons from spoofing (where someone tries to ‘impersonate’ your beacons, by broadcasting the same UUID, Major and Minor). Using Secure UUID, the UUID, Major and Minor values that your beacon broadcasts will change unpredictably over time. The only way to resolve the values we generate to a particular beacon is via authorized access to Estimote Cloud.

• You can enable Secure UUID via Estimote app from Google Play or via SDK

  connection = new BeaconConnection(...);
  connection.edit().set(connection.secureUUID(), true).commit(...);

• Ranging and region monitoring works transparently with Secure UUID enabled beacons. All you need is:

  • Make sure you have initialised SDK with your App ID & App Token.

    //  App ID & App Token can be taken from App section of Estimote Cloud.
    EstimoteSDK.initialize(applicationContext, appId, appToken);

  • Use SecureRegion instead of Region when starting ranging or monitoring.

    // Initialise BeaconManager as before.
    // Find all *your* Secure UUID beacons in the vicinity.
    beaconManager.startRanging(new SecureRegion(“regionId”, null, null, null));
    
    // Remember that you can also range for other regions as well.
    beaconManager.startRanging(new Region("otherRegion", null, null, null);

• Breaking changes:

  • BeaconManager methods for ranging & monitoring (startRanging, stopRanging, startMonitoring, stopMonitoring) no longer throws RemoteException. We heard that it caused lots of boilerplate code. We agree and removed it.
  • Formatting MAC address was always pain (aabbccddeeff or AA:BB:CC:DD:EE:FF?). That's why we removed all String representation of MAC address and introduced MacAddress class.
  • For the same reason we removed all usages of String representation UUID and used Java's java.util.UUID class instead.

• Available in Maven Central.

  dependencies {
    compile 'com.estimote:sdk:0.9@aar'
  }

The one with sensors

Also available in Maven Central under com.estimote:sdk:0.8.8@aar.

• Finally support for built-in sensors: motion and temperature.

• Motion sensor readout with notifications. Note that you need to make sure it is enabled (separate property do enable/disable motion) sensor.

  connection = new BeaconConnection(...);
  
  // Make sure to enable motion sensor first.
  connection.edit().set(connection.motionDetectionEnabled(), true).commit(...callback...);
  
  connection.setMotionListener(new Property.Callback<MotionState>() {
    @Override public void onValueReceived(final MotionState value) {
      // Motion state in value argument.
    }
  
    @Override public void onFailure() {
      // Error handling.
    }
  });

• Temperature sensor readout and calibration (two separate properies added to BeaconConnection).

  // Temperature calibration (see also docs for BeaconConnection#temperatureCalibration()).
  connection.edit().set(connection.temperatureCalibration(), 21).commit(...);
  
  // If you want to measure temperature from beacon on demand.
  connection.temperature().getAsync(new Property.Callback<Float>() {
      @Override public void onValueReceived(final Float value) {
        // updateTemperatureValue(value);
      }
  
      @Override public void onFailure() {
        // Error handling.
      }
    });

Bug fixes:

• Negative temperature is properly interpreted in EddystoneTelemetry packet.
• BeaconManager crash when there are Eddystone beacons with bad packet.

Breaking changes

• BeaconConnection.ConnectionCallback has been changed to indicate that that your access to beacon had been authorised (ConnectionCallback#onAuthorized(BeaconInfo)).