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

Кстати, параллельно этому разбору разработчик нашёл баг и в самой Windows. В Windows есть пециальный параметр в реестре, которым можно увеличить таймаут на завершение сервиса. И этот параметр не рабтает в Win7/2003: https://support.microsoft.com/en-us/help/2549760/waittokillservicetimeout-registry-value-does-not-work-in-windows-7-or Примечательно, что MS знал уже об этом баге, а разработчик просто нашёл его при исследовании. После обнаружения проверил на сайте MS и нашёл, что даже патч есть, но персональный. То есть персональным он был на тот момент, сейчас уже, наверное, раскатан на всех.

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

Когда покупаете рекламу, тщательно выбирайте площадки и способы распространения. Потому что может получиться вот так.

Дизайн 2/5, конечно.

Я тут выяснил, что очень многие не понимают, что такое каналы уведомлений (Notification Channel) в современных версиях Android, зачем они вообще нужны и как их применять.

Каналы нужны для того, чтобы пользователь мог управлять уведомлениями разной сути отдельно от других. К примеру, ваш продукт умеет создавать web сервер, smb сервер и ftp сервер. И пользователь держит ftp всё время включенным, а остальные включает время от времени.
Для того, чтобы система вас не убивала как можно дольше, вы используете foreground service, а значит отображаетесь в уведомлениях. И пользователя разжражает лишняя плашка, ведь он и так помнит, что FTP сервер вечно запущен. Так что он может отключить этот канал. С вашей стороны разумно три разных уведомления разделить в три разных канала. Тогда отключение канала с уведомлением для FTP никак не затронет другие два.
Более того, пользователь может настроить все каналы по-разному. Одному добавит звуковое уведомление при старте, а другому не разрешит включать погашенный экран.

Пример с KIS для Android. Пользователей раздражает вечно весящее уведомление о работе. Но если его убрать, отвалится часть функционала продукта на Android 8 и новее. Я предложил команде сделать разные каналы для разных событий. Но главное, выделить постоянное уведомление в отдельный канал типа «Persistent notification». Тогда пользователь сможет спокойно убрать именно это уведомление, но при этом получать другие уведомления продукта — о старте обновлений баз, об обнаружении угрозы. Надеюсь, это дотащат до релиза. По крайней мере концепт уже сделан.

Но есть обратные примеры. Скажем, Telegram создаёт по одному каналу уведомлений на каждый из чатиков. Включая приватные чаты и каналы. И не удаляет их. Этим он частично раскрывает вас, как пользователя. Скажем, вы запаролили вход в ТГ. Но можно открыть настройки уведомлений ТГ и увидеть там каналы, на которые вы подписаны, увидеть, с кем вы переписывались, даже если вы уже удалили эти переписки. Можете проверить сами и убедиться. Не удаление этих каналов уведомлений сливает о вас данные, которые вы хотели бы скрыть.
Строго говоря, я считаю это уязвимостью, ставящую под угрозу мою приватность.
При этом не понятно, зачем создавать канал на каждый чат, если проще из самого приложения управлять уведомлениями конкретного чата. Правильным было бы иметь один канал на сервисные сообщения, один канал на обычные сообщения, один на приватные (те, у которых время уничтожения задаётся) и один "на всякий случай". Тогда бы пользователь мог глобально настроить, чтобы все секретные чаты не показывали уведомлений и не включали экран. Сейчас же нельзя настроить такое поведение и это противоречит идее каналов уведомлений.

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

Дополнение про каналы уведомлений. К сожалению, в Android 8.0 (именно .0, но не в 8.1 и выше) есть баг. Если вы сделаете канал типа Persistent notification, чтобы пользователь мог его штатно скрыть, то ему тут же вывалится другое уведомление, уже от ОС. В нём будет сказано что-то вроде "Приложение ХХХ работает в фоне" или что-то такое. В общем, намекать будет на расход батарейки.

Ошибка в Андроид в том, что пользователь и так знал, что приложение работает в фоне, он видел это по постоянно висящему не смахиваемому уведомлению (которое создаёт foreground service этого приложения). И он сам, своими руками, скрыл это уведомление. Зачем ему сообщать о том, что он и так знает? При этом сообщать это другом не смахиваемым уведомлением. Бред же.

Этот бред исправлен в 8.1 и новее. Так что будьте готовы к такому поведению в 8.0.

У вас есть несколько способов убрать это раздражающее уведомление и ни один из них не является хорошим:
1. Дать пользователю инструкцию, как в системе отключить канал, сообщающих о фоновых работах. То есть даже когда это уведомление действительно будет нужно, пользователь его не увидит.
2. Запросить права на управление уведомлениями. Эта фича появилась в Android 4.3. Тогда вы сможете скрывать чужие уведомления. _ВОЗМОЖНО_ сможете скрыть и это. Честно говоря, я не проверял.

