Ответ No changes detected в продуктах JetBrains при попытке сделать коммит

Якобы изменений нет

    Если вы столкнулись с ответом git «No changes detected» в ваших Android Studio,  PyCharm, Intelij IDEA PhpStorm и прочих, то это для вас. Другое проявление проблемы — когда вы пишете новый код или изменяете существующий, сбоку нет этих цветных полос, уведомляющих об изменённых участках кода.

MS TFS REST API через боль и слёзы

Первый подход к снаряду. Выглядит так себе

    Раскуриваю REST API у TFS и мне хочется выть. Нет, возможно это нормально для больших и ветвистых проектов, а мои знания в прошлые разы были слишком простыми, т.к. строились на несложных опен сорсных проектах типа STF https://github.com/openstf/stf и подобных. И из-за этого у меня сложилось ложное впечатлиение, что REST API, это когда просто потянул за верёвочку и всё тебе пришло или толкнул коробку с данными, которые быстро набросал туда и всё снова работает.

    Но Microsoft мне показал, насколько я неправ.

Форматирование карты памяти как внутренней памяти. Возвращение Android Adoptable Storage

Получаем вот этот экран

    В Android 6, кроме прочего, появилась встроенная возможность форматировать карточки памяти как часть внутренней памяти — adoptable storage. Это отлично, это удобно. Конечно, мрази-производители убирали эту возможность, но МОЖЕТ БЫТЬ решение ниже может помогать и в случае таких производителей.

    В моём же варианте речь про Android Emulator. Дело в том, что
ещё недавно образы в эмуляторе позволяли форматировать «карты памяти» так, чтобы они становились внутренней памятью. Без этого вы не можете, к примеру, выполнить простое

adb push myDir /sdcard/

Проблема запуска Android emulator из командной строки

Хочется, но не удаётся

    Если вы попытались запустить эмулятор Android из командной строки и словили ошибку

ERROR:android/android-emu/android/qt/qt_setup.cpp:28:Qt library not found at ../emulator/lib64/qt/lib

для GNU/Linux или

emulator/qemu/windows-x86_64/qemu-system-i386.exe': No such file or directory

для Windows, то вам сюда.

Негативные сценарии тестирования

    Ииииииии... Это последняя запись из цикла! Она самая короткая, самая простая и практически целиком состоит из реальных историй. По возможности — глупо-смешных. Даже есть видео, снятое специально для записи вот прямо в момент написания. Свежачок-с. К сожалению, я не догадался снять скриншот с сообщением о падении Youtube клиента, он бы подошёл. Упал прямо при заливке того ролика, который вставлен в статью. Ладно, пусть будет мой экран блокировки.

    На старте тестирования, вне зависимости от того, новый это проект или такой, что его стоило бы уже похоронить, в целом всегда ясно, с чего начинать. Если, конечно, к момент старта тестирования ни одно из звеньев цепи не слажало. Обычно тестировщики вычитывают требования и прочие документы с нерусскими названиями, типа «БиЭрКью», «ЭсАрки» и «Юзер стори» и прикидывают, как написать тест кейс, чтобы он проверил выполенения всех этих документов. Это всё понятно, на поверхности и нет смысла на этом задерживаться. Но есть ещё поведение самого Android, о котором иногда не знают не то что аналитики, но даже архитекторы и некоторые разработчики. А помня, что с AOSP никто не работает, только с кастомами, таких особенностей всплывает довольно много. И я говорю не о стрессовых сценариях, когда памяти нет или батарейку внезапно вынули (как-то встречал негодование человека на терминал GNU/Linux, что тот не показывает пароль при вводе, а у него глючная клавиатура и он не понимает, вводит пароль или же это клавиатура снова не работает), а о штатном поведении кастомизации Android и даже поведении, заложенном в AOSP. То есть штатные поведения системы, которые могут отрицательно сказаться на тестируемом продукте. Так называемые, негативные сценарии.

Android SDK. Тестируем по-настоящему!

    Эта запись — предпоследняя из всего цикла. Пожалуй, она самая скучная, однако она ближе всего к тому, что называется тестированием. И, мне кажется, она ещё и самая длинная. Я попытался разбавить всю эту скукоту наглядными примерами, скриншотами. Книги с картинками читают охотнее? По крайней мере популярные «блоггеры» (а я — популярный, у меня есть минимум 8 читателей, скоро продамся кому-нибудь и работать перестану!) часто ставят всякие картинки, возможно это и работает.

    Как бы то ни было, здесь можно получить минимальное понимание того, что есть в Android SDK и что из этого нужно тестировщику. А главное — зачем. Ещё тут есть море грамматических ошибок, наверное, так как писать большую часть текста приходилось ночью, а я по ночам люблю спать и после 22 часов, как правило, уже сплю.

    Уверен, вам было интересно узнать, во сколько я засыпаю. Читайте дальше, там ещё интереснее!

 Android SDK

    Мы подбираемся всё ближе и ближе к инструментам и методам тестирования. Инструменты для тестирования, а также всякий вспомогательный инструментарий, входит в состави Android SDK. Самые нужные компоненты из состава SDK, конкретно для тестировщиков, это инструменты SDK, они же SDK tools, инструменты сборки, они же Build tools (внезапно, да?) и инструменты платформы, они же Platform tools. Нет никакого смысла запоминать это. Я просто сказал названия папок из установленного пакета Android SDK:

Рис. 1. Содержание папки Android SDK

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

