Announcing Fitbit OS SDK 4.1

[JonFitbit]

SDK 4.1 adds a new API for calendar access, Always-on Display API, detecting a user's primary goal, and some rather useful enhancements to the Document API.

https://dev.fitbit.com/blog/2019-12-19-announcing-fitbit-os-sdk-4.1/

[rc26]

Looks good. If I implement some of the new API features in my clockfaces, I assume only users with the OS 4.1 update on their watch can install it, right? Some people avoid updates in general. If a user doesn't have the OS 4.1 update on their watch, will there be a message for them when they try to install a clockface compiled with SDK 4.1 to update their watch?  

[JonFitbit]

If it's an existing clock/app I believe they'll get the previous compatible version. Otherwise they get a message stating it's not compatible with their device.

[rc26]

Another question:  Without changing my clockface at all, would there be any benefit or performance gain to recompiling the project with SDK 4.1 and pushing it out to users?  I'm not going to, but just wondering. I've been using Fitbit App 3.12 on Android 9 with my Ionic - latest firmware - and from time to time the Fitbit App on the phone just stops playing nice with my watch. My watch indicates that the messaging peersocket has closed, and most of the time I have to close and reopen the Fitbit App or restart the phone because the backup method of getting by on File Transfers stops working.  It's not a huge deal to restart the Fitbit App / phone, but I'm wondering if using a watch with OS 4.1 with a clockface compile with 4.0 might be a contributing factor. Thanks.  

[LiamFitbit]

The short answer is no.

The long answer is no: when it comes to JS the term SDK is a bit different to what it means elsewhere.

When we release new SDKs, here's what effectively changes:

- We bake a new number into the app you build that denotes it was built with a different set of expectations (ie, you've built it against the SDK as documented in 4.1)

- At runtime, we look at that number, and decide how the runtime should behave. Mostly this is exposing new modules/functions that didn't exist before, but sometimes it's changing the behaviour of existing ones

- Old apps keep their old numbers, so the runtime treats those just as before

- Sometimes, the tooling changes how it builds your app, which could result in slightly different JS

[j0nson]

Can I get approved for Always on Display? I just want to sideload to my own device.

[LiamFitbit]

Even for approved clocks/apps, sideloading isn't permitted. With the possibility for badly behaved clocks/apps to damage the screen, we need to ensure all content is reviewed before running on the watch, which wouldn't be possible when sideloading.

[curxxx]

That sounds very inconvenient.... especially for debugging graphical design... sometimes the simulator makes something look good when in reality it doesn't look that good on the watch. Can't you just implement something that somehow monitors for this bad behaviour automatically instead of needing manual approval? I imagine bad behaviour means things like flashing elements?

[LiamFitbit]

You can develop AOD designs on the watch just not actually in AOD mode if you want to see how it looks on the real device display.

It's less to do with flashing elements and more to do with how many pixels on the display are lit up at any one time. Light up too many, and you can damage the display. Enforcing this in software on the watch would be taxing on the CPU of the device and would result in poor battery life and performance.

[S_Willis]

It seems strange to say we can develop AOD applications although we don't have a good way of testing them to see if they are going to work correctly, and how they will look switching between states. For people who have applications that would need to reduce pixel count to get under the 20% guideline, they have no way of easily switching between the two modes as was suggested by the post.

I did finally come up with a way, using an extra settings toggle to fake a display "change" event, but obviously that is limited as it does not support the display poke to wake up, or the autoOff, but at least it lets me see the full application in both states, and the impact of the switch.

Any feedback on when the general community will have access to really develop AOD, or how to request access to use it?

[LiamFitbit]

We have no plans to allow AOD sideloading. Even approved developers/clocks/apps cannot sideload, and for the reasons we've stated, we don't have plans to change that.

[S_Willis]

I wasn't asking about sideloading, another developer was. My comments about development were limited to the FitBit Simulator, the same one that was used to demonstrate the AOD ability in the official announcement:

The same announcement also says "You can experiment with AOD using the simulator" and "Improvements to the simulator mean we can now toggle AOD mode". This information seems inaccurate as we cannot turn on the AOD mode in order to do any experimenting using the simulator, even just in the simulator.

So to try to be clear - not asking to sideload or publish ab AOD clockface, just trying to use the simulator that the announcement suggests can be used to experiment.

The last two questions I also asked about are:

1) Is there a timeframe for when the general developer community is allowed to really develop working AOD applications. According to the announcement "We aren't quite ready to roll this out publicly just yet", and I was wondering if there was a rough time when we will be allowed it. Are we weeks away, months away?

2) The announcement also said, "AOD is gated behind a restricted permission that needs to be granted to a developer profile, and also granted for each clock or app (once reviewed)". I was wondering if there was an approval process to be granted that permission on our profiles and applications - or is it a closed group your working with and so the rest of us have to wait till it is public? I think I read that it was closed, and FitBit was doing invites based on popularity and rating of the application, so it sounds like there is no way to "request" this permission.

[LiamFitbit]

I didn't realise, since I didn't see any mention of the word simulator in your post. You can pull down quick settings from the top at the clockface to enable AOD mode.

I'll let JonFitbit speak to the other questions.

[S_Willis]

I can turn on "Always-On-Display" through the simulator, however the application still does not have the permission granted to test in the sample code:

appbit.permissions.granted("access_aod")

This still returns false, but as mentioned before I can bypass that check easily enough. However when trying to set:

display.aodAllowed = true;

I get the warning:

[8:05:24 AM]Cannot enable app AOD mode since permission was not granted

Then in the simulator switching the display off uses the system/default AOD display, rather than the one I am experimenting with.

Normal display:

Display off (system AOD):

What it should look like (faked AOD):

[LiamFitbit]

Do you have "access_aod" in your requested permissions within package.json?

If you're using Studio (which we don't recommend for AOD work right now), you'll need to temporarily rename package.json in order to add this.

[S_Willis]

I am using Studio, and had not added it, as I was trying to not to bypass the normal processes where possible.

I have renamed the file, added "access_aod", and restored the name back, and now it does work as expected.

[MikeO1]

This is correct. I have developed the code to enable AOD in the simulator for my watch faces but you cannot submit any as you get the following error 'permission "access_aod" not allowed' 

Is there any date when the development environment will allow adding this permission and when we can submit applications with this permission enabled?

Regards,

Mike

[PatrickBiz]

"......We have no plans to allow AOD sideloading. Even approved developers/clocks/apps cannot sideload, and for the reasons we've stated, we don't have plans to change that."

Why?

May be, Google will now make Fitbit development process better and easier!

[Faqih]

Agree. It’s so annoying to not be able to fully utilise the software’s potential. I have so many ideas but no way to materialise them. What we made unpublished is for our own use and we are aware of the risks.

[PatrickBiz]

Not sure why "Always-On" is such a big deal for Fitbit. 

Samsung deployed this feature years ago, and Apple has taken it to a completely new different level. To remain relevant and competitive, Fitbit needs to figure out a way to leverage the developer community well.