API, CIQ, SDK, SYSTEM #s

Thanks for the amazing insight into the world of Glances and Widgets. This is new to me, and amazingly complex and compelling. Since behavior depends on generation, I started to look into Device compatibility.

My 2 y/o Forerunner 955 is an API 5.0.0 device. This seems to be the very latest, even on the most recent Garmin Watches like the Fenix 8 (the VSC manifest editor suggests there is a 5.0.1 now). So my watch should be compatible with all of SYSTEM 7 and likely the upcoming SYSTEM 8 features? Is this correct?

So if I publish a data field for my watch, it'll be on an:

  • API = 5.0.0 Device
  • CIQ = 5.0.0 Device (CIQ # == API #)
  • SDK = 7.4.3 code release
  • SYSTEM 7 code release (SYSTEM # == SDK MAJOR #)
  • Access to all SDK function

But if this data field were uploaded to an EDGE 1000 it would be:

  • API = 2.4.0 Device
  • CIQ = 2.4.0 Device
  • SDK = 7.4.3 code release
  • SYSTEM 7 code release
  • Use "has" logic to avoid SDK features not available to this device

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/system-8-beta-now-available

  • In general I would:

    - build with the latest production (non-beta) SDK

    - use lowest minApiLevel possible (the lowest for all devices/part numbers you want to support, including APAC part numbers). In the past I've used 1.3. [*]

    - use has to avoid accessing features unavailable to certain devices, as you said

    - use the --disable-api-has-check-removal compiler option to avoid compile-time optimization of has checks. Without this flag, your has checks will be optimized at compile-time based on the connectIqVersion listed for the part number in the device configuration file at the time of build. This is especially a problem for APAC (Asia-Pacific) part numbers, which are often configured to be behind their WW (worldwide) counterparts in terms of CIQ version, and sometimes configured to be behind the actual APAC devices.

    To be clear there are two problematic APAC vs WW situations:

    - the  APAC variant of a device is behind the WW device, in terms of connect IQ version, and this is reflected in the device file. (IOW, the real APAC device's CIQ version is outdated)

    - the APAC variant of a device has the same connect IQ version as the WW device, but the device file still indicates that the APAC variant has a lower version than it really does. (IOW, the real APAC device's CIQ version is up to date, but the device file is out of date)

    My 2 y/o Forerunner 955 is an API 5.0.0 device. This seems to be the very latest, even on the most recent Garmin Watches like the Fenix 8 (the VSC manifest editor suggests there is a 5.0.1 now). So my watch should be compatible with all of SYSTEM 7 and likely the upcoming SYSTEM 8 features? Is this correct?

    The way to know for sure is:

    - wait for the SDK device configuration file to be updated (fr955/compiler.json)

    or

    - look for an official Garmin announcement

    or

    - read the tea leaves (I'm guessing every CIQ 5 device is getting System 8)

    or

    - look at the beta firmware announcements or community discussions for your device (or look at your device, if you're on the beta program.)

    For FR955 in particular, the latest beta indeed has CIQ 5.1.0 (which apparently corresponds to System 8).

    And CIQ System 8 was actually leaked in one of Fenix 7 beta changelogs before it was even announced here.

  • As a side note:

    [*] One problem with trying to use minApiLevel in the past to gate devices by "system level" is that older system levels <= 6 supported two "tracks" of devices - CIQ 3 and CIQ 4 - which was the whole point of creating the system level scheme in the first place.

    For example, System 6 was CIQ 3.4.x (for CIQ 3 devices) and CIQ 4.2 (for CIQ 4+ devices). Suppose you built an app at a time when some devices where still configured as 3.3 and 4.1, but others were configured as 3.4 and 4.2 (this is hypothetical, but I could see this happening with APAC vs WW devices). There would have been no way to include all 3.4 devices but also to exclude all 4.1 devices, using minApiLevel.

    Ofc this is a moot point now since the latest system levels (7 and 8) have left CIQ 3 devices behind (which ironically means that the system level scheme is no longer necessary) and all the CIQ 4+ device configs have been updated to CIQ 5.

    So if you want to target older system levels, it's actually ok to use minApiLevel now.

    For example, minApiLevel = 3.4 should now target system 6 (3.4 and 4.2), since all CIQ 4+ devices are now configured as CIQ 5 in the device files, so it would be impossible for any hypothetical user with 4.0 or 4.1 firmware to install your app anyway. (The store prevents users from installing your app if they have firmware with lower CIQ support than the connectIqVersion configured in the device file at export time.)

    For the record:

    System 4 = CIQ 3.2 for CIQ 3 devices, CIQ 4.0 for CIQ 4+ devices

    System 5 = CIQ 3.3 for CIQ 3 devices, CIQ 4.1 for CIQ 4+ devices

    System 6 = CIQ 3.4 for CIQ 3 devices, CIQ 4.2 for CIQ 4+ devices

    System 7 = CIQ 5.0 for CIQ 4+ devices

    System 8 = CIQ 5.1 for CIQ 4+ devices

  • You might know. Is there a way to tell if a device is CIQ 5.0 or above?

  • You can use "has" for something specific, or use monkeyVersion to get the exact version of CIQ on the device at runtime

  • System.DeviceSettings.monkeyVersion

    Or on the actual device? Menu > System > About

  • I don't believe that "has" can tell the difference between foreground communications or background communications.  The former which only became a valid data field permission with CIQ 5.0.0.  

  • As I said, monkeyVersion is another option.

  • The only option it seems and that has is a red herring.

  • Thanks, comes back as an array, so I can just get first occurrence in array for the purposes I need.