Line no detect android

Методы лечения различных ошибок в Android Studio при разработке проекта

Сегодня хотел бы поделиться своим анализом и способами лечением разных ошибок при разработке своего продукта в Android Studio. Лично я, не раз сталкивался с различными проблемами и ошибками при компиляции и/или тестировании мобильного приложения. Данный процесс, всегда однообразный и в 99% случаев и всегда нужно тратить n-колличество времени на его устранение. Даже, когда ты уже сталкивался с данной проблемой, ты все равно идешь в поисковик и вспоминаешь, как же решить ту или иную ситуацию.

Я для себя завел файлик, в котором отметил самые частые ошибки — потратив на это несколько часов и перечислил самые популярные ошибки (в дальнейшем планирую просто их запомнить), чтоб сократить свое время в дальнейшем.

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

1) Если подчеркивает красным код, где используются ресурсы: R. — попробовать (но вероятно не поможет): Build -> Clean Project.

В принципе на Build -> Clean Project можно не терять времени, а лучше всего — слева переключиться на Project, открыть каталог .idea, затем каталог libraries и из него удалить все содержимое. Затем нажать кнопку Sync Project. А затем (если все еще красное, но скорее всего уже будет все ок ) Build -> Clean Project.

2) После внезапного выключения компьютера, после перезапуска может быть во всех проектах весь код красным. Перед этим может быть ошибка: Unable to create Debug Bridge: Unable to start adb server: Unable to obtain result of ‘adb version’. Есть три решения — первое помогло, второе нет (но может быть для другого случая), а третье — не пробовал:

а) File — Invalidate Caches/Restart — Invalidate and Restart

б) Закрыть студию. В корне папки проекта удалить файл(ы) .iml и папку .idea. Вновь запустить студию и импортировать проект.

в) Нажать Ctrl-Alt-O и запустить оптимизацию импорта.

Кстати, adb сервер можно проверить на версию (и работоспособность) и затем перезапустить:

3) Если Android Studio выдает приблизительно такую ошибку: Error:Execution failed for task ‘:app:dexDebug’.

Надо слева переключиться на опцию Project, найти и удалить папку build которая лежит в папке app, т.е. по пути app/build. Затем перестроить весь проект заново: Build -> Rebuild Project.

Такое же решение если ошибка типа: «не могу удалить (создать) папку или файл» и указан путь, который в ведет в app/build. Тоже удаляем папку build и ребилдим проект.

4) В сообщении об ошибке упоминается heap — виртуальная память. А ошибка обычно вызвана ее нехваткой, т.е. невозможностью получить запрашиваемый объем. Поэтому этот запрашиваемый объем надо уменьшить, т.е. переписать дефолтное значение (обычно 2048 MB которое можно изменить в настройках), на меньшее 1024 MB.

В файле проекта gradle.properties пишем:

5) Android Studio пришет примерно такую ошибку: Plugin is too old, please update to a more recent version, or set ANDROID_DAILY_OVERRIDE environment variable to «83648b99316049d63656d7276cb19cc7e95d70a5»

Возможные причины (кроме необходимости регулярного обновления SDK):

а) Загруженный проект был скомпилирован с помощью уже несовместимого старого gradle плагина. В этом случае надо найти и подключить в своем build.gradle проекта этот более старый плагин. т.е. попробовать более старые версии, например: 1.1.3 (часто именно 1.1.x и подходит).

Найти все версии можно здесь.

б) Если в build.gradle проекта используется beta-версия плагина — это означает, что срок ее истек. Посмотреть последние релизы (продакшн и бета) можно также здесь:

6) Иногда при подключении сторонних библиотек могут дублироваться некоторые файлы (обычно связанные с лицензированием). В сообщении будет что-то содержащее слова: duplicate files. Решение — надо посмотреть в сообщении об ошибке или в документации подключенной сторонней библиотеки — какие именно файлы стали избыточными, и перечислить их в build.gradle модуля для исключения (exclude) из билда.

Это делается в директиве packagingOptions (которая, в свою очередь, находится в директиве android).

Источник

Использование Lint в Android Studio для проверки своего кода

Содержание

На практике в коде очень часто можно встретить очевидные ошибки, спустя какое-то время. Это может происходить из-за невнимательности при написании кода. Что бы свести такие ошибки к минимуму могут помочь статические анализаторы кода. Одним из таких анализаторов является Lint.

