Мобильное приложение — это сложнейшая инженерная система, работающая в тысячах различных сред на устройствах миллионов пользователей. Когда оно начинает «тормозить», «вылетать» или «терять данные», бизнес несёт колоссальные убытки. Но как доказать, что виноват именно код, а не «кривые руки» пользователя или «особенности платформы»? Как отделить технический сбой от умышленного саботажа? Ответ один: компьютерная экспертиза мобильных приложений, проведённая инженерами Союза «Федерация судебных экспертов». Мы не верим на слово — мы исследуем APK, IPA, логи, память, сетевой трафик и десятки гигабайт данных. В этой статье — три реальных кейса, методология low-level анализа и чёткие критерии оценки работоспособности. Пристегнитесь, будет технически насыщенно. 🛠️📱🔬

Глава 1. Мобильное приложение как объект инженерной экспертизы: многослойность и недетерминизм

Мобильное приложение — это не монолит, а многослойная структура:

Уровень 1: Пользовательский интерфейс (UI/UX) — отрисовка экранов, анимации, жесты, обработка нажатий.

Уровень 2: Бизнес-логика — алгоритмы расчётов, валидация данных, состояние приложения.

Уровень 3: Работа с данными — локальная БД (SQLite, Realm, Room), кэширование, Shared Preferences.

Уровень 4: Сетевое взаимодействие — REST API, WebSocket, push-уведомления (FCM/APNS).

Уровень 5: Интеграция с ОС — камера, GPS, NFC, биометрия, файловая система.

Уровень 6: Аппаратный уровень — CPU, GPU, RAM, аккумулятор, сенсоры.

Каждый уровень может стать источником дефекта. При этом дефект может проявляться недетерминированно (например, краш только на устройствах с 2 ГБ ОЗУ или только при слабом сигнале сотовой сети). Инженерная экспертиза должна не только найти дефект, но и определить условия его воспроизведения и причинно-следственную связь. 🧩⛓️

КЛЮЧЕВАЯ ФРАЗА №1: Компьютерная экспертиза мобильных приложений требует инженерного мышления: мы не просто констатируем «приложение падает», мы выясняем, при каких входных данных, на каком стеке вызовов, с каким состоянием памяти это происходит.

Глава 2. Классификация дефектов работоспособности: от CRASH до ANR

Для систематизации претензий мы используем следующую классификацию (основанную на стандартах ISTQB и внутренних методиках):

Каждый из этих дефектов мы умеем не только выявлять, но и локализовать до конкретного метода, класса или даже строки кода. 🎯🧵

Глава 3. Кейс №1: CRASH при скролле ленты — невидимый NPE в адаптере

📁 Ситуация: Новостной агрегатор. Пользователи жалуются, что при быстром скролле ленты приложение вылетает. Разработчик утверждает: «Не можем воспроизвести, у нас всё работает». Заказчик теряет 30% DAU (Daily Active Users). Стоимость разработки — 12 млн руб. Подан иск о возврате денег. 💥📰

Инженерное исследование:

Шаг 1: Получение логов. Заказчик предоставил логи Crashlytics за 2 недели. Стек-трейс указывал на класс NewsAdapter.java, строка 147:

FATAL EXCEPTION: main

java.lang.NullPointerException: Attempt to invoke virtual method ‘void android.widget.TextView.setText(java.lang.CharSequence)’ on a null object reference

at com.news.NewsAdapter.onBindViewHolder(NewsAdapter.java:147)

Шаг 2: Декомпиляция APK. Использовали JADX. Восстановленный код:

java

@Override

public void onBindViewHolder(ViewHolder holder, int position) {

NewsItem item = newsList.get(position);

holder.titleTextView.setText(item.getTitle()); // строка 147

holder.dateTextView.setText(item.getDate());

if (item.hasImage()) {

holder.imageView.setVisibility(View.VISIBLE);

loadImage(holder.imageView, item.getImageUrl());

} else {

holder.imageView.setVisibility(View.GONE);

}

}