Исследовательское тестирование как метод изучения Android

Картинка без смысла

    Вторая часть лекции рассматривает реальные проблемы на реальных устройствах. Все рассмотренные проблемы вызваны архитектурой системы, Если точнее, изменениями, которые вносят некоторые производители в архитектуру, а приложения ничего с этим сделать не могут, потому что не имеют возможности влиять на работу системы. Использовать буду только реальные ситуации и, по возможности, буду давать ссылки в баг-трекер Google, чтобы каждый мог убедиться, что это всё не выдумки.

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

    Сразу нужно уяснить, что более-менее одинаковые реализации Android есть лишь у горстки производителей. И ситуация, когда на одной и той же модели устройства, но выпущенные в разных странах или даже в одной стране, но от разных операторов, используются разные прошивки — это жестокая реальность! Прошивка — это не ОС Android, а всё, под чем работает устройство. Начиная от загрузчика, заканчивая доступными в Android на этом устройстве языками и предустановленными приложениями с их настройками. ОС Android — это лишь часть прошивки.

    Все ключевые термины, что описано ниже, вы уже встречали в предыдущей статье из этого цикла. Теперь дополним понимание этих терминов с той стороны, которая называется «исследовательское регрессионное тестирование». Регрессионное здесь — потому что я буду описывать проблемы, которые появлялись из-за обновлений системы.

Основы понимания приложений

    Этой записью я открою короткий цикл длинных и скучных (не просто так же имя блогу дано!) статей о тестировании приложений под Android. Здесь теория, теория, теория, вперемешку с историями «из жизни», которые, конечно, наиболее ценны (для меня).
    Все статьи буду идти от очень общего к частностям. Это поможет сначала разобраться с тем, как всё работает, как устроено, как называется, а затем — жонглировать этими теоретическими знаниями. Например в этой, открывающей статье, я сначала расскажу вскользь о компонентах приложений, затем расскажу о них подробно, а затем — добавлю понимания, где можно найти эти компоненты. Так будет построена каждая последующая статья, но, кроме того, каждая последующая будет сильно завязана на каждую предыдущую. Так что если уж решили подтянуть уровень понимания Android и исследовательского тестирования приложений под Android, стоит читать всё.
    К чёрту, приступим!

    Программный код пишется, в основном, на Java. То есть вы можете писать на чём угодно, хоть на той же Scala, да хоть на Python. Но тут есть свои подводные камни, очевидные и не очевидные. Можно писать и на C и нативный код будет работать также быстро, как и Java (слова «быстро» и «Java» в одном предложении и даже нет слова «память», спешите видеть!), возможно даже быстрее, но это дороже в скорости разработки и затратах на сопровождение.
Итак, код пишется на Java. Далее Android SDK (Software Development Kit — набор средств для разработки) собирает код и все требуемые файлы ресурсов в файл APK (Android Application Package) — программный пакет Android, который суть — zip файл с расширением .apk. То, что это zip, легко убедиться, посмотрев на заголовок, где мы увидим буквы PK:

    Ну или «РК» — РосКом и многозначительное многоточие… Кстати, а кто помнит, какие буквы находятся в заголовках exe и dll файлов и что они означают? Это буквы MZ — инициалы Марка Зибовски, бывшего архитектора компании Microsoft, который был одним из создателей MS DOS. Он и разработал этот формат исполняемых файлов, который заменил собой устаревший .com. Пятиминутка бесполезных знаний!

Не используйте aapt для удаления файлов из apk

    Очень короткая запись про то, что aapt не стоит использовать для модификации apk файлов, лучше 7z подтянуть или иное решение. А ещё лучше, конечно, свалить в Новую Зеландию или Таиланд на ПМЖ, чего уж тут. Открыт для ваших предложений =)

В Android аду есть специальное место для Samsung

    Это перевод вот этой записи: http://verybadalloc.com/android/2015/12/19/special-place-for-samsung-in-android-hell/. Как всегда, рекомендую читать в оригинале, если есть такая возможность.
    Отказ от отвественности: если вы здесь только чтобы услышать, как кто-то поносит Samsung, проматывайте вниз. И да, вы пришли по назначению.
    Если вы используете библиотеку поддержки appcompat (конечно же используете), то могли видеть вот такой стек трейс  с Статистике падений от устройств Samsung под Android 4.2.2:

java.lang.NoClassDefFoundError: android.support.v7.internal.view.menu.MenuBuilder
at android.support.v7.app.ActionBarActivityDelegateBase.initializePanelMenu(ActionBarActivityDelegateBase.java:991)
at android.support.v7.app.ActionBarActivityDelegateBase.preparePanel(ActionBarActivityDelegateBase.java:1041)
at android.support.v7.app.ActionBarActivityDelegateBase.doInvalidatePanelMenu(ActionBarActivityDelegateBase.java:1259)
at android.support.v7.app.ActionBarActivityDelegateBase.access$100(ActionBarActivityDelegateBase.java:80)
at android.support.v7.app.ActionBarActivityDelegateBase$1.run(ActionBarActivityDelegateBase.java:116)
at android.os.Handler.handleCallback(Handler.java:725)
at android.os.Handler.dispatchMessage(Handler.java:92)
at android.os.Looper.loop(Looper.java:176)
at android.app.ActivityThread.main(ActivityThread.java:5299)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:511)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1102)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:869)
at dalvik.system.NativeStart.main(Native Method)