Check for has :Weather returns true although API level 3.1 doesnt have it

The main reason to use minSDK is preventing to download app to devices not fulfilled version.

If you have minSDk=1 it means everybody can do it so your app can't use any function above 1.0 or you have to write your own changer or display NULL / N/A/etc.

and of course you have to explain everybody why he can't e.g. download data for watch face.

flowstate said:

How is possible to the use the minApiLevel attribute in manifest.xml to include System 5 devices/firmware (and only those devices)?

jim_m_58 said:

I learned many years ago that setting min API caused more issues than it was worth.  I'm thinking the 2.1.x SDK was involved.  With CIQ 3.3.x and 4.1.x it's very obvious again.

Right, so in other words, it isn't possible and minAPILevel isn't useful in most cases. I sure don't use it myself, except for 1 app where it actually made sense (it's an app which revolves around a CIQ 3 feature that was released at a time when CIQ 3 was new.) Imagine if I made a similar app which targeted a System 5-only feature? I feel like if I was an end user, I would be annoyed if I downloaded the app only for it to crash or display a message stating "please update firmware" (which might be impossible if they have an APAC device).

I guess I find it very disappointing that most of the discussion about improving the CIQ ecosystem always boils down to "nobody wants to do that", "you shouldn't bother trying", and "Garmin isn't going to change that".

Basically, "if it's broken, don't use it."

In general I feel like the dev community (and users) get stuck with a lot of design decisions which were either poorly thought out in the first place, or didn't age well. Sure. hindsight is 20-20, but there's also something to be said for being flexible enough to fix what used to be broken.

Sure, I see that Garmin is really trying to fix and modernize stuff, but even end users complain about various historical limitations in the Garmin ecosystem, like the 50 course point limit in courses. Maybe some of that stuff is impossible to fix, but in this case, I don't think it's impossible for Garmin to give devs a more granular way of including and excluding devices based on features / API level. This is another one of those changes that only impacts CIQ infrastructure, not firmware, so they could go wild.

_psx_ said:

The main reason to use minSDK is preventing to download app to devices not fulfilled version.

If you have minSDk=1 it means everybody can do it so your app can't use any function above 1.0 or you have to write your own changer or display NULL / N/A/etc.

and of course you have to explain everybody why he can't e.g. download data for watch face.

Exactly. Couldn't have said it better myself.

Garmin wants to have 928 different devices to maximize market segmentation?

Cool, then it should also make sure devs can prevent users with the wrong device/firmware combo from downloading their app which revolves around Feature X which their device doesn't currently have. It's an especially relevant point for APAC devices. Even end users are constantly asking "why is my APAC device one year behind non-APAC devices >_<".

jim_m_58 said:

If it's too low for your app, the store displays a message and the app can't be installed.

jim_m_58 said:

Every one of my 50 or so production apps has a min ApiLevel of 1.x.  To handle the differences, I exclude targets, use "has" or in some cases, Jungles.

I learned many years ago that setting min API caused more issues than it was worth.

Interesting contrast of comments.

"You don't need to care about the min API for a given device because you can set minApiLevel to prevent your app from being installed if the device's api level is too low"

"minApiLevel causes more issues than it's worth."

You are sort of proving the point of people who are asking for a bettter/different way of doing things. You basically said "you can use minApiLevel to do what you want", then you said "I don't use minApiLevel because it has issues."

for me the worst thing is when device has no something e.g. baro/ and I never to check class if has member e.g. flores instead of checking simple null for member what I have to do anyway.

You mention jungles. That is the thing where you need to use exclude annotations? (Its a rhetoric question btw). Which is totally counter intuitive to deal with. Includes are much easier to grok.

I get has, because the device has a gyro it also has the associated toybox module for it when its on some API level. And some other watch doesnt have gyro so it doesnt have the module and thus it requires has when the api levels match.

However, you could argue that things like that should be defined in the manifest so you can exclude/include them better. The min api level impacts the product selection box in the vscode plugin. Lack of features should be easily excluded or said differently, availability of features on devices should be included so you can include supported devices much better.

waterkip said:

That is the thing where you need to use exclude annotations? (Its a rhetoric question btw). Which is totally counter intuitive to deal with. Includes are much easier to grok.

Yes, exclude annotations are not only counter-intuitive, but extremely unwieldy to deal with once you start excluding things across multiple dimensions, like screen size/shape, presence of touchscreen, amount of memory, CIQ level (sort of ironic, but yeah I've done it), etc. Adding one entry to a given dimension (like supporting a new screen size) means you have to go back and modify all your excludeAnnotation entries. (Yeah, in some cases there's ways to mitigate this kind of thing with local variables)

The one saving grace of this system is that if you mess up, you'll get a build error due to having the same symbol defined twice.

Having said that, I get why it is the way it is.

waterkip said:

However, you could argue that things like that should be defined in the manifest so you can exclude/include them better. The min api level impacts the product selection box in the vscode plugin. Lack of features should be easily excluded or said differently, availability of features on devices should be included so you can include supported devices much better.

Yep. The example that comes up over and over again when this is discussed is how the presence/absence of a barometer has nothing to do with CIQ API level, so you have to handle that at runtime if your app cares or manually exclude devices from the manifest if your app absolutely needs the baro.

Yeah, so wouldn't it be great if you could just flip a switch in the manifest to include/exclude all devices which have a baro? Same for any other significant hardware/software feature you could think of?

flowstate said:

Having said that, I get why it is the way it is.

Why? My take is because by default all the annotations are used and on release they exclude debug and on debug they exclude release. They expanded that and we are where we are.

Except... for barrels. Barrels must explicitly include an annotation in the manifest for it to be included in the barrel. And with barrels you have to include the annotation for it to use it in the consuming project. So it is completely the other way around. And it actually makes sense to me. Although barrels and annotations have seperate issues of their own. 

Jungles is more than just excludes.  I use it for things like having different app settings for different devices by way of resources.  No sense have options for colors on an Instince2 when it's B&W for example.

I also use it in cases where I use a different view mc files for different devices,  I find it much easier than using annotations for everything or using a bunch of if statements.