Difference between CIQ and API version

Just wondering, in the compiler.json file for each device, there is a "connectIQVersion" with a version number. In the https://developer.garmin.com/connect-iq/compatible-devices/ page, it shows a API level that is somewhat but not always the same as the CIQ version. I assume the "connectIQVersion" means the exact CIQ version the device has the API is what the device is compatible with, right? However, some devices like the VenuD (Mercedes, I believe), has a CIQ of 3.2.6 and yet its API is 3.3, Shouldn't be API 3.2?

Also, what happens to CIQ 4? All I see with that CIQ level are System6 and System7 "previews". Anybody knows why?

0 flowstate 8 days ago

CIQ version and API version mean the same thing. [*]

However, the compatible devices page you linked only shows the first two version components (e.g. 3.2) and not all three components (e.g. 3.2.6).

To answer your other questions quickly:

- venud (the ciq device) isn't in the compatible devices page. venu is though.

Ofc it's hard to tell from that page, but you'll note that venud is indeed a Mercedes-Benz variant of Venu (1st gen), yet the compatible devices page doesn't have the phrase "Mercedes-Benz" in the description for Venu.

Also note that display name for venu/compiler.json is "Venu®" , which *exactly* matches what's on the compatible devices page.

- All CIQ 4 devices have been upgraded to at least CIQ 5.0

[*] There was actually a time when the SDK version was in sync with the CIQ/API version, which is why minApiLevel in manifest.xml used to be called minSdkVersion, and why ConnectIQ/SDKs/SDK_VERSION/bin/compilerinfo.xml has an element called targetSdkVersions, but it really means targetApiVersions. Btw you can look at compilerinfo.xml:targetSdkVersions to see the "official" mapping from system level to API level.

Iirc, when the SDK and CIQ versions were in sync, there wasn't even a concept of API level. That was only introduced once the SDK version went out of sync with the CIQ version. Possibly at the exact same time that the concept of System Levels was introduced. The reason for system levels was to support both CIQ 3 devices and CIQ 4 devices at the same time, with new CIQ versions and features. CIQ 3 devices wouldn't get all the new features, but they would get some new features. (To be clear, the rule was that no CIQ 3 device would ever get CIQ 4; CIQ 4 was only for newer devices. But Garmin wished to continue to support CIQ 3 devices with new CIQ releases)

So when CIQ 4.0 was released (for new devices only), Garmin needed a way to group that with existing CIQ 3 devices, which would be receiving a CIQ 3.2 update, with some new features. So they invented the system level concept and defined System 4 as CIQ 3.2 for CIQ 3 devices, and CIQ 4.0 for newer devices.

System 5 was CIQ 3.3 / 4.1.

System 6 was CIQ 3.4 / 4.2.

But System 7 is CIQ 5.0 only. All CIQ 4 devices received CIQ 5.0 and CIQ 3 devices were left behind.

System 8 is CIQ 5.1

Ofc Garmin doesn't explain any of this. And they rarely explained what each system level meant. There was a lot of confusion amongst bloggers, users and devs around this topic, even devs who thought they understood.

You'll also note that it isn't possible to select a system level (for levels 4, 5 and 6) using minApiLevel in manifest.xml.

For example, say you wanted to target System 6 when it was new. You couldn't use minApiLevel of 4.2, as that would incorrectly exclude CIQ 3.4 devices. But you couldn't use minApiLevel of CIQ 3.4, because that would incorrectly include CIQ 4.1 devices. This is kind of a moot and abstract point, as CIQ 3 and 4 devices were mostly being updated to the latest CIQ (for their respective branches) anyway, although we can can see from the compatible devices page / compiler.json that not all of them have the latest. It really has been made moot since all previously CIQ 4 devices are now on CIQ 5, so you really can use a min API level of CIQ 3.4 now, to target system 6 (or higher).

This is also a problem for the docs - if a doc says something like available since CIQ 3.4, that really means available since CIQ 3.4 (for CIQ 3 devices) and available since 4.2 (for CIQ 4 devices) but that isn't explained anywhere. This is also a moot point now.

0 flowstate 8 days ago

SylvainGa said:
I assume the "connectIQVersion" means the exact CIQ version the device has the API is what the device is compatible with, right?

I assume you are referring to "connectIQVersion" in the partNumbers array in ConnectIQ/Devices/DEVICE_ID/compiler.json

The "connectIQVersion" / "firmwareVersion" for a given part number isn't the exact CIQ version for that part number has. Users aren't forced to update their firmware, so it's impossible for Garmin to guarantee that.