В общем, остаётся только объяснить пользователям 8.0, что, так и так, если вы скрываете постоянное уведомление, вам придётся скрыть предупреждающее уведомление от системы.

Зная Google, никакие обновления от 1 и 5 чисел каждого месяца не будут исправлять эту ошибку.

Классика — опечататься в названии компании. Это 2013 год. С тех пор, вроде, такого не встречалось.

Но я не об этом. Сейчас расскажу об одном более-менее интересном баге, который нашёл буквально вслепую. Она была в коде, который считался недостижимым (Unreachable code).

Возможно кто-то из вас помнит про очень старую уязвимость у многих производителей Android прошивок. Она была связана с USSD кодом *2767*3855#. Этот код вызывал hard reset огромного множества устройств без подтверждения пользователя. То есть можно было на сайте разместить ссылку <frame src="tel:*2767*3855%23" /> и при заходе на страничку телефон сразу форматировался.

Многие производители как прошивок, так и security решений срочно выпустили маленькие приложения, которые становились звонилками по умолчанию. Всё, что они делали — не прокидыали именно этот USSD в системную звонилку, а всё остальное прокидывали молча. Проксировали, в общем.

Лаборатория не стала делать отдельную утилиту, а выпустила обновление антивируса с такой функциональность.

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

Раскатали релиз, всё шло хорошо. В следующем релизе убрали и прокси-звонилку. И всё и дальше шло бы хорошо, если бы через какое-то время Google не представил супер новую невиданную ранее фичу — Okay Google. И пошли редкие, но достаточно стабильные падения в вызове кода, который нельзя было вызвать. А падало потому что и кода уже не было.

Поставили мне задачу понять, как это происходит. Как вообще людям удаётся достать недостижимый код. Я пробовал и по ссылка tel: тыкать, и в SMS их присылал, и звонилки разные пробовал, и USSD код этот вызывал. Пока не сказал Okay Google call one one two. И продукт упал.

Этот код вызывался в сценарии, которого вообще не существовало во время его написания. Он вызывался только через Окей Гугл. Ассистент (тогда ещё не было Ассистента, до его появления было ещё несколько лет, но пусть будет он) дёргал вызов, который пропустили при вырезании этой фичи.

Фикс был очень простым и быстрым. А вот его обнаружение было тем ещё развлечением.

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

Любой тестировщик со временем начинает мыслить очень творчески. Это помогает.

Я не умер, я в отпуске. А потому короткая история о том, как делать не надо.
В свой первый отпуск 10 (или уже 11?) лет назад я ушёл, подложив говна под дверью команды, образно говоря.
В день подписания релиза, когда высокоприоритетных ошибок уже не было, я решил проверить, что будет, если отправлять в драйверы продукта некорректные вызовы.
Сейчас мне очевидно, что это была хоть и правильная проверка, но не вовремя. Такое нужно делать сильно заранее.
В общем, эти тесты отправляли XP в синяк. Я записал баг высокого приоритета (а это стоп релиза), встал из-за стола, взял рюкзак и свалил.

Потом узнал, что меня искали, чтобы объяснить мне, что делать так не очень хорошо и что если уж нашёл что-то такое в столь поздние сроки, то будь добр, донеси это до команды сначала.

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

Баг был в Windows XP самом, кстати. Драйвер лишь дал возможность на него напороться. Фикс был в банальном запрете этого вызова.

Мир свернул сильно не туда, когда дал управление маркетологам и продажникам. Да, понятно, что все хотят денег (и я, и вы), но всё же нужно знать меру.
Это скриншот сетевых запросов от браузера, когда пользователь пытается прочитать Privacy Statement для продукта, который собирается использовать.
Это не ошибка, всё здесь "правильно". Я специально писал письмо со своим недовольством по такому поведению, но нет, здесь всё юридически честно и чисто.

Но меня это всё равно печалит. Неправильно это. Неправильно не конкретно из-за компании, а неправильно вообще, в общем и в целом. Ведь так делают вообще все.

Все, кто хотел, прошли дополнение ко второй (в современном перезапуске) Ларе про Бабу Ягу? Там есть такая ачивка, описание которой меня расстроило. Точнее, перевод на русский язык:
https://pbs.twimg.com/media/DX86STNWAAAdODo.jpg:large

Ну и чтобы два раза не вставать: https://pbs.twimg.com/media/DMrxy7FXcAAMS6n.jpg:large AAA игра от главного игродела Сони. И такой фейл — отпечаток протектора не зависит от рисунка протектора.

Баг, который я писал на самых разных проектах, которым помогал. Просто потому что раньше об этом не задумывались.
Ни одно ваше приложение не может отправлять никаких статистик и не делать никаких сетевых запросов (и вообще работать) до того, как пользователь примет EULA. Следите за этим в своих тестах.

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

Откопал баг уровня "олды помнят" (хотя не особо и олды, конечно).
Сам баг: