New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dealing with Doze and Standby in Android Marshmallow #413

Open
yaronyg opened this Issue Jan 5, 2016 · 4 comments

Comments

Projects
None yet
3 participants
@yaronyg
Member

yaronyg commented Jan 5, 2016

NOTE: We have tested this manually on the only Marshmallow devices we have but we need to test on more devices and we need to upgrade CI so that it has a new version of ADB build for our ARM environment on the Raspberry PIs that will allow us to automatically grant permissions.

When an App is put into Doze or Standby mode in Marshmallow it isn't allowed to connect to the network or to run or do anything. Now it's unclear what this means if one is trying to do things like run a BLE scanner or BLE beacon in the background. Also there is a special permission that the user has to approve in order to get around these restrictions.

We need answers to the following questions:

How does Doze and Standby affect services? Do they only apply to the app's foreground or to its services as well?

If Doze and Standby affect services then we need to know:

While our app is in Doze or Standby mode can we still be a BLE beacon?
While our app is in Doze or Standby mode can we still scan for BLE beacons?

If the answer to the two questions above is yes then we need to figure out if receiving an incoming BLE connection or discovering a remote BLE beacon will give us the ability to wake out of Doze/Standby and establish a BLE transfer and then establish a Bluetooth connection?

Separately we also need to figure out what we can do about WiFi. If local WiFi supports multicasting and direct connections then we will want to regularly ping the local AP (if there is one) to see if there is anyone around who wants to exchange information. It sounds like all WiFi gets turned off, so what can do we to make it go on?

Maybe we can do what we already are doing? If not then we have to investigate the feature they added to get white listed as an application that is exempted from Doze and Standby. Exempted apps still have limitations so we have to figure out if our BLE and Bluetooth functionality will continue to work right under those exemptions.

@tompaana

This comment has been minimized.

Show comment
Hide comment
@tompaana

tompaana Mar 11, 2016

Member

Tested with Nexus 6 (Android version 6.0.1).

Test results:

Doze:

  • Peer discovery not affected and runs successfully
  • Can accept incoming connections and transfer data (handshake bytes read and written)

Standby:

  • Peer discovery not affected and runs successfully
  • Can accept incoming connections and transfer data (handshake bytes read and written)
Member

tompaana commented Mar 11, 2016

Tested with Nexus 6 (Android version 6.0.1).

Test results:

Doze:

  • Peer discovery not affected and runs successfully
  • Can accept incoming connections and transfer data (handshake bytes read and written)

Standby:

  • Peer discovery not affected and runs successfully
  • Can accept incoming connections and transfer data (handshake bytes read and written)
@tompaana

This comment has been minimized.

Show comment
Hide comment
@tompaana

tompaana Mar 14, 2016

Member

How to reproduce the test scenario:

  1. Get the modified Native Test app for the first device. The version used for testing was this commit.
    • In Settings tab of the Native test app clear the peer name (set it empty) - this will utilize the simplified handshake message used by the Cordova Plug-in.
  2. Implement the following changes in ConnectionHelper class of this project:
    • The same UUID for both ConnectionManager and DiscoveryManager:
private static final String SERVICE_UUID_AS_STRING = "b6a44ad1-d319-4b3a-815d-8b805a47fb51"; //"fa87c0d0-afac-11de-8a39-0800200c9a66";
private static final String BLE_SERVICE_UUID_AS_STRING = "b6a44ad1-d319-4b3a-815d-8b805a47fb51";
  • Start ConnectionManager and DiscoveryManager explicitly in the constructor (on last line): start(50000, true, new JXcoreThaliCallback() { });
  1. Run Thali Test app (the one with all the Cordova and JXcore stuff) on the second device and get its logcat logs.
  2. Apply the Doze or Standby test commands (for the second device once the app is running) as explained here.
  3. Use the first device (the one running the native test app) to connect to the second device and check the logs for results.
    • Note: You can only connect once after which the Thali Test app (on second device) needs to be restarted.
Member

tompaana commented Mar 14, 2016

How to reproduce the test scenario:

  1. Get the modified Native Test app for the first device. The version used for testing was this commit.
    • In Settings tab of the Native test app clear the peer name (set it empty) - this will utilize the simplified handshake message used by the Cordova Plug-in.
  2. Implement the following changes in ConnectionHelper class of this project:
    • The same UUID for both ConnectionManager and DiscoveryManager:
private static final String SERVICE_UUID_AS_STRING = "b6a44ad1-d319-4b3a-815d-8b805a47fb51"; //"fa87c0d0-afac-11de-8a39-0800200c9a66";
private static final String BLE_SERVICE_UUID_AS_STRING = "b6a44ad1-d319-4b3a-815d-8b805a47fb51";
  • Start ConnectionManager and DiscoveryManager explicitly in the constructor (on last line): start(50000, true, new JXcoreThaliCallback() { });
  1. Run Thali Test app (the one with all the Cordova and JXcore stuff) on the second device and get its logcat logs.
  2. Apply the Doze or Standby test commands (for the second device once the app is running) as explained here.
  3. Use the first device (the one running the native test app) to connect to the second device and check the logs for results.
    • Note: You can only connect once after which the Thali Test app (on second device) needs to be restarted.
@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Mar 14, 2016

Member
  1. Please test on your remaining devices
  2. Please put the info on how to repro the tests into the test readme
Member

yaronyg commented Mar 14, 2016

  1. Please test on your remaining devices
  2. Please put the info on how to repro the tests into the test readme

tompaana added a commit that referenced this issue Mar 15, 2016

@tompaana

This comment has been minimized.

Show comment
Hide comment
@tompaana

tompaana Mar 15, 2016

Member
  1. We (@juhanak, @vjrantal and I) have no other Marshmallow devices than Nexus 6s so no remaining devices to test with
  2. Done - PR ready
Member

tompaana commented Mar 15, 2016

  1. We (@juhanak, @vjrantal and I) have no other Marshmallow devices than Nexus 6s so no remaining devices to test with
  2. Done - PR ready

@yaronyg yaronyg removed the estimate - 10 label Mar 15, 2016

@yaronyg yaronyg removed this from the New Infra milestone Mar 15, 2016

@yaronyg yaronyg added 0 - Icebox and removed 3 - Working labels Mar 15, 2016

@yaronyg yaronyg added this to the V1 milestone Aug 3, 2016

@yaronyg yaronyg added 1 - Backlog and removed 0 - Icebox labels Aug 4, 2016

@yaronyg yaronyg added the Android label Sep 1, 2016

@yaronyg yaronyg added bug and removed 1 - Backlog labels Oct 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment