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

Brandon.ConnectIQ  Can this problem be fixed?

Watchface compiled with 4.2.1 cannot read bodybattery on a real device - Connect IQ Bug Reports - Connect IQ - Garmin Forums

This is a previous bug report from another developer, which is obviously also related to this issue

3112676 said:

On the contrary, some watch face designers make it display correctly by ignoring "has"

This goes back to what jim_m_58 said about using the --disable-api-has-check-removal compiler flag (developer.garmin.com/.../)

The history behind this is has checks used to be evaluated at run time (so they would continue to work if a device's API level was upgraded), then they were changed to be evaluated at compile time (based on the CIQ version in SDK device files), for the sake of efficiency.

Since the device files for APAC FR245/etc. specify an older CIQ version than what's really on the devices, certain features will be inappropriately disabled if you gate them using has.

I think the solution here should be to simply use --disable-api-has-check-removal, assuming that you already use has to determine relevant feature support (e.g. stress and body battery).

Ideally you shouldn't have to manually change the device files after all. I didn't think it was a good idea, but I made that suggestion based that on your comment that sideloading works, but not publishing to the store. I'm still not sure how this could be the case, unless has checks are not being optimized for the sideload, but they are being optimized for the release version.

Even though the device files *should* be updated, I do think your app should work correctly if:

- you target a minApiLevel of 3.2 (or whatever the minimum API level is for all your app's devices, including APAC part numbers)

- use has checks

- use the --disable-api-has-check-removal compiler flag

Basically what jim_m_58 said.

My understanding of connectIqVersion and firmwareVersion in the device files is that they only serve two purposes:

- to exclude devices/part numbers from the app export based on minApiLevel in the manifest. (e.g., if you set minApiLevel to 3.3, then some of your APAC devices will be excluded)

- to force the end user to have that CIQ version / firmware version at a minimum, in order to install your app. (Otherwise, they get an error message asking them to update.)

So if I'm not mistaken, as long as you use --disable-api-has-check-removal, the only reason you would need the device files to be updated is if you wanted to ensure all your APAC users are running newer firmware (supporting 3.3 or 3.4).

FlowState said:

your comment that sideloading works, but not publishing to the store.

FlowState said:

I'm still not sure how this could be the case, unless has checks are not being optimized for the sideload, but they are being optimized for the release version.

IOW, I don't think the difference is due sideloading vs installing from the store per se, I think the build is working differently when when a sideload is built as opposed to an app export. Could be as simple as the difference between debug and release, or between optimization disabled and optimization enabled.

Thanks. Maybe it works.

Could you clarify exactly under which circumstances API-related has checks will be optimized away at compile-time? 

Does it happen when optimization is enabled? Or is it enabled for release builds and not debug builds?

I’m trying to figure out why devs have reported that this problem — apparently caused by has check optimization for APAC part numbers with old CIQ version in device files — only happens for store installs and not for sideloads.

I realize that it’s always an option to use the —disable-api-has-check-removal flag, but I’m also curious about how it works normally.

Just guessing:

Let's say there are 2 part numbers, one for WW with CIQ 3.4.0 and one for APAC with CIQ 3.2.0

When you export a project then a prg is being compiled for each part number. Because of the optimized out has check the APAC devices don't have the code.

When you build for a device, then I think it builds for the 1st part number, that is usually the most advanced (CIQ 3.4.0) so when you side load it to an APAC device it has the code for the has check, and thus it works.

Oh right that is definitely the most plausible explanation. Can't believe I didn't think of that haha.

There isn't even a way to select part numbers to build for, except indirectly, by specify a minApiLevel that excludes certain part numbers. But at best that would exclude APAC part numbers in favour of WW part numbers, and not the other way around.

So it's no wonder that people who test on APAC devices would see different behavior for sideloads vs store installation, due to the newish behavior where API-related has checks are optimized away at compile time.

Oh well, at least for most newer devices, there's a single firmware for WW and APAC.