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

There are many FR245\ FR945\ ENDURA\ FENIX6 devices in the Asia-Pacific region. Their SDK has been updated to 3.3 or above. Some devices have already been updated to 3.4, but Garmin still mistakenly identifies them as earlier versions such as 3.2.

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.

How to make watch face compatible with ASIA models? - Discussion - Connect IQ - Garmin Forums

 I found that someone reported this problem three years ago. But no one has dealt with it. If I limit the minimum SDK version of watchface to 3.3.1, a large number of Asian users will not be able to find wf. Their screenshots tell me that their devices are far beyond 3.3.1.

  • 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.

  • 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.