In summary, if JConsole or Java VisualVM aren’t able to connect to local processes, your %TMP%\hsperfdata_[username] directory needs to match the capitalization of your Windows username. In my case, I renamed hsperfdata_eburke to hsperfdata_EBurke, solving the problem.

To fix the problem, I right click the desktop, select “Show View Options”, and then change something like Icon Size or Grid Spacing.

After this little kick in the pants, the desktop icons become responsive again. But when the problem occurs, it usually happens several more times that day. What causes this?

If you fail to hold code reviews, the crappy code that works its way into your production code base really is riddled with obvious bugs.

A full review definitely takes more than ten seconds, but maybe the first ten seconds are the most important. If you don’t have time for a complete review, at least ask a peer to drop by and give your code a quick look.

Next, I searched for my city and state (O’Fallon, MO) as shown here:

OK, that didn’t work. Let’s try removing the apostrophe:

As you can see, it worked. Oddly, their own “Input Interpretation” displayed the city name with the apostrophe. They just won’t let you search that way.

See also: Apostrophe Abuse.

I received this comment from Alex:

Snake with open/close is a memory leak . As a weather has nothing to do with Android just bad app.

Duplicating the Bug

Here is how I duplicate the bug:

1. Start playing a game
2. Change the phone orientation, i.e. open or close the keyboard drawer
3. Push the trackball up to resume the game

Just repeat steps 2-3 a few times until it crashes, it usually takes a few tries. Is this a memory leak, as Alex suggests?

Diagnosing the Bug

1. First, install the free Android SDK. Google provides excellent instructions, so I won’t explain it here.
2. Configure your G1 phone for USB debugging. From the home screen, go to Menu -> Settings -> Applications -> Development, and select USB debugging.
3. Now connect your G1 phone to your computer via the USB cable.
4. Run ddms to start the Dalvik Debug Monitor. You’ll find ddms in the tools directory where you installed the Android SDK.
5. Make Snake crash and find the stack trace in the Log.

As you can see, this is an ArrayIndexOutOfBoundsException, not a memory leak. Here is the complete stack trace:

java.lang.ArrayIndexOutOfBoundsException
    at com.example.android.snake.TileView.setTile(TileView.java:150)
    at com.example.android.snake.SnakeView.updateApples(SnakeView.java:434)
    at com.example.android.snake.SnakeView.update(SnakeView.java:405)
    at com.example.android.snake.SnakeView.setMode(SnakeView.java:336)
    at com.example.android.snake.SnakeView.onKeyDown(SnakeView.java:279)
    at android.view.KeyEvent.dispatch(KeyEvent.java:718)
    at android.view.View.dispatchKeyEvent(View.java:3154)
    at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:734)
    at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:734)
    at android.view.ViewGroup.dispatchKeyEvent(ViewGroup.java:734)
    at com.android.internal.policy.impl.PhoneWindow$DecorView.superDispatchKeyEvent(PhoneWindow.java:1589)
    at com.android.internal.policy.impl.PhoneWindow.superDispatchKeyEvent(PhoneWindow.java:1084)
    at android.app.Activity.dispatchKeyEvent(Activity.java:1856)
    at com.android.internal.policy.impl.PhoneWindow$DecorView.dispatchKeyEvent(PhoneWindow.java:1560)
    at android.view.ViewRoot.deliverKeyEvent(ViewRoot.java:1616)
    at android.view.ViewRoot.deliverTrackballEvent(ViewRoot.java:1508)
    at android.view.ViewRoot.handleMessage(ViewRoot.java:1201)
    at android.os.Handler.dispatchMessage(Handler.java:88)
    at android.os.Looper.loop(Looper.java:123)
    at android.app.ActivityThread.main(ActivityThread.java:3739)
    at java.lang.reflect.Method.invokeNative(Native Method)
    at java.lang.reflect.Method.invoke(Method.java:515)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:739)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:497)
    at dalvik.system.NativeStart.main(Native Method)

Avoiding Bugs Like This

