У меня возникла такая же проблема.Я обнаружил, что проблема возникает только в том случае, если я выполняю обе следующие вещи:
Я не использую управляемые диалогами действий (activity.showDialog()
-> activity.onCreateDialog()
/ onPrepareDialog()
)
Я делаю dialog.findViewById()
(и это действительно разница между строкой success или исключением requestFeature!).
final Builder dialogBuilder = new AlertDialog.Builder(activity);
b.setView(rootView);
b.setIcon(android.R.drawable.ic_dialog_info);
b.setTitle(R.string.message_of_the_day_title);
b.setCancelable(false);
dialog = b.createDialog();
dialog.findViewById(R.id.myid); // this is the problem
dialog.findViewById()
вызывает проблему, потому что вызывает
dialog.getWindow().getDecorView()
, а метод javadoc из getDecorView()
говорит:
Обратите внимание, что вызов этой функции в первый раз "блокируется"различные характеристики окна, как описано в {@link #setContentView (View, android.view.ViewGroup.LayoutParams)}}.
Разве это не хорошо, findViewById()
имеет побочный эффект, который вызывает на первый взгляд правильныйприложения для сбоя.Почему есть разница между Activity
управляемыми диалоговыми окнами и обычными диалоговыми окнами, я не знаю, но я предполагаю, что getDecorView()
делает некоторую магию для Activity
управляемых диалогов.
Я сделал выше, потому что я перешел от использования Activity
сам управлял диалогами для обработки диалогов.
Для меня решение состоит в том, чтобы манипулировать rootView, используя rootView.findViewById()
вместо манипулирования диалогом.