Lint — это статический анализатор кода, который сообщает о подозрительных или критических выражениях в коде. По факту это слово стало нарицательным и им называют анализаторы, которые сканируют код на наличие ошибок.

В Android Studio уже есть встроенные анализаторы кода, который дают подсказки “налету”.

Однако подсказки подсвечивают ошибки достаточно ненавязчиво и поэтому их легко пропустить. Но можно запустить проверку несколькими способами.

Способы запуска Lint.

Запуск через меню в Android Studio

Самый простой и удобный способ запуска проверки — это через Android Studio. Для этого в меню необходимо выбрать пункты Analyze -> Inspect Code. В появившемся окне можно ограничить область сканирования кода. Можно проверить весь проект, определённый модуль или отдельный взятый класс. На мой взгляд самый полезных из пунктов — это проверка не закоммиченых файлов. Так же можно выбрать профиль с набором правил для проверки.

После выбора настроек можно начать проверку по нажатию на кнопку Ок. Когда проверка закончиться то появиться окно в котором все ошибки, и предупреждения будут выведены в специальном окне. Все замечания удобно собраны по типам с кратким описание причины и решением проблемы.

Запуск через командную строку

Так же проверку можно запустить через gradle выполнив в консоли команду:

После проверки сформируется отчёт в формате html, который можно посмотреть по следующему пути:

Этот способ менее удобный чем первый, так как отчёт формируется в отрыве от студии и для правки ошибок нужно постоянно переключаться между отчётом и IDE. Зато этот способ прекрасно подходит для случаев если проверку осуществляется на сервере, а в случае обнаружение ошибок, прикреплять файл с отчётом к письму.

Запуск при сборке проекта.

Можно автоматизировать запуск проверки lint, который будет осуществлять при каждой сборке проекта. Для этого необходимо зайти в настройки запуска проекта:

Добавить следующую строку:

Этот способ менее предпочтительный так как значительно замедлит скорость сборки и разработки.

Настройка gradle сборки

Так же lint проверку можно настроить в gradle файле.

• abortOnError: В случае обнаружение ошибки прекращается проверка.
• warningsAsErrors: определяет предупреждения как ошибки.
• lintConfig: путь к файлу проекта с настройками lint.

Если опция abortOnError включена, то при запуске сборки через gradle в случае обнаружении ошибки произойдёт исключение:

Настройка правил проверки lint

Отредактировать правила lint можно в настройках Android studio. Там же можно сделать отдельный конфигурационный профиль и использовать его.

Отключение проверки Lint с помощью анотаций в коде

Иногда бывают исключения, и может сложиться ситуация что необходимо отключить проверку какого-либо правила проверки для класса или метода. В Java коде это делается через аннотацию @SuppressLint(“NewApi”). В качестве параметра принимает строку названия проверки которую нужно исключить. Если нужно исключить все правила, то можно использовать следующую аннотацию:

Так же проверку можно обойти в xml файлах с помощью аттрибута tools:ignore=“NewApi,StringFormatInvalid”.

Выводы

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

Источник

Что такое Android Lint и как он помогает писать поддерживаемый код

Когда разработчик недостаточно осторожен, дела могут пойти весьма плохо. Например, классические упущения разработчика — использование новой версии API, которая не совместима со старым кодом, выполнение действий, которые требуют специальных пользовательских разрешений, пробелы в локализации приложения. И это только некоторые из них.

Кроме того, в Java и Kotlin, как и в любых других языках программирования, есть свои собственные конструкции, которые могут привести к снижению производительности.

Привет, Lint

Мы используем инструмент под названием Lint (или Linter) для избежания таких проблем. Lint — это инструмент для статического анализа кода, который помогает разработчикам изловить потенциальные проблемы ещё до того, как код скомпилируется. Lint выполняет многократные проверки исходного кода, которые могут обнаружить такие проблемы, как неиспользуемые переменные или аргументы функций, упрощение условий, неправильные области видимости, неопределённые переменные или функции, плохо оптимизированный код и т.д. Когда мы говорим о разработке для Android, существуют сотни проверок Lint, доступных «из коробки».

Но иногда нам нужно найти конкретные проблемы в нашем коде, которые не охватываются этими существующими проверками.

Привет, пользовательские проверки Lint

