Three years have passed, and Garmin has not yet planned to fix the bug on watches in Asia

APAC and watchfaces - Discussion - Connect IQ - Garmin Forums

fenix 6 APAC devices - Discussion - Connect IQ - Garmin Forums

Packager warnings, should I take these serious? "CIQ ver: '3.2.6' is being ignored by the package tool" - Discussion - Connect IQ - Garmin Forums

This is obviously a common problem. Currently, most old users in Asia are stuck on ciq 3.2.6, but in fact their watches have already received system updates above 3.3 or 3.4.

Data such as STRESS and bodybattery have been displayed normally in the secondary menu for a long time.

Fr945\245\645 and other machines are widely used in Asia, so you can consider fixing this problem.

The minimum limit is 3.2.6, and Asian users can download the watch face, but the data is missing.

Or choose 3.3.1 to completely abandon Asian users.Garmin has hundreds of models, which makes maintenance difficult, but this does not require any major changes. All you need to do is correctly identify the user's system version.

Set the minimum apiLevel to be 3.2, then use "has" to check for a specific API call.

On current SDKs, use the 

-disable-api-has-check-removal

compiler flag so has is resolved at run time, and not compile time. 

It was cases like this where a few of us requested that flag be added.

3112676 said:

As a result, many data on the watch cannot be displayed correctly. For example, STRESS and BODYBATTERY. If you skip the download from the Garmin store and directly copy the prg file into the watch with a data cable, the watch face can run normally.

This is pretty interesting.

I'm not saying I don't believe you, but I'm curious what the exact mechanism would be for limiting functionality by API level, but only for store downloads and not sideloads. If I'm understanding you correctly, you believe that this is happening due to connectIQVersion in the device files? I didn't think that having a too-low connectIQVersion in the device files would limit functionality on a real device (assuming ofc that the part numbers in question are not excluded from the build due to a too-high minApiLevel in the manifest.)

Normally I wouldn't recommend this, but have you tried manually changing connectIQVersion (and ideally, firmwareVersion) in the applicable device files (after making a backup)? At best, if the given CIQ/firmware version combo exists for APAC versions, then maybe it would fix your problem. (Only assuming that it really has something to do with the device files, which is something I'm not convinced of.)

I think the key is to find out the actual values to use for connectIQVersion and firmwareVersion. You could just copy the values from the WW part number, but they might be slightly too high, if APAC is still slightly behind WW. Or you could find out appropriate values from your APAC end users who actually have newer firnware/CIQ.

Normally I would assume that if you set your your min API level to 3.2 (or lower), as jim_m_58 suggested, everything should work as expected on devices which actually have a higher API level, regardless of what the device files say.

EDIT: in light of the clarification where some dev said they avoid the problem by not using has checks, I'm going to assume that the problem was always due to not using --disable-has-checks, as jim_m_58 suggested.

I only realized this problem when the user took a screenshot and told me that his watch was already 3.4.1

3112676 said:

Unzip the iq file, you will find it contains prg files for 3.2.5 and prg files for 3.3.1 for FR245. The system version of watches in Asia Pacific is different from that of European and American models, usually a few months or more behind. Then they forgot about these devices in one of the updates. Mistakenly pushed the 3.2.5 file to the watch with a higher level of ciq.

Right so I'm just wondering whether the problem is with the CIQ SDK device files, the firmware on the watch, or both?

Based on your statement that a sideload works properly, while a store install does not, it seems like the problem is only with the CIQ SDK device files and the firmware does support the level of CIQ that it claims to?

Based on what you're saying above, do you believe that the connectIqVersion in the manifest actually causes the PRG on the device to work differently at runtime? As in, the device actually limits the CIQ functionality to 3.2.5 simply because that's what's in the manifest.

Tbh I didn't think it works this way, but if this is the case, you could this theory by manually editing one of the device files, to bring the connectIqVersion (and ideally, firmwareVersion) in alignment with what's actually available on APAC FR245.

Or are you saying that the firmware on APAC FR245 claims to support 3.4.1, but actually only supports 3.2.5? That's not my understanding of what you meant, since you said that a sideload works fine.

It also doesn't seem like compile-time has checks are coming into play here, since again, you said that a sideload works fine but a store install does not.

Maybe it would be worth filing a bug report for this. Might also be good to include details about how CIQ 3.3/3.4 features work fine for a sideloaded PRG and not a PRG installed from the store (along with some code to reproduce the issue).

I would be very interested to hear what the CIQ team would have to say about this.