На первый взгляд, всё корректно. Но почему NPE в titleTextView?

Шаг 3: Воспроизведение на тестовом стенде. Мы установили приложение на 10 различных устройств с разными версиями Android (от 8 до 13). На всех устройствах скролл работал без вылета. Это указывало на специфическое условие.

Шаг 4: Анализ логов пользователя с крашем. Запросили у заказчика логи конкретного пользователя (через ADB). Обнаружили, что краш происходит ТОЛЬКО когда:

• Приложение работает на Android 11;
• В ленте есть новости без заголовка (поле title = null в JSON);
• Пользователь скроллит быстро, до того, как изображение загрузилось.

Шаг 5: Проверка гипотезы. Вручную подменили ответ API, добавив новость с «title»: null. При скролле до этой позиции — мгновенный краш с тем же стек-трейсом. Причина: в ViewHolder titleTextView инициализировался только в конструкторе (через findViewById), но при быстром скролле и переиспользовании вьюшек иногда происходила ситуация, когда holder создавался, но titleTextView оставался null из-за ошибки в методе onCreateViewHolder (там было условное создание, которое пропускало инициализацию при определённых условиях).

Вывод: Дефект в коде адаптера — неправильная инициализация ViewHolder при переиспользовании. Разработчик не протестировал граничный случай (отсутствие заголовка). Это ошибка, связанная с нарушением принципов работы RecyclerView.

Результат: Суд признал наличие критического дефекта, разработчик выплатил 4 млн руб. компенсации и переписал адаптер с корректной обработкой null. Заказчик остался, но с потерей репутации. 🏛️💰

КЛЮЧЕВАЯ ФРАЗА №2: Компьютерная экспертиза мобильных приложений позволяет воспроизвести даже самые редкие краши, анализируя не только код, но и конкретные условия окружения пользователя.

Глава 4. Статический анализ кода: что мы ищем в байт-коде APK и IPA

Статический анализ — первый этап любой инженерной экспертизы. Мы получаем APK (Android) или IPA (iOS) и исследуем его без запуска.

Инструменты для Android:

• JADX-GUI — декомпиляция DEX в читаемый Java/Kotlin код.
• APKTool — распаковка ресурсов, манифеста, библиотек (.so).
• Bytecode Viewer — анализ непосредственно байт-кода (для верификации).
• Semgrep + custom rules — поиск уязвимостей и антипаттернов.

Инструменты для iOS:

• Hopper Disassembler — дизассемблирование бинарного кода (если нет исходников).
• Class-Dump — извлечение заголовков Objective-C.
• otool — анализ зависимостей и флагов компиляции.

Что мы ищем (по претензиям к работоспособности):

1. UI-поток (Main Thread): сетевые вызовы, чтение/запись в БД, тяжёлые вычисления. Признак — отсутствие аннотаций @MainThread или явного переключения потоков. В Kotlin это также корутины с Dispatchers.Main без withContext.
2. Null Safety: в Java — отсутствие проверок на null после вызовов API. В Kotlin — использование оператора !! (принудительный вызов) без проверки.
3. Утечки памяти: статические ссылки на Activity, незарегистрированные слушатели (EventBus, RxJava), неотменённые корутины.
4. Обработка ошибок: пустые блоки catch, отсутствие finally, нелогирование исключений.
5. Работа с БД: открытые курсоры, отсутствие транзакций при массовой вставке, миграции без проверки существования колонок.

Пример из практики: В приложении для доставки еды мы нашли в коде:

java

public void loadRestaurants() {

new Thread(() -> {

List<Restaurant> list = api.getRestaurants();

runOnUiThread(() -> {

adapter.setItems(list);

});

}).start();

}

При ошибке сети api.getRestaurants() возвращал null, адаптер падал с NPE. Разработчик не обработал null и не добавил таймаут. Дефект подтверждён. 🔥

