menuItem.getActionView() == null in API 15

Question

I'm supporting down to API 15 in my app, and I'm getting a crash for those users when I try to get the searchView from my menu.

Below is my code:

@Override
public void onPrepareOptionsMenu(Menu menu) {
    super.onPrepareOptionsMenu(menu);

    MenuItem menuItem = menu.getItem(0);
    searchView = (SearchView)menuItem.getActionView();
    searchView.setIconifiedByDefault(false);
    searchView.setQuery("", true);
    menuItem.expandActionView();
}

I'm getting a NullPointerException on this line:

searchView.setIconifiedByDefault(false);

because the searchView is null. This works perfectly fine on devices at API 16 and above. Has anyone run into this issue before?

Just check what you get returned in menu.getItem(0) with a debugger. — Patrick, Oct 06 '14 at 15:34
Possible duplicate of http://stackoverflow.com/q/18438890/844882 — Alex Lockwood, Oct 06 '14 at 15:35
@AlexLockwood I've gone through this question, and none of the solutions seemed to resolve my issue — coder, Oct 06 '14 at 15:45
@for3st the menu.getItem(0) isn't null, but the actionView is — coder, Oct 06 '14 at 15:46
@AlexLockwood I'm actually not using AppCompat. Sorry about that - I have a custom searchView that extends android.widget.SearchView. When I extended from the AppCompat version, I got the crash on all OS versions. — coder, Oct 06 '14 at 16:00
when I use app:showAsAction='always' the searchView doesn't show in the action bar — coder, Oct 06 '14 at 16:01
Check LogCat. There may be exceptions coming from your `onCreateOptionsMenu()`, where you inflate the menu resource, related to creating your custom `SearchView` subclass instance. Those exceptions are sometimes just "handled" with dumping a message to LogCat, without re-raising the exception, and so we only find out about the problem when something downstream breaks. — CommonsWare, Oct 06 '14 at 16:07
@CommonsWare That was the issue. I was using a "setBackground" in the SearchView that was breaking in API 15. I can either delete the question, or if you write up an answer, I can accept yours. Your choice. — coder, Oct 06 '14 at 16:18

score 1 · Accepted Answer · answered Oct 06 '14 at 16:23

While inflating a layout usually causes an immediate crash if there is a problem, inflating a menu resource does not. If there is some problem, a stack trace is logged, but otherwise the exception is handled, and so execution continues. It is only some time later that we realize that something did not work, when things break later on.

Custom action bar items (actionLayout, actionViewClass, actionProvider) are especially prone to this. If there is some problem loading any of those -- such as the actionViewClass not implementing the proper constructor -- we only find out about it when we try to retrieve the custom item and get null back. The solution is to rummage through LogCat and look for the stack trace associated with the handled exception, to see what really went wrong.

In an API level-dependent case, like this one, the most likely scenario would be where initialization of custom action item refers to a method that does not exist on the older version of Android, and therefore fails.

score 0 · Answer 2 · edited Dec 03 '14 at 21:56

I also had just the same problem as you and came to this stackoverflow question. With some struggle, I have found the heart of this problem and a solution.

In API15, during app's initialization, only onCreateOptionsMenu is called but onPrepareOptionsMenu is not.

In API16 and later, onPrepareOptionsMenu is called right after onCreateOptionsMenu.

So my solution is to call onPrepareOptionsMenu at the ending point of onCreateOptionsMenu:

@Override
public void onCreateOptionsMenu(Menu menu, MenuInflater inflater) {
    super.onCreateOptionsMenu(menu, inflater);

    (...)

    if (Build.VERSION.SDK_INT < 16) {
        onPrepareOptionsMenu(menu);
    }
}

menuItem.getActionView() == null in API 15

2 Answers2