• Replies 137 replies
  • Subscribers 27 subscribers
  • Views 16991 views
  • Users 0 members are here
Options
Related

Watchface compiled with 4.2.1 cannot read bodybattery on a real device

li2niu
over 1 year ago

As the title, I just compiled my watchface with SDK4.2.1. However some users told me the body battery became in-readable on their real devices. Everything works fine in my simulator.  Do you have similar issues?

  • over 1 year ago in reply to trudelta

    You can try to compile with java -jar xxxxx/monkeybrains.jar xxxxx 

  • over 1 year ago in reply to _psx_

    I see.   But export seems to work OK.

    So this means I have no way to go back to compile, maintain and test older apps that I want to keep at a lower level SDK to avoid this bug in SDK 4.2.1?

  • over 1 year ago

    Now I see the problem too. So either there's something we don't understand, or there's an oversight from Garmin's part that couldn't do this backwards compatible :( I would understand why we need 4.2.1 for fr265, and that would still make no sense if we don't want to use System6 features, but I could understand it. But why can't we compile for epix2 with 4.1.7 the same code that we could compile 3 weeks ago?

  • over 1 year ago in reply to flocsy🤠

    Other devices files were updated, like the epix2 amd their connectIQversion for WW devices is 4.2.0, like the 265/965.  The 4.1.7 SDK doesn't understand 4.2.0, which is why you need the 4.2.1 SDK.  And it's not just for sys6 features.  It's to know what is available with 4.2.0 devices.

    This kind if thing really isn't new or strange.  It's like how you needed a 4.0.x SDK to use 4.0.x devices in the past. A 3.x SDK couldn't be used for a 4.0.x device.

  • over 1 year ago in reply to jim_m_58

    Which makes no sense, since we could compile to epix2 with 4.1.7 before we upgraded the device files, and whatever you compiled then does run today both on epixes with 4.1.x CIQ and also with 4.2.0.

    And I guess nobody would care, if there were no memory issues with the 4.2.1 compiler...

  • over 1 year ago in reply to flocsy🤠

    Updating the device files so they are Sys6 (4.2 or 3.4) is the reason you need the 4.2.1 SDK and why it happened at the same time.

    It's also why you'll see an error in VS Code if you try to use 4.1.x on a sys 6 device.

    As far as 4.2 issues, there were two beta SDKs (the first last oct) along with two Sys 6 preview devices..  I've yet to see any memory issues with a 4.2.x SDK, and I used both betas and moved to 4.2.1 when it was released, and run many of my apps with 4.2 over the last 5 months..

  • over 1 year ago in reply to flocsy🤠

    And as I said, I have not had an issue with my apps.

    I just rechecked one of my widgets using a f6 target, and the difference I see between peak memory with 4.1.7 and 4.2.1 is .1k while viewing the glance.

    also .1k in full screen

  • over 1 year ago in reply to jim_m_58

    Maybe you don't use features making problem.

    I have running app in sim 4.1.7, very optimised (20kB free), installing 4.2.1, updating devices, changing to the newest sdk running the exactly the same code and app crash due to no properties because no memory and again PRP.getValue().

    So have restored 4.1.7 from backup and ...  calm and no any problem.

    And  has the same feeling that mentioned early, updating epix, f6 etc to min 4.2.1 has no sense and I've asked why it have been done? To confirm it, I built new versions of app with 4.1.7 even for 265/965.

  • over 1 year ago in reply to _psx_

    I've mentioned before that what you see could be related to optimization and it not working the same in 4.1.7 and 4.2.1.  What if you turn optimization off for both SDKs?

    Did you do any testing with the two 4.2.0 beta SDKs?