Глава 5. Динамический анализ: профилирование, логирование и воспроизведение

Статика не даёт полной картины. Динамический анализ — запуск приложения в контролируемой среде с инструментацией.

Инструменты Android:

• Android Studio Profiler (CPU, Memory, Network, Energy)
• Logcat (системные логи)
• Systrace/Perfetto (анализ производительности системы)
• LeakCanary (обнаружение утечек памяти — в отладочной сборке)

Инструменты iOS:

• Xcode Instruments (Time Profiler, Leaks, Allocations, Network)
• Console.app (логи системы)
• MetricKit (сбор метрик производительности на реальных устройствах)

Процедура воспроизведения:

1. Получаем точные характеристики устройства заказчика: модель, версия ОС, объём ОЗУ, процент заполнения диска, установленные приложения.
2. Настраиваем эмулятор или реальное устройство с такими же параметрами.
3. Устанавливаем ту же версию приложения (APK/IPA).
4. Выполняем сценарий, описанный заказчиком (видео, скриншоты).
5. Фиксируем результат: краш, ANR, зависание, неверные данные.
6. Сохраняем логи, дампы памяти, профили.

Документирование: обязательно видео воспроизведения с экрана устройства + запись экрана компьютера с открытыми логами. Это доказательство, которое невозможно оспорить. 🎥📝

КЛЮЧЕВАЯ ФРАЗА №3: Компьютерная экспертиза мобильных приложений всегда включает динамический анализ — только в рантайме проявляются дефекты, связанные с гонками потоков, утечками памяти и нехваткой ресурсов.

Глава 6. Сетевой анализ: как мы ловим ошибки API и неэффективные запросы

Большинство мобильных приложений — это «тонкий клиент» к серверу. И претензии «не работает» часто связаны с тем, что сервер возвращает не то, что ожидает клиент. Для анализа мы используем:

Прокси-серверы:

• Burp Suite (с установкой своего CA-сертификата)
• Charles Proxy (удобный для мобильных, поддержка iOS/Android)
• Proxyman (для macOS, нативная интеграция)

Что анализируем:

• HTTP-статусы: 500 (Internal Server Error), 502 (Bad Gateway), 404, 403.
• Время ответа: Time To First Byte (TTFB) более 3 секунд — проблема на сервере.
• Структуру JSON: несоответствие схеме, отсутствие обязательных полей, неверные типы (строка вместо числа).
• Кэширование: отсутствие заголовков Cache-Control, приводящее к повторной загрузке одних и тех же данных.
• Многопоточность: последовательные запросы вместо параллельных (умножают время загрузки).
• Повторные попытки: отсутствие retry-политики при временных сбоях.

Кейс из практики: Приложение для онлайн-кинотеатра жаловалось на долгую загрузку списка фильмов (до 20 секунд). Анализ показал, что приложение делало 3 последовательных запроса: /get_user_profile, /get_genres, /get_movies. Каждый ждал ответа предыдущего. Поменяли на параллельные — время сократилось до 4 секунд. Дефект архитектуры. 🐢➡️🐇

Глава 7. Кейс №2: АНАЛИЗ ANR — когда главный поток засыпает навсегда

📁 Ситуация: Банковское приложение. Пользователи жалуются: при попытке открыть историю операций приложение зависает на 10-15 секунд, затем появляется диалог «Приложение не отвечает». Разработчик говорит: «Проблема в медленной работе сервера». Но заказчик проверил сервер — отвечает за 200 мс. Возник спор на 8 млн рублей. 🏦💢

Наше исследование:

Шаг 1: Анализ логов ANR. На устройстве Android в папке /data/anr/ (требуется root или adb-доступ) сохраняются файлы trace.txt. Мы получили такой файл. В нём:

text

—— pid 12345 at 2025-03-15 14:23:17 ——

Cmd line: com.bank.app

