Android SDK: Starting companion app from watch stops working with OREO

Current hack that replaces a missing functionality in the ConnectIQ Android SDK will stop working when the companion apps Android API Level 26 (Oreo 8.0).

I'm talking about the hack that enables you to start the Android app by a message from the watch app. You do this by capturing a Broadcast Intent
"com.garmin.android.connectiq.INCOMING_MESSAGE" (as demonstrated here) and then checking for the correct AppId in its extras.

This is no more possible in Android API Level 26 and higher.

According to https://developer.android.com/about/...tml#broadcasts, apps will not be able to register for implicit intents in manifest anymore and would need a running service to react to them.

PLEASE: Add this feature to the ConnectIQ SDK. Allow us to start the companion app from the watch.
  • Thank you for the heads up! I've created a ticket to see if this is something we would be able to add to the mobile SDK.

    -Coleman
  • Has this been ever looked into? With Android O, we will be unable to start any app or service on the phone from the watch.
  • Sorry to bring this up again but I'm really curious! At this moment we are past the deadline on this issue. I see that the GCM app is still on the API level 25, so our hack still works. Are you planning to add the companion app starting feature to the next iteration of the Android SDK?
    We have a workaround for that at this moment but it's not really robust as it needs to install another app.
  • I am also requesting this. I believe this is critical functionality for Android Connect IQ Partner SDK and It would be great if it will be officially supported and documented.
  • Hi Antonin,

    as my upcoming project is critically dependent on this feature, I am trying to understand more about scenarios when it will not be available.

    - First thing of course is, that it is not officially supported or documented by Garmin. So they can remove that funkcionality anytime. I hope this will not be case, right Coleman?

    - Secondly, there are mentioned broadcast receiver limitations. Well for me, it still works even on Oreo, which is kind of confusing, but I am new to this stuff. According to Android documentation I would expect that I should get error during building the app as I have registered handle of this implicit action by broadcast receiver on my manifest. But it just works. On another hand I don't understand why this should be affected by targetSDK of GCM app. What make you think the "hack" will stop work?

    Thanks!
  • Hi capinoha,

    we are still using this hack with our Sleep as Android app. I don't believe that they'd remove the functionality, since the hack is just tapping into a standard Android communication mechanism, but theoretically, they could change the Broadcast intent into a LocalBroadcast.

    So what changed with API level 26 - Oreo (which means API level with which the app is built, not the version of your OS. This regards both your app and Garmin Connect app, which is already on API level 26:

    Broadcast intents need to be explicit, i.e. every intent needs to have a target package set. Before it was possible to just send a broadcast intent without a target package, and any app that had a receiver registered for that intent could intercept and process it.
    This doesn't mean that you cannot see the broadcast intent. But you only can intercept it in your app's runtime. From API level 26 on, you cannot declare receivers for broadcast intents in your app's manifest.
    There are two exceptions:
    1) Intents that have the target package set for your app
    2) Broadcast intents whitelisted by Google (there is a handful, but those are generic intents, like ON_BOOT, or SMS received etc.)

    So if you want to intercept a broadcast intent that isn't meant for your app, you need to have a service that's running at the time of the broadcast, and has a receiver registered.

    How exactly do you have your receiver implemented?
  • Hi ArtaudAntonin , thanks for answer.

    From API level 26 on, you cannot declare receivers for broadcast intents in your app's manifest.



    Well according to this, I shouldn't be able to build the app with following part in manifest, as it is registering implicit intent, right? But I can do it and it can wake up my app (with compileSdkVersion 28 ) even if the service is not running. So what am I missing? :confused:


    <receiver android:name=".LaunchServiceReceiver" android:enabled="true" android:exported="true">
    <intent-filter>
    <action android:name="com.garmin.android.connectiq.INCOMING_MESSAGE" />
    </intent-filter>
    </receiver>


    From LaunchServiceReceiver which is off course BroadcastReceiver I just simply start foreground service to handle requests.
  • According to my understanding, Garmin Mobile must have already implemented registering available receivers with this action on its runtime and thanks to this, I actually receiving explicit intent and not implicit with the intent-filter above. This is why it works ok even on Oreo, and probably means there is no reason to worry too much about loosing this functionality in the future. Because if they were implicit intents, my app will not be waken up by them in newest Android versions, which is not the case. I hope I am not mistaken here.
  • You can't receive an explicit intent from GCM, because they would need to hardcode your package name into the intent, using the setPackage() on their intent.

    Also, the variable in question is not compileSdkVersion, but targetSdkVersion.
  • Hey, may I ask what is the current status of this? I've read through a few years worth of post history from you (thank you for sharing so much information on this) however the forum search doesn't allow me to get a chronological history of your recent posts.

    Has this ever been fixed or did you find another workaround or does what you previously did still work? 

    forums.garmin.com/.../can-garmin-connect-iq-apps-launch-the-linked-android-app-in-the-background