sdk 7.4.1 There are still problems

1341842 said:

But I can't download the watch face in the store which requires minimum 3.3.1

I'm interpreting this to mean you set minApiLevel in your app manifest to 3.3.1.

According to the 945 device file (...\ConnectIQ\Devices\fr945\compiler.json), the APAC (Asia-Pacific) part number for 945 has connectIQVersion equal to 3.2.5, while the worldwide part number has a connectIQVersion of 3.3.1. For all intents and purposes, connectIQVersion in the device file specifies the minimum CIQ version that is guaranteed to be on the device. (Because the store will refuse to allow the app to be installed on any device with a lower CIQ version).

If you set minApiLevel to 3.3.1, then the APAC part number will be excluded at build time [since 3.3.1 is greater than 3.2.5], which explains why you can't install the app on a Chinese FR945. In this case, you should get a warning about excluded part numbers at export time.

Unfortunately, sometimes the connectIQVersion in the device file lags behind the CIQ version on the real devices. See the following discussion, for example: forums.garmin.com/.../1860907

The solution is to set minApiLevel to 3.2.5 (or lower). If your app relies on certain features which are available in 3.3.1 but not 3.2.5, use has to gate the features in code, and specify the compiler option --disable-api-has-check-removal (this option will ensure that the has checks are evaluated at run-time, and not compile-time).

thank you 。 But I mainly rely on the third-party tool WFB to make the dial, it cannot be set--disable-api-has-check-removal，

I can't avoid this problem, and the generated iq file cannot be modified again

So I need Garmin can improve this problem.

Watchface Builder for Garmin – Creating your own watchface app for garmin device without coding

As you can see from the link I posted, Garmin is aware of the issue. But nobody knows how long it will take for them to fix it.

Since you're relying on generated code, the code generator would also have to insert the has checks (if they don't already exist) to use my approach.

A simpler approach (which could be implemented on the code generator side) would be to allow the dev to override connectIQVersion in the device file. I think this would be very dangerous unless you can also override firmwareVersion to a value that corresponds to a real firmware that has the CIQ version you want. Otherwise it *might* be possible to install the app on a device which has a lower CIQ version than expected, which could lead to crashes. (My guess is that the store really only gates apps based on firmareVersion, and not connectIQVersion, but those two values are typically matched in the device files.)

If you want to overcome this problem before Garmin makes a fix, you'll have to ask the watchface builder dev to make one of the two suggested changes:

1) gate relevant features using has and add --disable-api-has-check-removal to the compiler flag. Adding the compiler flag would be easy, gating the relevant features would not. This would be the proper way to fix things if you were writing the code by hand, though

2) allow the user to override connectIQVersion and firmwareVersion for a given part number in a given device file. This is dangerous, but it could be an "easy" way for you to get what you want. (Provided you know the firmware version for the CIQ version you want.)

Thanks,

WFB does not provide source code, only iq files. I am not sure if my changes to the iq file will pass the verification process.

From the current error, Garmin actually only needs a few simple steps and a few numbers to correctly correct the software version of the device. Maybe it can be solved in half an hour. But the biggest question is whether they do this in order, they have a lot of unresolved bugs. It may also be a long way off.

Without source code, you also can't research/debug anything that shows in an ERA report, so you can't really support it if there are crashes..  

Do you know which SDK was used to build the iq file?

3112676 said:

But there is no further operation, like --disable-api-has-check-removal

If the generated code already uses has checks where necessary, then you would only need the watchface builder dev to add the ability to set the --disable-api-has-check removal flag, and your use case should be fulfilled.

(Here I am assuming that you need to use 3.3.1 features in your app.)

This is something you should take up with the dev, unless you are willing to wait for Garmin to resolve this issue.

I tried to contact them, but got no response. Maybe the developers thought it was not enough to destroy the stability of the entire software for the needs of a small group of people. I can understand that, after all, this is not a WFB bug, so I tried to seek help on the official forum.