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

Часть 1: Выбор сенсора для подсчета шагов: от акселерометра до Step Counter

1. "Дедовский" метод: Sensor.TYPE_ACCELEROMETER

Начиная с Android 1.5 (API 3), в устройствах появился акселерометр. Он измеряет проекцию ускорения устройства по трём осям (X, Y, Z), включая силу гравитации. Мы сталкиваемся с его работой каждый день, например, при автоматическом повороте экрана.

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

Ключевые недостатки:

• Высокое энергопотребление: Постоянный анализ данных с акселерометра на основном процессоре критически быстро разряжает батарею.

• Ограничения фоновой работы: Начиная с Android 8.0 (API 26), система накладывает серьезные ограничения на фоновую работу приложений. Это приводит к тому, что подсчет шагов останавливается и данные теряются, как только приложение переходит в фон.

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

2. Детектор шагов в реальном времени: Sensor.TYPE_STEP_DETECTOR

Начиная с Android 4.4 (API 19), появился специализированный аппаратно-ускоренный сенсор, который значительно упростил задачу. Sensor.TYPE_STEP_DETECTOR определяет шаги пользователя в реальном времени.

Под капотом он использует данные с того же акселерометра (и гироскопа, если он есть), но их обработка происходит на уровне системы, часто с использованием Sensor Hub — энергоэффективного сопроцессора. Это снимает с разработчика необходимость писать собственный алгоритм и позволяет экономить заряд батареи. Сенсор срабатывает на каждый обнаруженный шаг, возвращая событие.

Важное примечание: Начиная с Android 10 (API 29), для доступа к этому сенсору требуется получить у пользователя разрешение android.permission.ACTIVITY_RECOGNITION.

Пример кода (Kotlin):

override fun onSensorChanged(event: SensorEvent?) {
    event?.let {
        if (it.sensor.type == Sensor.TYPE_STEP_DETECTOR) {
            // Событие срабатывает на каждый шаг. Значение всегда равно 1.0f.
            val stepDetected = it.values[0] 
            // Здесь мы инкрементируем счетчик и сохраняем его в БД.
        }
    }
}

Выводы: Sensor.TYPE_STEP_DETECTOR полезен для приложений, которым нужно мгновенно реагировать на шаги — например, для интерактивных игр или фитнес-трекеров, отображающих анимацию во время ходьбы. Однако для простого подсчета суточной активности он избыточен, так как требует постоянной работы слушателя и ручного суммирования.

3. Золотой стандарт: Sensor.TYPE_STEP_COUNTER

Вместе с детектором в Android 4.4 (API 19) был добавлен и счетчик шагов — Sensor.TYPE_STEP_COUNTER. Это самый точный и энергоэффективный способ для подавляющего большинства задач.

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

Пример кода (Kotlin):

override fun onSensorChanged(event: SensorEvent?) {
    if (event?.sensor?.type == Sensor.TYPE_STEP_COUNTER) {
        val totalStepsSinceReboot = event.values[0].toInt()
        // Это общее число шагов с последней перезагрузки.
        // Сохраняем и обрабатываем это значение в своей логике.
    }
}

Сложности реализации и как их решать

Работа с TYPE_STEP_COUNTER требует более сложной логики со стороны приложения, так как мы получаем "сырое" значение от системы. Необходимо обработать как минимум три важных сценария:

1. Ежедневный сброс и сохранение: Чтобы считать шаги за конкретный день, приложение должно:

   • При первом запуске сохранить текущее значение totalStepsSinceReboot как точку отсчета.

   • Запустить фоновую задачу (через WorkManager или AlarmManager), которая будет срабатывать ровно в 00:00. В этот момент она должна зафиксировать и сохранить количество шагов за прошедший день и установить новую точку отсчета на следующий.

2. Обработка перезагрузки устройства: Когда телефон перезагружается, системный счетчик обнуляется. Чтобы не потерять шаги, пройденные до перезагрузки, нужно:

   • Использовать BroadcastReceiver для отслеживания события android.intent.action.BOOT_COMPLETED.

   • После перезагрузки приложение должно определить, что счетчик сбросился, и корректно "смигрировать" данные: сохранить уже посчитанные за день шаги и начать новый подсчет с нуля.

   • Перезапустить фоновую задачу на 00:00.

3. Обработка смены часового пояса: Если пользователь сменит таймзону, ваша задача на 00:00 может сработать неправильно.

   • Нужно отслеживать событие android.intent.action.TIMEZONE_CHANGED и перенастраивать WorkManager или AlarmManager в соответствии с новым временем.