Furthermore, some users have beta firmware, so they may have a newer [for that device *] version of Connect IQ which isn't widely released yet.

[* here when I say device, I speak of a generic customer-facing device/model, not a specific CIQ device ID that you select in manifest.xml or see in ConnectIQ/Devices.]

When I want to speak specifically of "CIQ devices" - as in the device IDs in manifest.xml / folders in ConnectIQ/devices, I will say "CIQ device". A CIQ device also maps 1-to-1 with a hardwarePartNumber, so we can consider these to be unique hardware platforms.]

[1/x]

0 flowstate 8 days ago in reply to flowstate

Actually "connectIQVersion" / "firmwareVersion" for a given part number in a CIQ device's compiler.json is just the *minimum* CIQ / firmware combo that's guaranteed to be present on the device, if you build an app now (with the current contents of compiler.json.

When you export your project, the compiler puts `firmwareVersion` for each part number into the manifest as minFirmwareVersion (or something similar), and when a user tries to install your app (or update to the new version you built), the store will check to make sure they have at least that firmware version.

Since Garmin always updates compiler,json so that connectIQVersion and firmwareVersion are in sync, this also means that connectIQVersion will be the minimum guaranteed CIQ version on the device, for newly built apps.

This is why users with old firmware are unable to install apps that were updated recently, but they can still install old apps

[2/x]

0 flowstate 8 days ago in reply to flowstate

Also, to be clear, Garmin never updates connectIQVersion / firmwareVersion until the firmware in question is 100% rolled out and has been out for a while.

So:

- connectIQVersion is not necessarily the latest version of CIQ on a given device

- connectIQVersion is the min CIQ version your app will see on a given device, if you export the app today. (because users with an older firmware / ciq version will not be allowed to install your app)

[3/x]

0 flowstate 8 days ago in reply to flowstate

SylvainGa said:
However, some devices like the VenuD (Mercedes, I believe), has a CIQ of 3.2.6 and yet its API is 3.3, Shouldn't be API 3.2?

I think the simple explanation in this case is that the device referred to in CIQ as venud (displayName = "Venu® Mercedes-Benz® Collection") is not in the compatible devices page at all.

What you see in the compatible devices page for "Venu" is probably the venu CIQ device. Note these are separate CIQ devices. (For later generations, the regular Venu X and Mercedes-Benz Venu X are multiple part numbers grouped under the CIQ device like venu2, which has 4 part numbers - Venu 2 WW, Venu 2 APAC, Venu 2 Mercedes-Benz WW, Venu 2 Mercedes-Benz APAC)

Furthermore, like many other devices which have WW/APAC variants, the CIQ version for venud's WW part number is not the same as the CIQ version for its APAC part number.

Unlike other devices, venud's WW part number is actual behind its APAC part number: WW has 3.2.6 while APAC has 3.3.6.

Regardless, they are different which again sort of highlights the limitations of the compatible devices page. That page does not break devices down by part number / APAC vs WW variants, either. It just has a bunch of high-level "customer-facing" model names without specifying which CIQ devices / part numbers they refer to. (Although you can guess that each variant roughly corresponds to a single CIQ device.)

------

Speaking of mapping part numbers to actual customer-facing models, I wrote a bunch of stuff about that here:

https://forums.garmin.com/developer/connect-iq/f/discussion/420066/watch-app-cannot-be-downloaded-on-device-device-is-listed-as-compatible-in-manifest-and-on-the-website-but-not-in-the-mobile-app

The TL;DR is you can use this API to see the description in the store website for a given part number (as seen in the compatible devices (*) tab):

[https://apps.garmin.com/api/appsLibraryExternalServices/api/asw/deviceTypes]

You can also use it to get the store url which shows only apps for that device (*). This is handy for devices like Fenix 8 whose urls couldn't be guessed (ppl assumed there were no specific store urls for that family of devices).

0 flowstate 8 days ago in reply to flowstate

I've said this before, but I don't like that CIQ revolves so much around CIQ device IDs, each of which corresponds to a single hardware part number, and each of which can have 1 to many (software) part numbers (which CIQ also revolves around), but they don't explain any of this stuff at all.

Like what the info in compiler.json means, how to map part numbers to customer-facing product names, or any of the related stuff.

Yet iirc, various sections of the docs refer to part numbers (without explaining them), and so does the compiler.

Speaking of the ambiguity with the word "device", the compiler refers to devices and part numbers interchangeably during the export process.

But ofc, elsewhere, a CIQ device (as in fr935, fenix6 or fenix6pro) is referred to as a "device" (or sometimes a "product").

Not only the nomenclature not explained, it's also not consistent.