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🤠
  • 4 months ago

    This was fixed in today's update of the device files (though not in the link yet)

  • 4 months ago

    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.

  • 4 months ago in reply to FlowState
    But of course, there is no reason for devs to rebuild their apps simply because CIQ/firmware versions were updated in device configs, right?
    Nope. The only reason I can think of right now is if there's a compiler fix listed in the release notes that you want in your app. For instance, an optimization that improves memory usage or application speed.
    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.
  • 4 months ago

    And if the intention is what Kyle writes, the version of each called system function (taking HAS into account) should be checked during compilation and only its use should limit devices when downloading applications from the store.

    This is an interesting idea, but I'm not sure it's feasible, because there are many ways for a dev to conditionally call system functions, other than using a has check for the function in question, and it's not always going to be clear to the compiler whether the condition is true or false for a given device.

    e.g. Consider an app that contains the following code:

    Assuming this is the only code in the app which depends on CIQ 3.4 (or higher), I would like the app to be available to older devices with CIQ 2, as well as newer devices. But according to your proposal, the compiler will probably decide that it should only be available for devices with CIQ 3.4 or higher.

    I'm not claiming this is good code or realistic code, but devs have asked for ways to detect CIQ 5 at runtime (for example), so I don't think it's impossible for code that's *similar* to this example to appear in a real CIQ app. And ofc we can't assume that devs will write the most optimal code for every situation.

    TL;DR I don't think it's a good idea for the compiler to try to analyze the code to determine what CIQ API level is required. I think that's what minApiLevel (formerly minSdkVersion) in the manifest is for (as you said).

  • 4 months ago

    And that's exactly what I wrote about, it only to force the users to download new firmware.
    Limiting the minimum version just because there's a new API?
    And what if the developer doesn't need this API?
    And what if the developer wants to use HAS and support the old firmware?
    Of course, the solution is to modify each json and change the version.... Otherwise, building a new version just because, for example, a new device has appeared (e.g. descent G2) immediately causes that many users will not download the new version for no reason.
    Only the minSdkVersion in the manifest should be used to eliminate devices.

    And if the intention is what Kyle writes, the version of each called system function (taking HAS into account) should be checked during compilation and only its use should limit devices when downloading applications from the store.