Выводы: Sensor.TYPE_STEP_COUNTER — идеальный выбор для фитнес-приложений, которым важен пассивный трекинг дневной и недельной активности. Он обеспечивает максимальную точность и энергоэффективность.

Важные нюансы:

• Производители: На некоторых устройствах (особенно Huawei, Xiaomi) из-за агрессивных политик энергосбережения сенсоры могут работать некорректно в фоне без дополнительной настройки со стороны пользователя.

• Задержка: Sensor.TYPE_STEP_COUNTER может обновлять данные с небольшой задержкой (иногда до 30 секунд), так как система накапливает шаги "пачками" для оптимизации. Это не является проблемой для долгосрочного трекинга.

Часть 2. Платформы-агрегаторы: Google Fit, Samsung Health и другие

Помимо прямого считывания данных с сенсоров, существует и другой, более высокоуровневый путь — использование готовых платформ-агрегаторов. Эти сервисы берут на себя всю "грязную работу" по сбору и обработке данных, предоставляя разработчику уже готовый результат.

Google Fit API: "старый добрый" метод и его закат

Долгое время Google Fit был основным способом получить данные о шагах, не вникая в работу сенсоров.

Простота реализации: Для разработчика процесс был элементарным:

1. Убедиться, что на устройстве установлено приложение Google Fit.

2. Запросить у пользователя авторизацию через его Google-аккаунт.

3. Получить разрешение на чтение данных о шагах.

4. Запрашивать историю шагов за любой нужный интервал.

Потенциальные проблемы и их решение: Самая распространенная проблема — выбор пользователем неверного аккаунта. Например, в приложении Google Fit используется аккаунт А, а в вашем приложении пользователь по ошибке предоставляет доступ к аккаунту Б. В этом случае ваше приложение не получит никаких данных.

Практический совет: Чтобы проверить, верный ли аккаунт выбрал пользователь, можно запросить у Google Fit количество шагов за последние 7 дней. Если API возвращает значение больше нуля, значит, все в порядке. Если же приходит 0 или null, это сигнал о проблеме. Можно предложить пользователю сменить аккаунт или сообщить, что в выбранном профиле нет данных.

Закат эпохи: отключение Google Fit API (начало 2026) Эра Google Fit API подходит к концу. Google объявил о его грядущем отключении в пользу новой платформы — Health Connect. Сроки несколько раз переносились, но стратегическое решение принято. Хотя API все еще может функционировать в старых приложениях, Google прекратил рассмотрение заявок на доступ для новых партнеров и настоятельно рекомендует всем переходить на Health Connect.

Samsung Health SDK и другие платформы

• Samsung Health SDK: Когда-то это была отличная альтернатива Google Fit в пределах экосистемы Samsung. SDK предоставлял схожий простой доступ к данным. Однако, как и Google, Samsung свернул поддержку своего отдельного SDK в пользу интеграции с Health Connect.

• SDK от производителей носимых устройств (Fitbit, Garmin): Позволяют получать очень точные данные напрямую с устройств, но являются точечными решениями, сильно сужая охват аудитории.

Выводы и взгляд в будущее: Платформы вроде Google Fit и Samsung Health выполняли огромную работу: считывали данные с телефона или фирменных часов (Pixel Watch, Galaxy Watch), обрабатывали их собственными алгоритмами (в основе которых все тот же TYPE_STEP_COUNTER) и отдавали приложению готовый результат.

Однако на середину 2025 года ситуация ясна:

• Прямые интеграции уходят в прошлое. Старый Google Fit API и отдельный Samsung Health SDK больше не являются стратегическими направлениями.

• Будущее — за Health Connect. Это новый стандарт для всех. Вместо десятка разных SDK теперь есть единый инструмент.

Часть 3: RecordingAPI (Google Play Services)

После анонса о прекращении поддержки Google Fit API в качестве альтернативы был представлен RecordingAPI, являющийся частью Google Play Services. По сути, это новый способ считывания данных о шагах.

Ключевые особенности:

• Разрешение: Требуется ACTIVITY_RECOGNITION, так как "под капотом" используется тот же сенсор TYPE_STEP_COUNTER.

• Зависимость: Обязательно наличие на устройстве Google Play Services.

Принцип работы: Процесс интеграции сводится к трем шагам:

1. Получение разрешения от пользователя.

2. Подписка на получение данных о шагах.

3. Считывание данных за необходимый временной интервал.

