AMOLED Always-On Mode for Watch Faces

A recent announcement said that developers are expected to make their watch faces support always-on mode: "To avoid a poor user experience, it is expected that Connect IQ watch faces for AMOLED devices support always-on mode"

https://forums.garmin.com/developer/connect-iq/b/news-announcements/posts/changes-to-watch-face-low--and-high-power-modes

Yet the means for doing this is not straightforward. This very insightful thread is the best resource (from other developers who have figured out workarounds):

https://forums.garmin.com/developer/connect-iq/f/discussion/192673/how-to-enable-an-always-on-mode-for-venu-amoled

Many watch faces have static features on the layout, especially the data rich watch faces with icons or other labels for different data. This makes it tricky to avoid the burn-in prevention.

Since this is an expectation, can Garmin provide some official guidance, best practices, or an SDK function or software feature that can help make it easier for developers to support always-on mode? Thanks

  • Have you seen this? https://developer.garmin.com/connect-iq/connect-iq-faq/how-do-i-make-a-watch-face-for-amoled-products/#howdoimakeawatchfaceforamoledproducts

    AMOLED and AOD has been around a number of years.  The real key is to use something like

    		var sSettings=Sys.getDeviceSettings();
            if(sSettings has :requiresBurnInProtection) {       
            	canBurnIn=sSettings.requiresBurnInProtection;        	
            }

    and do things differently if the watch face is in low power and "can burn in"

  • One thing to note is if you support AOD in a watch face on an AMOLED device and the user has AOD enabled, there likely will be a noticeable impact on the battery life 

  • Thanks Jim, I have seen that page on the developer site, but it does not really give guidance on how to avoid burn-in; it just explains what burn in protection is and how to test for it. What are best practices for doing things differently if a watch has burn in protection? For example, on a digital face, the colon and several other pixels for the numbers will be on for an extended time in low power mode, even if I remove all of the peripheral data that the user may want to keep. Is the best solution a checkerboard that shifts every minute? Can there be a function that can generate a checkerboard so each developer doesn't have to spend the effort to figure it out and implement properly? What about secondary exposure bleeding between pixels which the burn-in protection may not account for? Should the checkerboard have a certain density to ensure no bleeding? I'm ok with figuring things out if I *want* to, but when there is an expectation to do so, I kind of expect some official guidance in return.

  • Also, does Garmin have any preferences around how *not* to avoid burn in to ensure that the user does not have a similarly poor experience? (What is a "poor" user experience?) For example, would a user get annoyed if there is a timer that blanks the entire screen for 1 minute every 3 minutes? Would something like this be discouraged? Because it would be easier than making a checkerboard that shifts back and forth.

  • On some watches. I move the time "hh:mm", starting in the top half, then the middle, then the bottom half,  Other's I have the checkerboard option so that a pixel is never on more than 1min at a time Time is always drawn in the same place, but overlaied by the checkerboard, shifting it every minute

    When I did the checkerboard, I did it as a custom font, that's 50x50, and editing the png (lots of copy/pastes), but for my own use, I prefer moving the time instead.  With the checkerboard, it makes the time dimmer. and harder to see in bright sunlight.  Just a png with alternating pixels like this (X is white, O is black(

    XOXOXOXO

    OXOXOXOX

    XOXOXOXO

    You may want to download some watch faces from the store and see how they look, be it shifting, checkerboard, etc.

  • Hello all, what do you think about drawing horizontal on all screen lines where y is even, and next minute where y is odd. 
    that will prevent burning, but what is the batterie consumption for drawing all thos lines…

    on the following screen shot I have one pixel line then 3 black line to « overrride » actual pixel. Is that a valid solution?

  • What do you see with "View Heat Map" in the sim?  You need to be in low power and you can  do a full 24 hours fairly quickly.

    The fewer pixels you have on, the better the battery life.

  • it strange, because even when im showing all pixels, its says OK.
    But for sure the " : " will be always on for the 24.

    Does this options is really reliable?

  • Some devices don't have the 3 minute rule for a single pixel.  All Amoled devices  have the 10% rule

  • I really like the idea of lines instead of a checkerboard because it is easier to avoid potential secondary exposure from neighboring pixels when toggling back and forth. I think I will use this for my watch face. Thanks for the idea! Slight smile

    The battery consumption for the screen should be the same with lines or a checkerboard if the total number of pixels illuminated is the same. (The lines are really just a checkerboard with half of the pixels offset.)

    The method for drawing the lines may affect the battery too. I haven't tried it yet, but I wonder if a bmp font character would use more or less battery than drawing the lines with a for loop.