Acknowledged
22 hours ago

Many devices in Asia cannot recognize the system version properly

Corrected the problem that the SDK could not recognize Asian models. Asian FR245, FR945, endura and other devices have been updated to 3.3.1 or 3.4.1, but are still recognized as 3.2.6.
Once the watch face is exported with the minimum setting of 3.3.1, Asian users will not be able to download it,
even if their watch supports it. A large number of users said that they could not find the watch face, even if their watch was in the compatible list.
At the same time, their software version in the photo is already 3.3.1 or has been upgraded to 3.4.1 long ago.

 

3112676
  • 22 hours ago

    > Someone in the same discussion mentioned that their app works properly for sideloads and not when installing from the store, meaning that for them, has checks are being evaluated at runtime for their sideloaded app, but not for their app when installed from the store.

    Never mind, flocsy explained it:

    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.

    This does highlight a certain limitation, where it's not possible to build a sideload for a given part number (i.e. APAC part number instead of the default WW part number), unless you edit device files by hand.

  • 1 day ago

    > And maybe the compiler could emit a warning/notice about has checks, but only when they're actually being removed at compile-time?

    To be clear, I mean there could be warning/notice for each specific line where a has check is removed at compile-time.

  • 1 day ago

    To Garmin: note that as per this discussion, devs are apparently being caught by the relatively new behavior where has checked are removed at compile time, based on the CIQ version of the target device and part number. Yes, we can use the --disable-api-has-check-removal compiler option to revert to the old behavior where has checks are evaluated at runtime, but not every dev may know about this.

    Someone in the same discussion mentioned that their app works properly for sideloads and not when installing from the store, meaning that for them, has checks are being evaluated at runtime for their sideloaded app, but not for their app when installed from the store. I'm guessing this has something to do with debug vs. release or optimization disabled vs optimization enabled, but it would also be nice to get some feedback from the compiler about how has checks are being handled, for any given build. Like an informational notice (e.g. "has checks are being handled at compile-time/runtime") with a link to a web page with further information.

    I realize that would be a very unusual thing to do and it's probably not going to happen. (Imagine if the compiler emitted a notice about every single quirk that catches devs by surprise). So maybe this information could be added to a developer FAQ?

    And maybe the compiler could emit a warning/notice about has checks, but only when they're actually being removed at compile-time?