Основное преимущество Recording API — простота. Разработчику не нужно заботиться о фоновой работе, синхронизации или обработке перезагрузок — все это SDK берет на себя. Логика, которая раньше была частью приложения Google Fit, теперь интегрирована непосредственно в Google Play Services.

Несмотря на очевидные плюсы, существует и ограничение: требование к наличию Google Play Services может исключить часть устройств (например, устройства для китайского рынка или Huawei без GMS). Тем не менее, для большинства пользователей это очень рабочее и эффективное решение.

Часть 4: Health Connect — новый единый стандарт

Health Connect, официально запущенный в октябре 2022 года, является частью экосистемы Android. Начиная с Android 14, Health Connect интегрирован в операционную систему, а для более старых версий (Android 8+) его можно установить из Google Play.

Простыми словами, Health Connect — это локальное и безопасное хранилище на вашем устройстве, куда фитнес-приложения могут записывать данные о здоровье (включая шаги), а другие приложения — считывать их с разрешения пользователя. Приложения вроде Google Fit, Samsung Health, Fitbit и другие уже являются поставщиками данных для Health Connect.

Простота и нюансы интеграции: С точки зрения разработчика, процесс выглядит просто:

1. Приложение запрашивает у пользователя разрешение на чтение и/или запись определённых типов данных (например, шагов).

2. После получения разрешения можно считывать данные за выбранный временной интервал.

Проблемы на практике: На первый взгляд всё идеально. Однако что произойдёт, если на телефоне пользователя не установлены или не настроены приложения-поставщики, такие как Google Fit или Samsung Health? Ответ очевиден: Health Connect останется пустой базой данных.

Другая проблема — частота синхронизации. Мы не можем контролировать, как часто Google Fit или Samsung Health синхронизируются со своими часами и как быстро после этого записывают данные в Health Connect.

Пользовательский опыт и "провал" Google:

Как разработчики, мы можем проверить, настроен ли Health Connect у пользователя, запросив количество шагов за последние 7 дней. Если результат больше нуля, скорее всего, всё в порядке. Если же шагов нет, это может означать, что:

• Health Connect не настроен.

• Приложения-поставщики (Google Fit, Samsung Health) настроены некорректно.

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

По моему опыту, лишь небольшая часть(15-20%) пользователей имеет правильно настроенный Health Connect. Google могла бы легко решить эту проблему, предложив настроить Google Fit или Samsung Health как источники данных по умолчанию, но этого сделано не было.

Выводы: Health Connect, без сомнения, является самым удобным и унифицированным источником для получения данных о здоровье. Однако это узкоспециализированный инструмент, о котором большинство обычных пользователей не знают. Вероятно, именно поэтому полное отключение старого Google Fit API так часто переносится — Health Connect пока не готов стать полноценной заменой для массового пользователя.

Вердикт: Оптимальный алгоритм получения шагов в 2025+ году

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

1. ? Health Connect (Приоритет №1)

   • Действие: Проверяем, есть ли данные о шагах в Health Connect за последние 7 дней.

   • Почему: Это самый современный и унифицированный источник, объединяющий данные от множества приложений и устройств. Если он настроен, это лучший вариант.

2. ? Recording API (Приоритет №2)

   • Действие: Если Health Connect недоступен или пуст, проверяем наличие и версию Google Play Services. Если они подходят, используем Recording API.

   • Почему: Это отличная и простая альтернатива, которая покрывает огромное число устройств с сервисами Google и не требует сложной логики.

3. ? Sensor.TYPE_STEP_COUNTER (Надежный запасной вариант)

   • Действие: Если ни один из вышеперечисленных методов не сработал, прибегаем к прямому считыванию данных с аппаратного датчика.

   • Почему: Этот метод работает даже без интернета и сервисов Google, но требует реализации собственной логики для сохранения и сброса данных.

Заключительное слово

В подавляющем большинстве случаев (95–99%) предложенная схема будет работать корректно. Экосистема Android всегда была фрагментированной, и Health Connect, стремясь к унификации, на данном этапе, как ни парадоксально, добавил еще один уровень сложности, переложив часть ответственности за настройку на пользователя. Наша задача как разработчиков — построить гибкую систему, которая предоставит данные, какой бы из путей ни оказался рабочим на конкретном устройстве.

Спасибо за ваше время! Надеюсь, эта статья была для вас полезной.

Полезные ссылки:
RecordingAPI
Sensor.TYPE_ACCELEROMETER
Sensor.TYPE_STEP_COUNTER
HealthConnect