I find that most Android bugs occur when Activities pause and resume. Changing screen orientation is a great way to crash many applications. That’s because orientation changes trigger lifecycle events. These events will occur at inopportune moments, such as when you receive phone calls or the user hits the Home button.

Applications that do not properly react to onPause(), onResume(), and other such methods will eventually fail.

You can use the UI/Application Exerciser Monkey to stress test your application. In the emulator, you can simulate incoming phone calls, which will pause the current Activity. You should also open and close the keyboard — repeatedly — while your application is performing tasks.

In summary, you need to brutalize your applications. Try really, really hard to break them. Android is a challenging environment because you must carefully manage threads, react to a complex series of lifecycle events, and deal with limited resources.

So I grabbed my Canon PowerShot SD1100 camera and snapped the picture shown above. My Canon camera never shows a “Force Close” error. It just works. I expect the same user experience from my phone. Is that an unreasonable expectation?

Here is the Weather Channel Android application, one of the most popular apps in the Android Market. It Force Closes becomes unresponsive from time to time. To get this picture, I simply tapped the tabs quickly:

Next I opened the Snake game. I opened and closed the phone a few times and…well, you know what’s coming next:

This is not good enough.

public class TooltipBug extends JFrame {
    public static void main(String[] args) {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
                try {
                    UIManager.setLookAndFeel(
                      "com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
                } catch (Exception e) {
                    e.printStackTrace();
                }
                new TooltipBug().setVisible(true);
            }
        });
    }

    public TooltipBug() {
        // un-comment these lines for the workaround
        //UIManager.put("ToolTip[Disabled].backgroundPainter",
        //        UIManager.get("ToolTip[Enabled].backgroundPainter"));

        JButton b1 = new JButton("One");
        b1.setToolTipText("Button 1");

        JButton b2 = new JButton("One");
        b2.setEnabled(false);
        b2.setToolTipText("Button 2");

        Container c = getContentPane();
        c.setLayout(new FlowLayout());
        c.add(b1);
        c.add(b2);

        pack();
        setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    }
}

*** UPDATE: They accepted my bug report. It is Bug ID 6789983.

The problem is, disabled items in JToolBar use a black font and don’t look any different than enabled items.

This example requires Java6u10 or later, and demonstrates the bug:

public class ToolbarBug extends JFrame {
  public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        try {
          UIManager.setLookAndFeel(
               "com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel");
        } catch (Exception e) {
          throw new RuntimeException(e);
        }
        new ToolbarBug().setVisible(true);
      }
    });
  }

  public ToolbarBug() {
    /*
    // un-comment these lines for the workaround
    UIManager.put("ToolBar:Button[Disabled].textForeground",
            UIManager.getColor("nimbusDisabledText"));
    UIManager.put("ToolBar:ToggleButton[Disabled].textForeground",
            UIManager.getColor("nimbusDisabledText"));
    */

    JToolBar tb = new JToolBar();
    tb.add(new JButton("Enabled"));
    JButton disabled = new JButton("Disabled");
    disabled.setEnabled(false);
    tb.add(disabled);

    add(tb, BorderLayout.NORTH);

    pack();
    setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
  }
}

With the fix, the example looks right:

Dell sells this computer with a defective video driver. Icons sometimes vanish until you move your mouse over them, at which time they eventually paint. The screen shows frequent painting artifacts — sometimes the entire login screen is blank, but you can still type. Software updates from ATI crash and burn.

This is true for other people’s PCs as well, so I know it is not a fluke with my machine. I have first hand experience with Vista at home, and I know that some video cards work fine with Vista. This particular configuration — the one Dell chooses to sell — does not work properly.

Yes, Vista has a lot of problems. I get it.

In this case, however, Dell is the problem. They knowingly sell this particular video card with their own PCs. 20 minutes of basic usage reveals painting artifacts and bugs. If Dell cared about customers, they would reject shitty hardware like this. Dell is huge. They can very easily tell ATI: “Sorry, not good enough. We refuse to cheapen our PCs with your flaky hardware and drivers.”