Android где посмотреть логи

Как я могу просмотреть и изучить журнал Android?

В системном журнале Android есть много интересных вещей, которые полезны во многих отношениях.

• найти коренные причины проблем
• определить ненадлежащие приложения

Как я могу просмотреть и изучить журнал Android?

Android 4.1 и новее

Предпочтительным способом является загрузка SDK и его использование adb logcat (требуется активировать «параметры разработчика» на устройстве).

Существуют приложения, доступные для просмотра полного системного журнала, однако они работают только на корневых устройствах или требуют ручного запуска команды, adb чтобы заставить их работать. Для получения дополнительной информации см. Этот вопрос.

Android 4.0 и старше

Вы можете либо загрузить SDK и использовать, adb logcat либо получить Logcat Extrem из Google Play Store, где журнал отображается прямо на вашем телефоне.

Расположение файла журнала

Существует несколько каталогов, в которых могут отображаться журналы (в том числе журналы о сбоях) — не все они стандартизированы (то есть некоторые могут быть привязаны к ПЗУ).

• /data/anr : Некоторые файлы трассировки, похоже, попадают сюда (Dalvik записывает трассировки стека здесь в ANR, то есть «Приложение не отвечает» или «Force-Close»; см., Например, выдержки из журнала здесь )
• /data/dontpanic кажется стандартным местоположением (AOSP) и содержит некоторые журналы сбоев, включая трассировки (см., например, viaForensics и StackOverflow )
• /data/kernelpanics это другое место — у меня не было никакой «паники ядра» на моих устройствах Android, я пока не видел там никакого контента.
• /data/panic/panic_daemon.config может указывать на другие места , сконфигурированных — на моем Droid 2 он упоминает /sdcard/panic_data/
• упомянутый Droid 2 также имеет /data/panicreports каталог (здесь пусто)
• /data/tombstones может содержать несколько tombstone_nn файлов ( nn будучи серийным, увеличивается с каждым новым файлом). Поскольку надгробные плиты размещаются для мертвых, это делается здесь для «процессов, погибших в результате аварии» (т.е. сбой) — и это то, что называется «дампами ядра» в системах Linux / Unix. Однако не все приложения создают надгробия; это должно быть явно разрешено разработчиком (см. Отладка дампов ядра Android ).

Может быть еще несколько мест, которые избежали меня; но поскольку большая часть записи ведется tmpfs , эти данные теряются при перезагрузке и не соответствуют вопросу OP.

Журнал команд для использования с терминальным приложением (или adb)

Несколько команд могут получить тонны информации. Для большинства из них рекомендуется перенаправить их в файл ( > filename.ext ) или передать через фильтр ( | grep search-for-this ):

Журнал ядра

Следующее работает без рута:

Logcat

Здесь вы можете, например, указать, в какой области вы заинтересованы — радио, события .

Получение информации об устройстве

И тонны этого: особенности устройства, информация об учетной записи, услуги .

Все в одном

Сделайте большой шар со всем вместе, от logcat до dumpstate:

Я уверен, что вы действительно хотите перенаправить эту последнюю команду . xD

Что-то о разрешениях

PS: Естественно, для доступа к этой информации может потребоваться root, так как большинство источников находятся во внутренней памяти.

Источник

Где у андроида логи?

Телефон LG P500. Иногда наглухо виснет, лечится только выдергиванием батареи. Как понять, что происходит — то ли ядро в кору выпало, то ли оболочка фризится — непонятно. Поделитесь тайным знанием, куда смотреть. Или мануалом, где про это написано.

Android Log Collector

эмулятор терминала, команда adb logcat

короче прог для просмотра логов в маркете полно. а adb это из SDK

че ты с ним делал? какая версия? у меня тоже П500, правда я почти им не пользуюсь. только звоню, и изредка в инторнеты хожу. до сих пор даже до 2.3 не обновил. да, я лентяй.

2.3.3 Проблема возникла практически с самого начала, с заводским дефолтом. Сейчас отрутовал, кучу хлама предустановленного снес, теперь виснет гораздо реже.

я вот тоже хочу 2.3, а потом рут-права, да только запуск на телефоне каких-то бинарей, сделанных кем-то меня немого напрягает.

