Side effects of changing minimum CIQ version from 2.4 to 3.0

A good question that isn't covered in the docs and can only be explored on a device.
FWIW I deployed some 3.0 code :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN


onto my 2.4 VA-HR and it crashed at runtime.

RaceQs that sounds like a bug in the simulator since the docs actually say that symbol is only available in 3.0.0 and up. Not sure if this has been reported, but maybe it should be.

ekutter Note this D2 Charlie bug from November:
https://forums.garmin.com/forum/deve...-support-menu2

Basically D2 Charlie supports 3.0.0 (at minimum), but returns false for "has Menu2". I think this is a problem in both the sim and the real device.

I don't know how you to want to handle this. The way I handled it:
- In an app that requires Menu2, I excluded D2 Charlie support. (Sucks to be them). One day when I'm sure the bug is fixed (not sure how I'll know), I might put it back in.
- In an app that had optional Menu2 support, I used a runtime "has" check to detect Menu2 support. (Which is the only way I could've done it anyway, unless I hardcoded exclude annotations in the jungle file, to save memory.)

The question is, what are the side effects of changing the minimum version for users that may not have the latest fw on their devices? Again, all devices my app supports support 3.0 in the latest fw. What happens if someone with an older firmware wants to install it? Will the CIQ store prevent them from installing it until they upgrade their device? Will they not even see the update? Do I need to have code in my app that basically states they should upgrade their fw if they want to use the app?

I believe that users with devices with old firmware won't be able to install or update your app. (*)

A great example is the Japanese "Foreathlete" watches (230J, 235J, etc.). None of them support 1.4, so if your minimum SDK is 1.4, those users won't be able to download your app.

(*) One thing I'm not 100% sure about is whether the store excludes devices based on BOTH of:
A) Device part-number plus highest known firmware for that part-number
B) ACTUAL firmware on the device

I know it uses A) for sure, as the compiler/packager will exclude part numbers with max CIQ that is too low. You can even see this in the build log, if you select targets where CIQ support differs based on part number. e.g. 230 vs 230J.

I believe it uses B) as well, because there has been a recurring bug when the firmware on a device (e.g. 935) was believed to be too low by the store, due to the devices.xml file not being updated, and users trying to download certain apps would get a message that says "You need to upgrade your firmware" even though they had the latest firmware. This has happened to me personally, and there have been many reports on the forums.

So I believe the only time you need to tell users to upgrade their firmware is if there is a known bug that needs to be fixed, which is not keyed to your minimum CIQ version. A great example would be the D2 Charlie bug. D2 Charlie already supports 3.0.0, but the Menu2 support isn't there, apparently....

Thanks for the responses. Good to know about the D2 Charlie. In my case, I don't really care if it doesn't work on older devices as I've got a "good enough" version of the app for them. I just don't want to be breaking anybody that has already installed this new version of my app (they are actually two different apps as far as the store is concerned).

Why this still has not been fixed… Yes, the :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN perfectly works in the Forerunner 735xt simulator, looks like there is no problem, but crashes on the device.

This needs to be fixed in the simulator.