Прежде чем мы начнем кодить, давайте определим нашу цель и посмотрим, как реализовать её шаг за шагом с помощью Lint API. Цель состоит в том, чтобы создать проверку для обнаружения неправильного вызова метода для объекта. Идея этой проверки состоит в том, чтобы определить, является ли метод установки слушателя на View-компонент таким, который будет прерывать несколько последовательных кликов по компоненту, чтобы мы могли избежать открытия одной и той же Activity или обращения к сети несколько раз.

Пользовательские проверки Lint написаны как часть стандартного модуля Java (или Kotlin). Самый простой способ начать — создать простой проект на основе Gradle (это не обязательно должен быть проект Android).

Затем добавим зависимости Lint. В файле build.gradle вашего модуля добавьте:

Теперь есть хитрость, о которой я узнал, исследуя эту тему. lintVersion должен быть gradlePluginVersion + 23.0.0 . gradlePluginVersion — это переменная, определённая в файле build.gradle на уровне проекта. И на данный момент последняя стабильная версия — 3.3.0. Это означает, что lintVersion должен быть 26.3.0.

Каждая проверка Линт состоит из 4 частей:

• Проблема — проблема в нашем коде, которую мы пытаемся предотвратить. Когда проверка Lint завершается неудачей, то об этом сообщается разработчику.
• Детектор — инструмент для поиска проблемы, который предоставляет API Lint.
• Реализация — область, в которой может возникнуть проблема (исходный файл, файл XML, скомпилированный код и т.д.).
• Реестр — настраиваемый реестр проверок Lint, который будет использоваться вместе с существующим реестром, содержащим предопределённые проверки.

Реализация

Давайте начнём с создания реализации для нашей пользовательской проверки. Каждая реализация состоит из класса, который реализует детектор и область действия.

Помните, что Scope.JAVA_FILE_SCOPE также будет работать для классов Kotlin.

Проблема

Следующим шагом является использование этой реализации для определения проблемы. Каждая проблема состоит из нескольких частей:

• ID — уникальный идентификатор.
• Описание — краткое (5-6 слов) изложение проблемы.
• Объяснение — полное объяснение проблемы с предложением, как это исправить.
• Категория — категория проблемы (производительность, перевод, безопасность и т.д.).
• Приоритет — важность проблемы, в диапазоне от 1 до 10, где 10 является самым высоким. Это будет использоваться для сортировки проблем в отчёте, созданном при запуске Lint.
• Серьёзность — серьёзность проблемы (фатальная, ошибка, предупреждение, информация или игнорирование).
• Реализация — реализация, которая будет использоваться для обнаружения этой проблемы.

Детектор

Lint API предлагает интерфейсы для каждой области, которую вы можете определить в реализации. Каждый из этих интерфейсов предоставляет методы, которые вы можете переопределить и получить доступ к интересующим вас частям кода.

• UastScanner — файлы Java или Kotlin (UAST — Unified Abstract Syntax Tree (рус. унифицированное абстрактное синтаксическое дерево)).
• ClassScanner — скомпилированные файлы (байт-код).
• BinaryResourceScanner — двоичные ресурсы, такие как растровые изображения или файлы res/raw .
• ResourceFolderScanner — папки ресурсов (не конкретные файлы в них).
• XmlScanner — XML-файлы.
• GradleScanner — Gradle-файлы.
• OtherFileScanner — всё остальное.

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

Теперь мы готовы реализовать детектор, который будет проверять правильный вызов метода для объекта.

Реестр

Последнее, что нам нужно сделать, это добавить проблемы в наш реестр и сообщить Lint, что существует специальный реестр проблем, который он должен использовать наряду со стандартным.

В build.gradle уровня модуля:

где co.infinum.lint — это пакет класса MyIssueRegistry . Теперь вы можете запустить задачу jar , используя скрипт gradlew , и библиотека должна появиться в каталоге build/libs .

Здесь есть ещё один пример пользовательской проверки Lint, где вы можете увидеть, как обрабатывать XML-файлы.

Использование

Ваша новая проверка Lint готова к использованию в проекте. Если эту проверку можно применить ко всем проектам, вы можете поместить её в папку

/.android/lint (вы можете создать её, если она ещё не существует).

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

Стоит ли оно того?

Lint — действительно хороший инструмент, который следует использовать каждому разработчику. Возможность обнаружить потенциальные проблемы с вашим кодом на раннем этапе очень полезна. Хотя настраиваемые проверки писать не так просто, в основном из-за сложности API, они определённо стоят того и могут сэкономить много времени и усилий в будущем.

Источник