Acknowledged
4 months ago

bug: venusqm CIQ version isn't updated

On a physical venusqm the API level is 3.3.6, but in compiler.json it's only 3.3.1 and here: https://developer.garmin.com/connect-iq/compatible-devices/ it's only 3.3.0

flocsy🤠
Parents
  • 4 months ago
    Of course, the solution is to modify each json and change the version
    , don't do this. You risk crashing your app on devices this way.

    If app can crash just before I rebuild it without any changes in source code it means new firmware can have not only API but also duplicated api (for app built the older SDK and the newest). Or upgrading of firmware upgrading installed app to the newest CIQ.

    Sorry to address this real late but I can easily think of a scenario where editing compiler.json will crash the device without either of the above statements in bold being true.

    Quite simply, if you edit compiler.json to allow an app to be installed on a device with older firmware, it runs the risk of invalidating compile-time API has checks which would normally prevent an app from crashing when you try to use an API feature that isn't present. This will happen if you change firmwareVersion to an older firmware without also changing connectIqVersion to the corresponding CIQ version for the older firmware.

    --

    Details:

    For example, right now fr955/compiler.json has the following versions for its only part number:

    "connectIQVersion": "5.1.0",
    "firmwareVersion": 2222,

    This means that if I build an app for fr955, the minimum firmware to install the app on fr955 is 22.22, and the device is guaranteed to have at least 5.1.0.

    Now let's say I change firmwareVersion to something like 1918, but I don't change connectIqVersion. Now the app can be installed on devices that have CIQ < 5.1.0. Maybe CIQ 5.0 or even 4.x.

    Let's also say that I have optimization on, but I don't use the --disable-api-has-check-removal compiler flag.

    And let's say my app uses Toybox.Notifications (new for 5.1.0), and uses a has check like Toybox has :Notifications before accessing Toybox.Notifications.*. The has check will be resolved at compile-time, but how?

    I tried to answer this question by looking at the value of Toybox has :Notifications in the simulator, with optimization set to the highest level and without --disable-api-has-check-removal (although it shouldn't matter for the sim, since presumably the sim and the compiler have the same idea of the capabilities for a given device).

    - fr945 (CIQ 3.x): Toybox has :Notifications == false (of course)

    - fr955 (CIQ 5.1.0, unedited device file): Toybox has :Notifications == true (of course)

    - fr955 (compiler.json edited to change firmwareVersion to something less than 2222 (e.g. 1918))\: Toybox has :Notifications == true (as expected)

    - fr955 (compiler.json edited to change connectIqVersion to 5.0.0): Toybox has :Notifications == false (as expected)

    --

    The problem I mentioned above doesn't just have to apply to the *latest* API features. What if I backdate firmwareVersion to some firmware which only supports CIQ 4.1, but I accidentally change ciqVersion to "4.2.0"? Now if my app uses a compile-time has check for a CIQ 4.2.0-only feature, the check will be true and the app could crash at runtime because it doesn't really have that feature.

    If you backdate firmwareVersion manually, how will you know what version to use? And how will you know the corresponding connectIqVersion to set? Will you search all the device forums to look for a suitable firmware version? Of course the official changelogs don't say what the CIQ version is - if you're lucky, maybe some dedicated user will have a thread with that info.

    It seems that instead of editing compiler.json by hand, the real solution is to restore it from a backup, or ideally, have Garmin officially distribute old device files (as discussed in a couple of other threads.)

Comment
  • 4 months ago
    Of course, the solution is to modify each json and change the version
    , don't do this. You risk crashing your app on devices this way.

    If app can crash just before I rebuild it without any changes in source code it means new firmware can have not only API but also duplicated api (for app built the older SDK and the newest). Or upgrading of firmware upgrading installed app to the newest CIQ.

    Sorry to address this real late but I can easily think of a scenario where editing compiler.json will crash the device without either of the above statements in bold being true.

    Quite simply, if you edit compiler.json to allow an app to be installed on a device with older firmware, it runs the risk of invalidating compile-time API has checks which would normally prevent an app from crashing when you try to use an API feature that isn't present. This will happen if you change firmwareVersion to an older firmware without also changing connectIqVersion to the corresponding CIQ version for the older firmware.

    --

    Details:

    For example, right now fr955/compiler.json has the following versions for its only part number:

    "connectIQVersion": "5.1.0",
    "firmwareVersion": 2222,

    This means that if I build an app for fr955, the minimum firmware to install the app on fr955 is 22.22, and the device is guaranteed to have at least 5.1.0.

    Now let's say I change firmwareVersion to something like 1918, but I don't change connectIqVersion. Now the app can be installed on devices that have CIQ < 5.1.0. Maybe CIQ 5.0 or even 4.x.

    Let's also say that I have optimization on, but I don't use the --disable-api-has-check-removal compiler flag.

    And let's say my app uses Toybox.Notifications (new for 5.1.0), and uses a has check like Toybox has :Notifications before accessing Toybox.Notifications.*. The has check will be resolved at compile-time, but how?

    I tried to answer this question by looking at the value of Toybox has :Notifications in the simulator, with optimization set to the highest level and without --disable-api-has-check-removal (although it shouldn't matter for the sim, since presumably the sim and the compiler have the same idea of the capabilities for a given device).

    - fr945 (CIQ 3.x): Toybox has :Notifications == false (of course)

    - fr955 (CIQ 5.1.0, unedited device file): Toybox has :Notifications == true (of course)

    - fr955 (compiler.json edited to change firmwareVersion to something less than 2222 (e.g. 1918))\: Toybox has :Notifications == true (as expected)

    - fr955 (compiler.json edited to change connectIqVersion to 5.0.0): Toybox has :Notifications == false (as expected)

    --

    The problem I mentioned above doesn't just have to apply to the *latest* API features. What if I backdate firmwareVersion to some firmware which only supports CIQ 4.1, but I accidentally change ciqVersion to "4.2.0"? Now if my app uses a compile-time has check for a CIQ 4.2.0-only feature, the check will be true and the app could crash at runtime because it doesn't really have that feature.

    If you backdate firmwareVersion manually, how will you know what version to use? And how will you know the corresponding connectIqVersion to set? Will you search all the device forums to look for a suitable firmware version? Of course the official changelogs don't say what the CIQ version is - if you're lucky, maybe some dedicated user will have a thread with that info.

    It seems that instead of editing compiler.json by hand, the real solution is to restore it from a backup, or ideally, have Garmin officially distribute old device files (as discussed in a couple of other threads.)

Children
  • 4 months ago in reply to FlowState

    Of course you are right on condition you add something to source code or something is deleted from API with the new firmware.

    When your source code doesn't change at all, what is the reason that compilation with the new sdk limit the watches by them firmware? 

    Example (false data)

    2022-02 F7 in market 2022'01, firmware 13.12 sdk 3.4, app tested and build for f7

    2025-03 f7 firmware 20.22 (the same in *.json), sdk 8.1, the same source code (I don't use any new features above sdk 3.4)  - and only user who has 20.22 can download app. Why?

    I Rrestore devices form 2022-02, add some code and build with sdk 3.4 for the  f7 with minimal version of 13.12. Putting app in to the store for every user of f7. Possible? Yes, so why can't do the same with sdk 8.1? 

    Every developer have to do something if he wants to support a different device (jungle, has), the same is with the different firmware. I don't care about version of firmware, for me important is CIQ version or rather minimal sdk I put into manifest. 

    So limiting devices by firmware version means - the current firmware is not compatible with the minimal version of sdk - and isn't the truth just because I use my own apps in beta version build months/years ago.

    Using the new sdk is obligatory if you want to support the newest devices (not firmware) because the old one doesn't know the new devices.