Acknowledged
1 day 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
Parents
  • 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?

Comment
  • 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?

Children
No Data