afaik все «джейлбрейки» (или как их лучше называть?) предполагают запуск прекомпилированных блобов? я бы хотел какой-нть опен-сурцный вариант — самому собрать и проверить на наличие бэкдоров. паранойя, ага.

в /data/logger/*.log
только надо в hidden menu включить запись логов.
последовательность для входа в скрытое меню нагуглишь сам — у меня нет для этой трубы.

самому собрать и проверить на наличие бэкдоров. паранойя, ага

После перепрошивки и хардресета — не пофиг ли на бэкдоры в руте? 🙂

юзай adb shell, даже top -n 1 работает

adb logcat + временной лог

отладку usb — возможно можно будет подключиться через adb во время зависания по usb кабелю.

Еще смотри по времени когда виснет и жрет баттарею в BattaryGraph.

У меня тоже такое было но хитрое перепрошивание хитрой китайской прошивки вроде пока помогло, но про adb узнал уже после.

таки сначала перепрошивка, потом получение рута

Таки, наоборот. Как ты поставишь кастомную прошивку, не имея рута? И зачем тебе рут, когда в кастомных прошивках он обычно стоит изначально? 🙂

я хотел обновить дефолт 2.2 на дефол 2.3, получить рут, удалить говно с телефона, как сделал ТС

кто сказал что в кастомной прошивке не может быть бэкдоров?

кочнено, я исхожу из предположения, что в дефолтной прошивке нет бэкдоров 🙂

Droid Log Viewer

О как — у меня сегодня опять завис.

Почитал буржуйский форум попробую форматированную флешку от нокии и вставить ее, там правда про factory reset писали.

Кстати LogCat всетаки после перезагрузки ведет лог заново или я что то не так понимаю?

И adb shell во время зависания не работает. На kernelpanic кстати не похоже — на ютрубе кернел паник на этом телефоне уже видел и телефон мигает во время сего.

Источник

Как посмотреть логи на Android?

Как просмотреть журнал событий на Андроиде?

Как посмотреть другие действия

1. На телефоне или планшете Android откройте приложение «Настройки» Google Аккаунт Google.
2. В верхней части экрана нажмите Данные и персонализация.
3. В разделе «Действия и хронология» выберите Мои действия.
4. В правом верхнем углу страницы нажмите на значок «Ещё» …
5. Выберите нужный вариант.

Как открыть log файл на андроид?

Как получить лог-файл

1. Запустите приложение на мобильном устройстве и воспроизведите возникающую проблему.
2. В командной строке для остановки сбора логов нажмите Ctrl+C на клавиатуре.

Как удалить лог файлы андроид?

Чтобы решить проблему, наберите на телефоне служебный номер *#9900#. Телефон при этом никуда не звонит, зато на экране появляется служебное меню. Выберите в нём второй пункт, Delete dumpstate/logcat, нажмите OK. Всё.

Как снять логи в Андроид студио?

Для третьего способа нужно:

1. Скачать и установить последнюю версию «Android Studio». Запустить один раз «Android Studio» для подкачивания нужных файлов. Подключить устройство к ПК, предварительно включив отладку через USB. …
2. Выбрать вкладку «LogCat».
3. Дождаться полной загрузки логов. Скопировать логи (нажав Ctrl+A).

Как открыть LogCat в Android Studio?

Попробуйте нажать Alt + 6 в Windows или CMD + 6 на Mac. А как насчет Linux? В AndroidStudio 3.4: View-> ToolWindows-> LogCat.

Где хранятся отчеты об ошибках Android?

Отчеты об ошибках хранятся в /data/data/com. android. shell/files/bugreports .

Как посмотреть журнал уведомлений?

Как посмотреть подробную историю уведомлений на Android

1. Откройте перечень всех доступных виджетов (через контекстное меню, список установленных приложений или другим способом).
2. Найдите виджет «Ярлык настроек» и перетащите его на рабочий стол смартфона или планшета.
3. Появится меню с несколькими доступными опциями, выберите среди них «Журнал уведомлений».

Что такое системный журнал?

системный журнал (файл) — Регистрирует события операционной системы, а также особые действия оператора.

Что такое снятие логов?

Снять логи — означает процедуру по записи показателей определённых групп измерений в файл для последующего анализа этих данных. Логи снимают в одном из двух режимов: В рабочем режиме. Например, для анализа работы датчиков, работы системы климата или блока комфорта.

Что такое Crash Log TXT?

txt> фиксируется время возникновения важных событий и их краткое описание. Лог-файл crash. txt> содержит в себе время возникновения ошибок и их краткое описание.

Что такое лог?

Логи (лог-файлы) — это файлы, содержащие системную информацию работы сервера или компьютера, в которые заносятся определенные действия пользователя или программы. Иногда также употребляется русскоязычный аналог понятия — журнал.

Как удалить старые файлы обновления андроид?

Убрать можно только апдейты встроенных в Android приложений – Google Chrome, Play Market.
…
Удаление обновлений

1. Откройте настройки, перейдите в «Приложения».
2. Отыщите в списке программу, обновления которой хотите удалить. …
3. Тапните по кнопке «Удалить обновления».

Можно ли удалять лог файлы?

Для того что бы очистить место на диске необходимо удалить не нужные файлы. Чаще всего место занимают log файлы терминалов, советников и история котировок. Для их удаления нужно перейти в каталог данных МТ, и удалить в нем следующие файлы: … logs*.

Как удалить все следы приложения Android?

Кэш отдельно взятого приложения: зайдите в диспетчер приложений («Настройки» → «Приложения» → «Показать все приложения»), выберите требуемую игру либо программу из списка, откройте подраздел «Хранилище» и нажмите кнопку «Очистить кэш».

Источник

Гайд по отладке Android-приложения: ищем баги и читаем логи

Иногда в приложении встречаются ошибки, которые нельзя увидеть даже после запуска. Например, код компилируется, проект запускается, но результат далёк от желаемого: приложение падает или вдруг появляется какая-то ошибка (баг). В таких случаях приходится «запасаться логами», «брать в руки отладчик» и искать ошибки.

Часто процесс поиска и исправления бага состоит из трёх шагов:

1. Воспроизведение ошибки — вы понимаете, какие действия нужно сделать в приложении, чтобы повторить ошибку.
2. Поиск места ошибки — определяете класс и метод, в котором ошибка происходит.
3. Исправление ошибки.

Если приложение не падает и чтение логов ничего не даёт, то найти точное место ошибки в коде помогает дебаггер (отладчик) — инструмент среды разработки.

Чтобы посмотреть на логи и воспользоваться дебаггером, давайте напишем простое тестовое (и заведомо неправильное) приложение, которое даст нам все возможности для поиска ошибок.

Это будет приложение, которое сравнивает два числа. Если числа равны, то будет выводиться результат «Равно», и наоборот. Начнём с простых шагов:

1. Открываем Android Studio.
2. Создаём проект с шаблоном Empty Activity.
3. Выбираем язык Java, так как его, как правило, знают больше людей, чем Kotlin.

Нам автоматически откроются две вкладки: activity_main.xml и MainActivity.java. Сначала нарисуем макет: просто замените всё, что есть в activity_main.xml, на код ниже:

Можете запустить проект и посмотреть, что получилось:

Теперь оживим наше приложение. Скопируйте в MainActivity этот код:

В этом коде всё просто:

1. Находим поля ввода, поле с текстом и кнопку.
2. Вешаем на кнопку слушатель нажатий.
3. По нажатию на кнопку получаем числа из полей ввода и сравниваем их.
4. В зависимости от результата выводим «Равно» или «Не равно».

Запустим приложение и введём буквы вместо чисел:

Нажмём на кнопку, и приложение упадёт! Время читать логи. Открываем внизу слева вкладку «6: Logcat» и видим:

Читать логи просто: нужно найти красный текст и прочитать сообщение системы. В нашем случае это java.lang.NumberFormatException: For input string: «f». Указан тип ошибки NumberFormatException, который говорит, что возникла какая-то проблема с форматированием числа. И дополнение: For input string: «f». Введено “f”. Уже можно догадаться, что программа ждёт число, а мы передаём ей символ. Далее в красном тексте видно и ссылку на проблемную строку: at com.example.appdebugging.MainActivity$1.onClick(MainActivity.java:26). Проблема в методе onClick класса MainActivity, строка 24. Можно просто кликнуть по ссылке и перейти на указанную строку:

Конечно, метод parseInt может принимать только числовые значения, но никак не буквенные! Даже в его описании это сказано — и мы можем увидеть, какой тип ошибки этот метод выбрасывает (NumberFormatException).

Здесь мы привели один из примеров. Типов ошибок может быть огромное количество, все мы рассматривать не будем. Но все ошибки в Logcat’е указываются по похожему принципу:

• красный текст;
• тип ошибки — в нашем случае это NumberFormatException;
• пояснение — у нас это For input string: «f»;
• ссылка на строку, на которой произошла ошибка — здесь видим MainActivity.java:26.

Исправим эту ошибку и обезопасим себя от некорректного ввода. Добавим в наши поля ввода android:inputType=»number», а остальной код оставим без изменений:

Теперь можем вводить только числа. Проверим, как работает равенство: введём одинаковые числа в оба поля. Всё в порядке:

На равенство проверили. Введём разные числа:

Тоже равно. То есть приложение работает, ничего не падает, но результат не совсем тот, который требуется. Наверняка вы и без дебаггинга догадались, в чём ошибка, потому что приложение очень простое, всего несколько строк кода. Но такие же проблемы возникают в приложениях и на миллион строк. Поэтому пройдём по уже известным нам этапам дебаггинга:

1. Воспроизведём ошибку: да, ошибка воспроизводится стабильно с любыми двумя разными числами.
2. Подумаем, где может быть ошибка: наверняка там, где сравниваются числа. Туда и будем смотреть.
3. Исправим ошибку: сначала найдём её с помощью дебаггера, а когда поймём, в чём проблема, — будем исправлять.

И здесь на помощь приходит отладчик. Для начала поставим точки останова сразу в трёх местах:

Чтобы поставить или снять точку останова, достаточно кликнуть левой кнопкой мыши справа от номера строки или поставить курсор на нужную строку, а затем нажать CTRL+F8. Почему мы хотим остановить программу именно там? Чтобы посмотреть, правильные ли числа сравниваются, а затем определить, в какую ветку в нашем ветвлении заходит программа дальше. Запускаем программу с помощью сочетания клавиш SHIFT+F9 или нажимаем на кнопку с жучком:

Появится дополнительное окно, в котором нужно выбрать ваш девайс и приложение:

Вы в режиме дебага. Обратите внимание на две вещи:

1. Точки останова теперь помечены галочками. Это значит, что вы находитесь на экране, где стоят эти точки, и что дебаггер готов к работе.
2. Открылось окно дебага внизу: вкладка «5: Debug». В нём будет отображаться необходимая вам информация.

Введём неравные числа и нажмём кнопку «РАВНО?». Программа остановилась на первой точке:

1. Сразу подсвечивается синим строка, где программа остановлена: в окне кода на 28-й строке и в левом окне отладчика (там даже можно увидеть, какой метод вызван, — onClick).
2. В правом, основном окне отладчика, всё гораздо интереснее. Здесь можно увидеть инстансы наших вью (answer, first, second), в конце которых серым текстом даже отображаются их id. Но интереснее всего посмотреть на firstInt и secondInt. Там записаны значения, которые мы сейчас будем сравнивать.

Как видим, значения именно такие, какие мы и ввели. Значит, проблема не в получении чисел из полей. Давайте двигаться дальше — нам нужно посмотреть, в правильную ли ветку мы заходим. Для этого можно нажать F8 (перейти на следующую строку выполнения кода). А если следующая точка останова далеко или в другом классе, можно нажать F9 — программа просто возобновит работу и остановится на следующей точке. В интерфейсе эти кнопки находятся здесь:

Остановить дебаггер, если он больше не нужен, можно через CTRL+F2 или кнопку «Стоп»:

В нашем случае неважно, какую кнопку нажимать (F9 или F8). Мы сразу переходим к следующей точке останова программы:

Ветка правильная, то есть логика программы верна, числа firstInt и secondInt не изменились. Зато мы сразу видим, что подпись некорректная! Вот в чём была ошибка. Исправим подпись и проверим программу ещё раз.

Мы уже починили два бага: падение приложения с помощью логов и некорректную логику (с помощью отладчика). Хеппи пас (happy path) пройден. То есть основная функциональность при корректных данных работает. Но нам надо проверить не только хеппи пас — пользователь может ввести что угодно. И программа может нормально работать в большинстве случаев, но вести себя странно в специфических состояниях. Давайте введём числа побольше и посмотрим, что будет:

Не сработало — программа хочет сказать, что 1000 не равна 1000, но это абсурд. Запускаем приложение в режиме отладки. Точка останова уже есть. Смотрим в отладчик:

Числа одинаковые, что могло пойти не так? Обращаем внимание на тип переменной — Integer. Так вот в чём проблема! Это не примитивный тип данных, а ссылочный. Ссылочные типы нельзя сравнивать через ==, потому что будут сравниваться ссылки объектов, а не они сами. Но для Integer в Java есть нюанс: Integer может кешироваться до 127, и если мы вводим по единице в оба поля числа до 127, то фактически сравниваем просто int. А если вводим больше, то получаем два разных объекта. Адреса у объектов не совпадают, а именно так Java сравнивает их.

Есть два решения проблемы:

1. Изменить тип Integer на примитив int.
2. Сравнивать как объекты.

Не рекомендуется менять тип этих полей в реальном приложении: числа могут приходить извне, и тип лучше оставлять прежним. Изменим то, как мы сравниваем числа:

Всё работает. Наконец-то! Хотя… Давайте посмотрим, что будет, если пользователь ничего не введёт, но нажмёт на кнопку? Приложение опять упало… Смотрим в логи:

Опять NumberFormatException, при этом строка пустая. Давайте поставим точку останова на 26-й строке и заглянем с помощью отладчика глубже.

Нажмём F8 — и перейдём в глубины операционной системы:

Интересно! Давайте обернём код в try/catch и посмотрим ошибке в лицо. Если что, поправим приложение. Выделяем код внутри метода onClick() и нажимаем Ctrl+Alt+T:

Выбираем try / catch, среда разработки сама допишет код. Поставим точку останова. Получим:

Запускаем приложение и ловим ошибку:

Действительно, как и в логах, — NumberFormatException. Метод parseInt выбрасывает исключение, если в него передать пустую строку. Как обрабатывать такую проблему — решать исключительно вам. Два самых простых способа:

1. Проверять получаемые строки first.getText().toString() и second.getText().toString() на пустые значения. И если хоть одно значение пустое — говорить об этом пользователю и не вызывать метод parseInt.
2. Или использовать уже готовую конструкцию try / catch:

Теперь-то точно всё в порядке! Хотя профессиональным тестировщикам это приложение никто не отдавал: поищете ещё ошибки? 🙂

Иногда в приложении встречаются ошибки, которые нельзя увидеть даже после запуска. Например, код компилируется, проект запускается, но результат далёк от желаемого: приложение падает или вдруг появляется какая-то ошибка (баг). В таких случаях приходится «запасаться логами», «брать в руки отладчик» и искать ошибки.

Часто процесс поиска и исправления бага состоит из трёх шагов:

1. Воспроизведение ошибки — вы понимаете, какие действия нужно сделать в приложении, чтобы повторить ошибку.
2. Поиск места ошибки — определяете класс и метод, в котором ошибка происходит.
3. Исправление ошибки.

Если приложение не падает и чтение логов ничего не даёт, то найти точное место ошибки в коде помогает дебаггер (отладчик) — инструмент среды разработки.

Чтобы посмотреть на логи и воспользоваться дебаггером, давайте напишем простое тестовое (и заведомо неправильное) приложение, которое даст нам все возможности для поиска ошибок.

Это будет приложение, которое сравнивает два числа. Если числа равны, то будет выводиться результат «Равно», и наоборот. Начнём с простых шагов:

1. Открываем Android Studio.
2. Создаём проект с шаблоном Empty Activity.
3. Выбираем язык Java, так как его, как правило, знают больше людей, чем Kotlin.

Нам автоматически откроются две вкладки: activity_main.xml и MainActivity.java. Сначала нарисуем макет: просто замените всё, что есть в activity_main.xml, на код ниже:

Можете запустить проект и посмотреть, что получилось:

Теперь оживим наше приложение. Скопируйте в MainActivity этот код:

В этом коде всё просто:

1. Находим поля ввода, поле с текстом и кнопку.
2. Вешаем на кнопку слушатель нажатий.
3. По нажатию на кнопку получаем числа из полей ввода и сравниваем их.
4. В зависимости от результата выводим «Равно» или «Не равно».

Запустим приложение и введём буквы вместо чисел:

Нажмём на кнопку, и приложение упадёт! Время читать логи. Открываем внизу слева вкладку «6: Logcat» и видим:

Читать логи просто: нужно найти красный текст и прочитать сообщение системы. В нашем случае это java.lang.NumberFormatException: For input string: «f». Указан тип ошибки NumberFormatException, который говорит, что возникла какая-то проблема с форматированием числа. И дополнение: For input string: «f». Введено “f”. Уже можно догадаться, что программа ждёт число, а мы передаём ей символ. Далее в красном тексте видно и ссылку на проблемную строку: at com.example.appdebugging.MainActivity$1.onClick(MainActivity.java:26). Проблема в методе onClick класса MainActivity, строка 24. Можно просто кликнуть по ссылке и перейти на указанную строку:

Конечно, метод parseInt может принимать только числовые значения, но никак не буквенные! Даже в его описании это сказано — и мы можем увидеть, какой тип ошибки этот метод выбрасывает (NumberFormatException).

Здесь мы привели один из примеров. Типов ошибок может быть огромное количество, все мы рассматривать не будем. Но все ошибки в Logcat’е указываются по похожему принципу:

• красный текст;
• тип ошибки — в нашем случае это NumberFormatException;
• пояснение — у нас это For input string: «f»;
• ссылка на строку, на которой произошла ошибка — здесь видим MainActivity.java:26.

Исправим эту ошибку и обезопасим себя от некорректного ввода. Добавим в наши поля ввода android:inputType=»number», а остальной код оставим без изменений:

Теперь можем вводить только числа. Проверим, как работает равенство: введём одинаковые числа в оба поля. Всё в порядке:

На равенство проверили. Введём разные числа:

Тоже равно. То есть приложение работает, ничего не падает, но результат не совсем тот, который требуется. Наверняка вы и без дебаггинга догадались, в чём ошибка, потому что приложение очень простое, всего несколько строк кода. Но такие же проблемы возникают в приложениях и на миллион строк. Поэтому пройдём по уже известным нам этапам дебаггинга:

1. Воспроизведём ошибку: да, ошибка воспроизводится стабильно с любыми двумя разными числами.
2. Подумаем, где может быть ошибка: наверняка там, где сравниваются числа. Туда и будем смотреть.
3. Исправим ошибку: сначала найдём её с помощью дебаггера, а когда поймём, в чём проблема, — будем исправлять.

И здесь на помощь приходит отладчик. Для начала поставим точки останова сразу в трёх местах:

Чтобы поставить или снять точку останова, достаточно кликнуть левой кнопкой мыши справа от номера строки или поставить курсор на нужную строку, а затем нажать CTRL+F8. Почему мы хотим остановить программу именно там? Чтобы посмотреть, правильные ли числа сравниваются, а затем определить, в какую ветку в нашем ветвлении заходит программа дальше. Запускаем программу с помощью сочетания клавиш SHIFT+F9 или нажимаем на кнопку с жучком:

Появится дополнительное окно, в котором нужно выбрать ваш девайс и приложение:

Вы в режиме дебага. Обратите внимание на две вещи:

1. Точки останова теперь помечены галочками. Это значит, что вы находитесь на экране, где стоят эти точки, и что дебаггер готов к работе.
2. Открылось окно дебага внизу: вкладка «5: Debug». В нём будет отображаться необходимая вам информация.

Введём неравные числа и нажмём кнопку «РАВНО?». Программа остановилась на первой точке:

1. Сразу подсвечивается синим строка, где программа остановлена: в окне кода на 28-й строке и в левом окне отладчика (там даже можно увидеть, какой метод вызван, — onClick).
2. В правом, основном окне отладчика, всё гораздо интереснее. Здесь можно увидеть инстансы наших вью (answer, first, second), в конце которых серым текстом даже отображаются их id. Но интереснее всего посмотреть на firstInt и secondInt. Там записаны значения, которые мы сейчас будем сравнивать.

Как видим, значения именно такие, какие мы и ввели. Значит, проблема не в получении чисел из полей. Давайте двигаться дальше — нам нужно посмотреть, в правильную ли ветку мы заходим. Для этого можно нажать F8 (перейти на следующую строку выполнения кода). А если следующая точка останова далеко или в другом классе, можно нажать F9 — программа просто возобновит работу и остановится на следующей точке. В интерфейсе эти кнопки находятся здесь:

Остановить дебаггер, если он больше не нужен, можно через CTRL+F2 или кнопку «Стоп»:

В нашем случае неважно, какую кнопку нажимать (F9 или F8). Мы сразу переходим к следующей точке останова программы:

Ветка правильная, то есть логика программы верна, числа firstInt и secondInt не изменились. Зато мы сразу видим, что подпись некорректная! Вот в чём была ошибка. Исправим подпись и проверим программу ещё раз.

Мы уже починили два бага: падение приложения с помощью логов и некорректную логику (с помощью отладчика). Хеппи пас (happy path) пройден. То есть основная функциональность при корректных данных работает. Но нам надо проверить не только хеппи пас — пользователь может ввести что угодно. И программа может нормально работать в большинстве случаев, но вести себя странно в специфических состояниях. Давайте введём числа побольше и посмотрим, что будет:

Не сработало — программа хочет сказать, что 1000 не равна 1000, но это абсурд. Запускаем приложение в режиме отладки. Точка останова уже есть. Смотрим в отладчик:

Числа одинаковые, что могло пойти не так? Обращаем внимание на тип переменной — Integer. Так вот в чём проблема! Это не примитивный тип данных, а ссылочный. Ссылочные типы нельзя сравнивать через ==, потому что будут сравниваться ссылки объектов, а не они сами. Но для Integer в Java есть нюанс: Integer может кешироваться до 127, и если мы вводим по единице в оба поля числа до 127, то фактически сравниваем просто int. А если вводим больше, то получаем два разных объекта. Адреса у объектов не совпадают, а именно так Java сравнивает их.

Есть два решения проблемы:

1. Изменить тип Integer на примитив int.
2. Сравнивать как объекты.

Не рекомендуется менять тип этих полей в реальном приложении: числа могут приходить извне, и тип лучше оставлять прежним. Изменим то, как мы сравниваем числа:

Всё работает. Наконец-то! Хотя… Давайте посмотрим, что будет, если пользователь ничего не введёт, но нажмёт на кнопку? Приложение опять упало… Смотрим в логи:

Опять NumberFormatException, при этом строка пустая. Давайте поставим точку останова на 26-й строке и заглянем с помощью отладчика глубже.

Нажмём F8 — и перейдём в глубины операционной системы:

Интересно! Давайте обернём код в try/catch и посмотрим ошибке в лицо. Если что, поправим приложение. Выделяем код внутри метода onClick() и нажимаем Ctrl+Alt+T:

Выбираем try / catch, среда разработки сама допишет код. Поставим точку останова. Получим:

Запускаем приложение и ловим ошибку:

Действительно, как и в логах, — NumberFormatException. Метод parseInt выбрасывает исключение, если в него передать пустую строку. Как обрабатывать такую проблему — решать исключительно вам. Два самых простых способа:

1. Проверять получаемые строки first.getText().toString() и second.getText().toString() на пустые значения. И если хоть одно значение пустое — говорить об этом пользователю и не вызывать метод parseInt.
2. Или использовать уже готовую конструкцию try / catch:

Теперь-то точно всё в порядке! Хотя профессиональным тестировщикам это приложение никто не отдавал: поищете ещё ошибки? 🙂

Источник