DALVIK THREADS (mutexes: tll=0 tsl=0 tscl=0 ghl=0 hwl=0 hwll=0)

«main» prio=5 tid=1 Waiting

| group=»main» sCount=1 dsCount=0 flags=1 obj=0x72c00000 self=0xb4000071

| sysTid=12345 nice=0 cgrp=default sched=0/0 handle=0x7b8a4a80

| state=S schedstat=( 0 0 0 ) utm=0 stm=0 core=0 HZ=100

| stack=0x7fd8c00000-0x7fd8c02000 stackSize=8192KB

| held mutexes=

at java.lang.Object.wait(Native method)

— waiting on <0x0b258920> (a java.lang.Object)

at java.lang.Thread.parkFor(Thread.java:2137)

at sun.misc.Unsafe.park(Native method)

at java.util.concurrent.locks.LockSupport.park(LockSupport.java:211)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:869)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1003)

at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1329)

at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:232)

at com.bank.data.TransactionRepository.loadHistory(TransactionRepository.java:89)

— locked <0x0b258920> (a java.util.concurrent.CountDownLatch)

at com.bank.ui.HistoryFragment.onCreateView(HistoryFragment.java:45)

Шаг 2: Декомпиляция кода. Смотрим TransactionRepository.java:

java

public List<Transaction> loadHistory() {

CountDownLatch latch = new CountDownLatch(1);

List<Transaction> result = new ArrayList<>();

api.getHistory(new Callback() {

@Override

public void onSuccess(List<Transaction> data) {

result.addAll(data);

latch.countDown();

}

@Override

public void onError(Throwable t) {

latch.countDown(); // ОШИБКА: нет записи в result, но latch срабатывает

}

});

try {

latch.await(5, TimeUnit.SECONDS);

} catch (InterruptedException e) {

// пустой catch

}

return result;

}

Шаг 3: Анализ условия. Проблема: если API возвращает ошибку (например, 500), то onError вызывает countDown(), но result остаётся пустым. В этом случае метод возвращает пустой список. Но в UI-потоке (HistoryFragment) вызывается loadHistory() СИНХРОННО, на MAIN THREAD. При этом внутри loadHistory используется latch.await(), который блокирует MAIN THREAD до получения ответа. Если сервер долго отвечает или не отвечает вовсе (таймаут), то MAIN THREAD блокируется на 5 секунд, вызывая ANR. Это грубейшее нарушение: нельзя делать сетевые вызовы синхронно на UI-потоке.

Вывод: Дефект архитектуры — использование CountDownLatch на главном потоке. Разработчик не использовал асинхронные колбэки или корутины. Сервер тут ни при чём.

Результат: Суд признал приложение не соответствующим стандартам качества Android (Google требует, чтобы сетевые вызовы были асинхронными). Разработчик вернул 3 млн руб. за переработку модуля. ✅

КЛЮЧЕВАЯ ФРАЗА №4: Компьютерная экспертиза мобильных приложений выявляет даже такие тонкие дефекты, как блокировка UI-потока через CountDownLatch — то, что стандартное тестирование часто пропускает.

Глава 8. SQLite, ROOM и REALM: анализ дефектов локальных баз данных

Мобильные приложения активно используют локальные БД. Типичные претензии:

• «После обновления пропали данные»
• «Приложение тормозит при открытии списка из 5000 записей»
• «Приложение крашится при запуске — ошибка БД»

Методика анализа:

1. Извлечение файла БД (обычно /data/data/com.app/databases/ — требует root для Android или резервной копии для iOS).
2. Анализ схемы через SQLite Browser или командную строку: проверка индексов, внешних ключей, типов данных.
3. Проверка целостности: PRAGMA integrity_check;
4. Анализ миграций: сравнение кода миграции с реальной схемой БД на устройстве пользователя.
5. Профилирование запросов: EXPLAIN QUERY PLAN — поиск полных сканирований таблиц (full table scan).

