"Яндекс" говорит, что исправил ошибку в Яндекс.Метро для Android, из-за которой приложение фоном отправляло данные о местоположении пользователя на сервера компании, - пост о выпуске новой версии с исправленным поведением опубликован на Хабре.
Однако, в публикации на Хабре нет четко-сформулированного описания ошибки. Следите за руками:
Существование проблемы постоянных фоновых загрузок на сервер признается:
[М]ы исправили ошибки, приводившие к описанному поведению. Сейчас оно раскатывается в сторе. Напомним, что приложение в фоновом режиме могло отправлять данные на сервера Яндекса. Мы в изначальном посте сразу же ответили, что это баг и такое поведение не было заложено в Метро.
Затем говорится, где внутри приложения был расположен код загрузки:
Как же возникла эта ошибка? Отправка статистики была вставлена в обработчик Application.onCreate(), который вызывается каждый раз при инициализации любого из процессов Метро, не учитывая, что бывают не только запуски приложения пользователем, но и фоновые вызовы процессов приложения.
Но откуда и почему код onCreate() вызывался с высокой частотой в посте однозначно не говорится.
В тексте есть объяснение, зачем приложению нужно было разрешение на старт при запуске системы:
Яндекс.Метро было подписано на событие загрузки системы, потому что в нём есть опциональная возможность включить поисковый виджет в области нотификаций, который должен загружаться вместе со стартом системы. Процесс Метро запускается в процессе загрузки ОС, проверяет состояние этой опции и, если виджет не включен, выходит, заканчивая свою работу.
Однако старт при запуске не объясняет ежеминутной загрузки данных о местоположении пользователя.
В тексте также упоминается, что Яндекс.Метрика для приложений (система сбора статистики, которую создатели приложений могут внедрить в свои продукты) не пытается работать с сетью в каждом приложении, в котором установлена, а выбирает одно приложение на телефоне как ведущее, создаёт в его рамках отдельным процессом сервис, через который все остальные приложения отправляют свою статистику. И таким «главным» приложением может быть выбрано любое из тех, где есть "Метрика" (в том числе и "Метро").
Также в тексте упоминается, что на время жизни процесса приложения влияет виджет.
В итоге, "Яндекс" признает проблему, признает, что эта проблема может быть не только в Яндекс.Метро, но и в других приложениях компании. Но не дает четкого ответа, откуда и почему код отправки местоположения пользователя вызывался у некоторых клиентов раз в минуту.
Добавить 7 комментариев
действительно четкий ответ, код отправки вызывался потому, что вызывался
Антон, прошу прощения, я мало знаком с устройством и жизненным циклом приложений в Андроиде, но вы пишите:
«потому, что вызывался в некоторых случаях при каждом вызове кода приложения».
А «код приложения» кем вызывался каждую минуту и зачем?
Причем, насколько я понимаю, не только код вызывался каждую минуту, но и ОС зачем-то между вызовами прибивала приложение и затем создавала его из-за вызова «кода приложения».
В чем же там было дело?
Я не знаю как именно было в метро, но система действительно может убивать приложение и снова перезапускать его и особенно часто она делает это с фоновыми сервисами на девайсах с небольшим количеством оперативной памяти (см, например, http://developer.android.com/guide/components/processes-and-threads.html). Ну а перезапуск приложения->вызов кода приложения->отправка местоположения (вот тут, собственно, и был баг).
Ильдар,
ну вот Яндекс пишет пост на Хабр для программистов, почему бы не объяснить более подробно, что у них там произошло? раз уж история получила такое внимание.
С конкретным пояснением, как вызывался злополучный код, и какая особенность Андроида привела к такому результату.
А то в начале Яндекс говорил, что это вообще крайне редкая ошибка, и именно из-за редкости ее пропустили при тестировании. Вместе с тем, в первом тредике по этой теме на Роеме был далеко не один комментарий с жалобами на подобное поведение приложения, и у людей были вполне приличные устройства, типа пятых нексусов.
Кроме того, оказывается, что это не просто какой-то баг по невнимательности, а проблемы с дизайном, которые касаются и других приложений Яндекса.
В общем, «код отправки вызывался потому, что вызывался» — это не очень четкое объяснение, по-моему :-)
В тексте на Хабре, кстати, не просто так упомянута Метрика.
По всей видимости именно Метрика из других приложений дергала что-то в Метро (какой-то сервис?) и это порождало создание процесса с вызовом кода в блоке инициализации. Вместе с тем сервис отрабатывал быстро и завершался, так что что при следующем вызове через короткое время сервис опять пересоздавался вместе с процессом, что опять дергало злополучный код.
Комментарий господина Волнухина на Хабре:
«Просто сейчас Яндекс.Метрика работает всегда через один конкретный свой инстанс (с самой свежей версией). В вашем случае это, очевидно, инстанс в Яндекс.Метро. Т.е. отправляется статистика Такси, но делается это через код Метрики в Метро.
Я признаю, что выглядит это чуть запутано, но, увы, это технически обосновано в Андроиде. И точно не является слежкой. «
И чуть-чуть о троянских конях:
«Яндекс» купил израильский стартап KitLocate… он разрабатывает технологию, которая позволяет собирать геоданные, почти не разряжая смартфон пользователя.
«Яндекс» купил экономный к батарее GPS-трекер для таргетирования рекламы → Roem.ru