Always On Display - Implementations (Jumping vs Static)

So this is just my educated guess, but I would say:

- CIQ 3: "OG Venu rules" (whatever they are)

- CIQ 4: 10% pixels max

- CIQ >= 5 (System 7): 10% luminance max

I don't develop AMOLED watchfaces, so take all of this with a grain of salt...

Sources:

As per the compiler.json files in the SDK's Devices folder:

- The original Venu is stuck on CIQ 3

- All other AMOLED devices are on CIQ 4/5

[https://developer.garmin.com/connect-iq/user-experience-guidelines/watch-faces/]

[https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/welcome-to-system-7]

Always on Always

The original Venu was the first Connect IQ device with an AMOLED screen and introduced the heuristics to avoid screen burn-in. Newer devices allow watch faces to keep the screen on in “Always On” mode if the screen is using less than 10% of the display pixels.

With API level 5.0.0, we are updating the heuristic from one based on pixels to one based on luminance. Now the screen will stay on if the display is using less than 10% of the total luminance. This allows you to use more pixels.

thank you very much, that helps.

If I remember correctly, there is no way to check the CIQ version dynamically (like :has), is there?

Use System.getDeviceSettings() and inspect monkeyVersion in the returned DeviceSettings object.

Michael said:

dynamically (like :has)

Note that recently, the compiler has been improved so that has checks can be done at compile time (which means they may be optimized away so they don't execute at run time.) This is nice for optimization, but it also means that has checks may not work as intended if a device gains a new feature after a given version of your app was compiled and released to the store. IOW, you may want a has feature check to work without recompilation, when a device gets that feature, but this new optimization prevents that from happening.

If you want to prevent has checks from being optimized away, add  --disable-api-has-check-removal to the compiler command line.

thank you very much. I was aware of the new :has optimization anyways already. In my case I prefer the optimization.

Michael said:

I was aware of the new :has optimization anyways already. In my case I prefer the optimization.

Cool. Just wanted to make it clear that has is no longer as dynamic as it used to be.

There is a compiler flag if you want to do "has" the way it's been done in the past

-disable-api-has-check-removal

jim_m_58 said:

There is a compiler flag if you want to do "has" the way it's been done in the past

-disable-api-has-check-removal

FlowState said:

If you want to prevent has checks from being optimized away, add  --disable-api-has-check-removal to the compiler command line.

Does anyone of you know if burn ins can theoretically happen on a watch that allows static AOD displays? Does garmin guarantee that (or at least take the responsibility for it)?

I ask because I wonder if I should show a static AOD with 10% pixels/luminance if possible or if I should allow the user to decide if he really wants to use a static AOD instead of the "jumping" one that I use currently.

Idk what Garmin guarantees, but I do know that on AMOLED devices, Garmin utilizes pixel shifting on native activities. (Devs noticed that the data field separator lines move around periodically.)

Not to be super cynical, but if you give the user a choice, they will just blame you if they pick the “wrong” choice and happen to experience burn in.