Кейс из практики: Приложение для заметок. После обновления пользователи потеряли все заметки старше 2 месяцев. Наша экспертиза показала: в новой версии добавили поле is_archived, но в миграции забыли установить DEFAULT 0. В SQLite старые записи получили NULL, а код приложения фильтровал WHERE is_archived = 0. Заметки не были удалены, просто не отображались. Мы написали скрипт для исправления и спасли репутацию разработчика. 🛟💾

Глава 9. Анализ энергопотребления и батареи: когда приложение «жрёт» заряд

Претензия «Приложение быстро разряжает батарею» — одна из самых сложных для экспертизы, потому что зависит от модели устройства, состояния аккумулятора и поведения пользователя.

Инструменты:

• Android: Battery Historian (Google), dumpsys batterystats.
• iOS: Energy Log (Xcode Instruments), sysdiagnose.

Что мы измеряем:

• WakeLocks: приложение не даёт устройству перейти в спящий режим.
• Сетевую активность: частые запросы (polling каждые 5 секунд).
• GPS: постоянное обновление местоположения в фоне.
• CPU: высокую загрузку из-за бесконечных циклов или тяжёлых вычислений.
• AlarmManager/WorkManager: частые пробуждения.

Кейс: Приложение такси жаловалось на разряд батареи за 3 часа. Battery Historian показал, что приложение отправляло геопозицию каждые 500 мс, даже когда машина стояла на месте. Исправили на 30 секунд в движении и 5 минут в покое — батарея стала держаться день. ⚡🔋

Глава 10. Кейс №3: ПРОБЛЕМЫ ПУШ-УВЕДОМЛЕНИЙ — FCM/APNS и их капризы

📁 Ситуация: Ритейлер инвестировал 2 млн руб. в разработку приложения с push-уведомлениями для акций. После запуска выяснилось, что 60% пользователей не получают уведомления. Разработчик заявил: «Это проблемы гугла/эппл, мы не виноваты». Заказчик потребовал вернуть деньги. 📲📣

Наше исследование:

Шаг 1: Проверка токенов. Через серверную часть приложения мы получили список зарегистрированных FCM-токенов. Оказалось, что токены не обновляются после переустановки приложения — старые токены продолжали висеть в базе.

Шаг 2: Анализ кода регистрации. Декомпилировали APK, нашли:

java

FirebaseMessaging.getInstance().getToken().addOnCompleteListener(task -> {

if (task.isSuccessful()) {

String token = task.getResult();

sendTokenToServer(token);

}

});

Проблема: метод getToken() возвращает кэшированный токен, который может быть невалидным после переустановки. Надо использовать FirebaseMessaging.getInstance().deleteToken() перед повторной регистрацией. Этого не было.

Шаг 3: Анализ серверной логики. Сервер отправлял уведомления через FCM, но не обрабатывал ошибки: если FCM возвращал NotRegistered, сервер не удалял токен. Со временем база токенов превратилась в кладбище невалидных записей.

Шаг 4: Воспроизведение. Установили приложение, получили токен T1. Удалили приложение, установили заново — получили тот же токен T1 (кэш). Но на стороне FCM этот токен уже недействителен. Уведомления не доходили.

Вывод: Ошибка и в клиентской части (необновление токена), и в серверной (отсутствие обработки NotRegistered). Разработчик не следовал рекомендациям Google.

Результат: Суд обязал разработчика вернуть 50% стоимости (1 млн руб.) и исправить логику за свой счёт. Заказчик остался недоволен, но получил работающие уведомления. 🤝

КЛЮЧЕВАЯ ФРАЗА №5: Компьютерная экспертиза мобильных приложений в части push-уведомлений требует проверки как клиентского кода регистрации токенов, так и серверной логики их обработки — только комплексный анализ выявляет истинную причину.

Глава 11. Инструментальный парк инженерной лаборатории: от ADB до JTAG

Для глубокого анализа мы используем не только программные, но и аппаратные инструменты:

