Known Stock ROM Issues

Photon 4G

Many users have reported that Webtop can be loaded but the track pad is unresponsive. After some remote investigation sessions and user interactions, it is believed that this is an official timing bug that can be temporary fixed by clearing the dalvik cache of some apps(eg. DockService and PortalApp) and then reboot to increase the boot time of Android so as to allow other (unknown) process to run earlier than certain Android related services to allow the track pad from working.

A better fix would be to find out the exact racing services and then re-run the intended services manually. This will need Photon owner to provide remote investigation session and my time. :) Email me if you wish.

No track pad and evbridge is using 99% CPU

Razr Maxx

On some Razr, its evbridge will fall into a dead loop at early stage. One instance was reported by Miguel Ortiz. He provide a remote investigation session so that I have chance to test running the evbridge from WT-2.0.0-82 and WT-2.0.0-113. Both could run normally on his Razr Maxx. His Webtop version is WT-2.0.0-139.

Razr

Another instance of this is reported by Lorenzo Kellogg. He has a XT912 with WT-2.0.0-139 from Verizon. It is interesting that the evbridge(113) has the same behavior on it. By setting the TZ variable(to GMT, let say) that skipped the /etc/localtime, evbridge(both 113 and 139) can be started without any problem. By analyzing the difference between a hanging and non-hanging strace log, /etc/localtime(or /usr/share/zoneinfo/$TZ) is found to be the culprit.

Problem reproduced on a healthy Razr

I'm able to reproduce the problem on a Razr that hasn't this problem by using the /etc/localtime extracted from Lorenzo's phone. The steps to reproduce:

• 1. backup /etc/localtime

  2. cp /tmp/localtime /etc/localtime

  3. sudo -u adas -i

  4. run evbridge from WT-2.0.0-113 or WT-2.0.0-139.

Here is the tz database wiki link. The latest tz database can be downloaded from http://www.iana.org/time-zones .

It is found that the /etc/localtime found from Lorenzo's phone is exactly the same as /usr/share/zoneinfo/US/Michigan.

Workaround

• 1. First backup /etc/localtime (eg. copy to /etc/localtime.o)

  2. Then from the date/time setting, untick the automatic and change the timezone to something else.

  3. Reboot the phone.

  4. Enter Webtop.

  5. Change back the timezone to the original.

  6. Run 'getprop persist.sys.timezone' (without the quote) to verify that the timezone set is not US/Michigan or America/Detroit. If it is, go back step 5 and select another timezone.

  7. Reboot the phone.

  8. Enter Webtop again.

So, what's going on?

Okay, to summarize the stuffs of evbridge dead loop:

• 1. Most likely a Verizon Razr phone (it is possible that it comes with more choices of US time zone)

  2. The automatic date/time has detected a timezone of Eastern Daylight Time GMT -5:00, that is either US/Michigan or America/Detroit when checking by getprop | grep timezone.

  3. When the timezone is changed to something else, say GMT -4:00(or if the Eastern Time doesn't response to Michigan or Detroit when checking by getprop | grep timezone), after rebooting the phone or Webtop and then enter Webtop again, the track pad will work.

  4. This is because evbridge has some trouble when the persist.sys.timezone is US/Michigan or America/Detroit, as concluded from experiments.

One more instance BUT different timezone!

The timezone file is Europe/Brussels. It is reported by Viktor Horvat. Webtop version WT-2.0.0-113. What's up? ?_?