Acknowledged

OLED: font resources seem to be forgotten while sleeping which leads to a crash onExitSleep

It seems that OLED watches now release fonts when sleeping and onExitSleep is called before initialize, so the app crashes when it uses fonts in the onExitSleep to update the layout. 

I get null exception while a resource is expected on this line that is called from onExitSleep.

"UnexpectedTypeException: Expected Number/Resource, given null…"

I got thousands of failure reports on this line from a variety of OLED devices. 

I do not release fonts anywhere in the code and the same line is called via initialize without problems. 

I hotfixed it by catching the exception and calling the initialize instead, but that is a huge wasting of resources and probably a battery. 

I am not aware of any documentation that the Monkey might release any resources on its own and even if it does, I'd expect it would call initialize before onExitSleep. 

Some of devices where the error occurred: 

  • Venu® 3: 8.25
  • vívoactive® 5: 8.27, 4.14
  • Forerunner® 265s: 17.26

EDIT: added an exception text

EDIT2: added devices 

Parents
  • Dear Travis!

    I've reported a lot of bugs and a few with flow. How many times should I report the same bug to be treated seriously?
    Why many bugs hasn't fixed for years? So why do you surprise that the same problems appear?

    I have already been taught that you cannot wait for bugs to be fixed, you should immediately look for a workaround.
    So sorry I won't give you examples of bugs - it doesn't help because you have to solve the problem yourself anyway!
    But as I've involved in this thread... How do I know that flow is bad sometimes? Because I guessed (not on my f6/f7 because I've never seen IQ errors on my watch) that onExitSleep is called directly after initialise and after getting rid of onLayout the problems have disappeared. Usually it happens for amoled's with AOD off - but I don't know why. Most importantly, there is no onLayout(), no bugs, no problems - but it waits for every new developer to time of fixing bug.

Comment
  • Dear Travis!

    I've reported a lot of bugs and a few with flow. How many times should I report the same bug to be treated seriously?
    Why many bugs hasn't fixed for years? So why do you surprise that the same problems appear?

    I have already been taught that you cannot wait for bugs to be fixed, you should immediately look for a workaround.
    So sorry I won't give you examples of bugs - it doesn't help because you have to solve the problem yourself anyway!
    But as I've involved in this thread... How do I know that flow is bad sometimes? Because I guessed (not on my f6/f7 because I've never seen IQ errors on my watch) that onExitSleep is called directly after initialise and after getting rid of onLayout the problems have disappeared. Usually it happens for amoled's with AOD off - but I don't know why. Most importantly, there is no onLayout(), no bugs, no problems - but it waits for every new developer to time of fixing bug.

Children
  • In this case I think it suggests it is crashing in TVM code rather than app code. There is going to be no way to catch such an exception.

  • t's a release build, right? What to get from it? I don't see any clue to identify the cause if there's no the stack trace from the debug mode. I don't have an OLED device to test it by myself. 

    Coincidentally, there is just one Exception in ERA from 13. 2. (Epix) on this line. The line is just a var declaration:

    var line;

    That makes zero sense. What exception can be raised by a single declaration? 

  • All reported issues go through QA first before passing it on to development. We have a great number of test applications that we can either use for reproducing problems directly or modify them to cause the particular issue, but more obscure problems can require writing something from scratch.

    The more information provided and especially a CIQ project that already reproduces the problem with Monkey C code that can be examined the quicker an issue can be resolved.