Аппаратные:

• JTAG-адаптеры для прямого чтения памяти устройства (при физическом доступе).
• USB-анализаторы (Total Phase Beagle) для перехвата USB-трафика.
• Специализированные смартфоны с root-доступом (Google Pixel, Xiaomi с разблокированным загрузчиком).

Программные:

• ADB (Android Debug Bridge) — получение логов, дампов, установка приложений.
• Frida — динамическая инструментация (внедрение JS-скриптов в рантайм).
• Objection — обход SSL pinning, дамп памяти.
• MobSF (Mobile Security Framework) — автоматизированный статический анализ.
• Ghidra — дизассемблирование нативных библиотек (.so).

Облачные сервисы:

• Firebase Test Lab — тестирование на сотнях реальных устройств.
• AWS Device Farm — аналогично.
• BrowserStack App Automate — для iOS/Android.

Мы не привязаны к одному инструменту. Каждая экспертиза — это подбор оптимального набора. 🧰🛠️

Глава 12. Процессуальные нюансы: как подготовить материалы для назначения экспертизы

Чтобы суд назначил независимую компьютерную экспертизу мобильного приложения, нужно предоставить:

1. APK/IPA-файл той версии, на которую есть претензия. Если приложение обновлялось — требуется архивная версия (можно найти в apkmirror или через запрос к разработчику).
2. Видеозапись воспроизведения дефекта на устройстве заказчика. Желательно с экрана (запись через другой телефон или встроенными средствами Android 11+).
3. Логи (Logcat для Android, Console.app для iOS). Если нет технической возможности — хотя бы скриншоты ошибки.
4. Исходный код (желательно) или хотя бы доступ к репозиторию. Без кода статический анализ невозможен, но можно обойтись динамическим.
5. Переписку с разработчиком, где он признаёт или отрицает проблему. Это важно для оценки добросовестности.

Формулировка вопросов эксперту (пример):

• Имеются ли в мобильном приложении «ABC» (версия 2.1.0, Android) дефекты, приводящие к его неработоспособности в части функции «отображение истории операций»?
• Если да, то какова причина каждого дефекта (ошибка в коде, несоответствие API, сбой ОС)?
• Возможно ли устранение дефектов без переработки архитектуры приложения?
• Требуется ли для устранения дефектов изменение серверной части или достаточно обновления клиента?

Грамотно поставленный вопрос — 50% успеха. 🎯📋

Глава 13. Типичные ошибки заказчиков при подготовке к экспертизе

Мы видим эти ошибки постоянно. Избегайте их:

❌ Ошибка 1: «У меня всё сломалось, вот телефон, разбирайтесь». Без логов, без видео, без APK. Эксперт не экстрасенс. Предоставьте максимум данных.

❌ Ошибка 2: «Я обновил приложение до последней версии, теперь баг пропал, но деньги верните». Если баг исчез в новой версии — это хорошо для пользователя, но плохо для доказательств. Нужно сохранить старую версию (APK) до обновления.

❌ Ошибка 3: «Дайте заключение, что приложение плохое, а мы уже сами придумаем причину». Экспертиза — это установление причинно-следственной связи. Мы не пишем «плохое», мы пишем «имеет дефект X, выраженный в Y, приводящий к Z».

❌ Ошибка 4: Обращение к эксперту за неделю до суда. Глубокое исследование мобильного приложения занимает от 2 до 6 недель. Не откладывайте.

❌ Ошибка 5: Скрытие факта, что приложение работало на кастомной прошивке или рутированном устройстве. Это может изменить поведение. Эксперт должен знать все условия. 🤥

Глава 14. Почему мы — Союз «Федерация судебных экспертов» — лидеры в этой области

У нас есть то, чего нет у 90% конкурентов:

🔹 Инженерный состав. Наши эксперты — бывшие разработчики мобильных приложений с опытом 7+ лет (Android, iOS, Flutter, React Native). Они знают, где обычно прячутся баги.

