«Яндекс» не захотел объяснить, почему «Метро» фоном отправляло данные о местоположении пользователя

Развитие событий: Приложения для Android массово уличили в тайной от пользователя активности (6 мая 2015)

"Яндекс" говорит, что исправил ошибку в Яндекс.Метро для Android, из-за которой приложение фоном отправляло данные о местоположении пользователя на сервера компании, - пост о выпуске новой версии с исправленным поведением опубликован на Хабре.

Однако, в публикации на Хабре нет четко-сформулированного описания ошибки. Следите за руками:

Существование проблемы постоянных фоновых загрузок на сервер признается:

[М]ы исправили ошибки, приводившие к описанному поведению. Сейчас оно раскатывается в сторе. Напомним, что приложение в фоновом режиме могло отправлять данные на сервера Яндекса. Мы в изначальном посте сразу же ответили, что это баг и такое поведение не было заложено в Метро.

Затем говорится, где внутри приложения был расположен код загрузки:

Как же возникла эта ошибка? Отправка статистики была вставлена в обработчик Application.onCreate(), который вызывается каждый раз при инициализации любого из процессов Метро, не учитывая, что бывают не только запуски приложения пользователем, но и фоновые вызовы процессов приложения.

Но откуда и почему код onCreate() вызывался с высокой частотой в посте однозначно не говорится.

В тексте есть объяснение, зачем приложению нужно было разрешение на старт при запуске системы:

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

Однако старт при запуске не объясняет ежеминутной загрузки данных о местоположении пользователя.

В тексте также упоминается, что Яндекс.Метрика для приложений (система сбора статистики, которую создатели приложений могут внедрить в свои продукты) не пытается работать с сетью в каждом приложении, в котором установлена, а выбирает одно приложение на телефоне как ведущее, создаёт в его рамках отдельным процессом сервис, через который все остальные приложения отправляют свою статистику. И таким «главным» приложением может быть выбрано любое из тех, где есть "Метрика" (в том числе и "Метро").

Также в тексте упоминается, что на время жизни процесса приложения влияет виджет.

В итоге, "Яндекс" признает проблему, признает, что эта проблема может быть не только в Яндекс.Метро, но и в других приложениях компании. Но не дает четкого ответа, откуда и почему код отправки местоположения пользователя вызывался у некоторых клиентов раз в минуту.

Странности в работе Яндекс.Метро: разбор полётов и апдейт приложения

Добавить 7 комментариев

  • Ответить

    Антон, прошу прощения, я мало знаком с устройством и жизненным циклом приложений в Андроиде, но вы пишите:

    «потому, что вызывался в некоторых случаях при каждом вызове кода приложения».

    А «код приложения» кем вызывался каждую минуту и зачем?

    Причем, насколько я понимаю, не только код вызывался каждую минуту, но и ОС зачем-то между вызовами прибивала приложение и затем создавала его из-за вызова «кода приложения».

    В чем же там было дело?

  • Ответить

    Я не знаю как именно было в метро, но система действительно может убивать приложение и снова перезапускать его и особенно часто она делает это с фоновыми сервисами на девайсах с небольшим количеством оперативной памяти (см, например, http://developer.android.com/guide/components/processes-and-threads.html). Ну а перезапуск приложения->вызов кода приложения->отправка местоположения (вот тут, собственно, и был баг).

  • Ответить

    Ильдар,

    ну вот Яндекс пишет пост на Хабр для программистов, почему бы не объяснить более подробно, что у них там произошло? раз уж история получила такое внимание.

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

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

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

    В общем, «код отправки вызывался потому, что вызывался» — это не очень четкое объяснение, по-моему :-)

  • Ответить

    В тексте на Хабре, кстати, не просто так упомянута Метрика.

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

    Комментарий господина Волнухина на Хабре:

    «Просто сейчас Яндекс.Метрика работает всегда через один конкретный свой инстанс (с самой свежей версией). В вашем случае это, очевидно, инстанс в Яндекс.Метро. Т.е. отправляется статистика Такси, но делается это через код Метрики в Метро.

    Я признаю, что выглядит это чуть запутано, но, увы, это технически обосновано в Андроиде. И точно не является слежкой. «

  • Ответить

    И чуть-чуть о троянских конях:
    «Яндекс» купил израильский стартап KitLocate… он разрабатывает технологию, которая позволяет собирать геоданные, почти не разряжая смартфон пользователя.

    «Яндекс» купил экономный к батарее GPS-трекер для таргетирования рекламы → Roem.ru