Как включить утверждения уровня языка в Android Runtime (ART)?

У меня есть Pixel-C, для которого я разрабатываю. Мой минимальный уровень API – 21, что также является уровнем, на котором ART заменил Dalvik. Я пробовал оба:

adb shell setprop dalvik.vm.enableassertions all adb shell setprop debug.assert 1 

И они, похоже, успешно выполняются. Я поставил

 assert false : "assertions are active!"; 

В моем onStart, и я не вижу никаких следов стека в logcat. Я ожидаю, что приложение выйдет сразу после установки и запуска. Скажите, пожалуйста, как заставить это утверждение выполнить.

Пожалуйста, не упоминайте JUnit или другие способы делать утверждения, а также любое решение, требующее явно бросать ошибку. Производственный код никогда не должен бросать ошибки, а также не пытаться их поймать и обработать. Вот почему на язык были добавлены утверждения, чтобы иметь возможность привести к сбою приложения, когда инварианты нарушаются в тестовых средах без каких-либо накладных расходов или риска вообще в производстве.

Этот 6-летний вопрос в основном тот же, но для Dalvik (IE устарел), и решения либо не работают, либо не хороши: могу ли я использовать assert на устройствах Android?

Я неохотно утверждаю, что ответ кажется: вы не можете утверждать утверждения в отношении АРТ . То, что работает, заключается в замене всех утверждений явно выраженным AssertionError, завернутым в оператор if следующим образом:

 if (BuildConfig.DEBUG) { if (writeBuffer.hasRemaining()) { // As with all assertions, this condition should never be met. throw new AssertionError("whole buffer not written"); } } 

По-видимому, в уровнях API 21, 22 и 23 АРТ фактически полностью удалит байт-код для этого, если блок из не-отладочных сборников устанавливается после установки, то есть, когда BuildConfig.DEBUG == false. На этих уровнях API АРТ компилирует байт-код в родной для установки, но это меняется для Android N. Итак, я полагаю, что на Android N, АРТ может по-прежнему видеть незначительное снижение производительности при производстве проверки BuildConfig.DEBUG до тех пор, пока оптимизатор не сможет ее скомпилировать После определенного использования.

Мне не нравится это, потому что он удаляет возможность выбора для запуска утверждений для определенного пакета в apk. Теперь выбор заключается в детализации всей сборки и только во время сборки.

Другая важная причина, что это отстой, это то, что она многословная и уродливая. Краткость утверждений делает их полезными для документирования вашего встроенного кода. Хотя эти взломанные утверждения могут служить документацией, они перестают быть непонятными и разборчивыми. Посмотрите на этот пример. Это должна быть одна строка, а не пять.

Если у вас есть идея, почему АРТ, похоже, не поддерживает утверждения, например, внутренние знания о технических препятствиях или внутренней политике Google, прокомментируйте или оставьте новый ответ. Мое предположение заключается в том, что широко распространенное недоразумение полезности и роли утверждений и распространенность использования антипаттернов побудили команду Android просто отключить эту функцию, а не воспитывать всех. Возможно, команда Android страдает от подобных недоразумений .