🔹 Лабораторная база. Более 50 реальных устройств (Samsung, Pixel, iPhone, Xiaomi) со всеми версиями ОС от Android 8 до 14, iOS 13 до 17.

🔹 Методология. Собственная методика «Мобильная форензика и анализ качества», зарегистрированная в РФЦСЭ (рег. № 2024-07-15).

🔹 Судебный опыт. Более 80 экспертиз мобильных приложений, 92% положительных для заказчика исходов. Ни одного отменённого заключения.

🔹 Независимость. Мы не работаем на «заказ» в смысле подгонки выводов. Мы работаем на истину. Если приложение качественное — мы это докажем. Если нет — тоже докажем.

КЛЮЧЕВАЯ ФРАЗА (ДЛЯ ЗАКРЕПЛЕНИЯ): Компьютерная экспертиза мобильных приложений от Союза «Федерация судебных экспертов» — это сочетание глубоких инженерных знаний и процессуальной безупречности. Мы не успокоимся, пока не докопаемся до истины.

Глава 15. Руководство к действию: что делать при первых признаках неработоспособности

Если вы столкнулись с проблемами в мобильном приложении и готовитесь к суду или досудебной претензии:

ШАГ 1. НЕ ОБНОВЛЯЙТЕ ПРИЛОЖЕНИЕ. Сохраните текущую версию (APK/IPA). Если не умеете — отключите автоматические обновления в Google Play/App Store.

ШАГ 2. ЗАФИКСИРУЙТЕ ОШИБКУ НА ВИДЕО. Вторым телефоном снимите экран, покажите действия и результат. Желательно с часами/таймером рядом.

ШАГ 3. СОХРАНИТЕ ЛОГИ. Для Android: установите ADB, выполните adb logcat -d > crash.log. Для iOS: подключите к Mac, в Xcode -> Devices -> выберите устройство -> Open Console.

ШАГ 4. ПЕРЕХВАТИТЕ ТРАФИК. Установите Charles Proxy, настройте телефон как прокси, выполните сценарий, сохраните.har-файл.

ШАГ 5. ОБРАТИТЕСЬ К НАМ. Даже для предварительной оценки. Мы скажем, стоит ли заказывать полноценную экспертизу, или проблема на вашей стороне (например, устаревшее устройство). 📞💬

ШАГ 6. ПОДГОТОВЬТЕ ХОДАТАЙСТВО В СУД. Мы поможем с формулировкой вопросов. Не доверяйте это «своим» юристам, которые не понимают разницы между ANR и CRASH.

ШАГ 7. НЕ ДАВИТЕ НА ЭКСПЕРТА. Мы работаем по методике, а не по указке. Если вы попытаетесь повлиять на выводы — мы откажемся от экспертизы и вернём деньги (кроме фактических затрат). Это прописано в договоре. ✋⛔

Финальный аккорд: истина в коде, а не в эмоциях

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

Союз «Федерация судебных экспертов» готов принять ваш вызов. Дайте нам APK, логи и описание проблемы — мы разберём его до уровня инструкций процессора. Дайте нам доступ к серверу — мы покажем, где разработчик срезал угол. Дайте нам честный вопрос — мы дадим честный ответ. Даже если этот ответ не в вашу пользу. Потому что наша независимость дороже гонорара. ⚖️🧠💎

Переходите на наш сайт: https://krimexpert.ru/ekspertiza-kachestva-razrabotki-mobilnyh-prilozhenij/ — там вы найдёте не только услуги, но и технические статьи, чек-листы для заказчиков и контакты ведущих экспертов.

Союз «Федерация судебных экспертов»
Лаборатория инженерной экспертизы мобильных приложений
Доказываем. Научно. Инженерно. Честно.

P.S. Каждый баг, который мы находим, — это маленькая победа здравого смысла над небрежностью. И мы любим побеждать. 🏆🐞