- Как снять дамп разделов system, kernel, data, zImage на Андроид
- Необходимо для снятия образа
- Подробно о Root Android:
- Инструкция как снять образ с Андроид
- Узнаем /dev/block разделов
- [Обновление]
- Снятие образа Android с выбранного раздела
- [Обновление]
- Восстановление раздела из созданного образа Android (дампа раздела)
- [Обновление]
- Анализ памяти для Android приложений
- Инструменты
- Пример: Отладка утечки памяти
- Исследование кучи с помощью DDMS
- Создание дампа кучи
- Анализ дампа кучи при помощи MAT
- Сравнение дампов кучи с помощью MAT
- Как сделать nandroid backup устройства непосредственно на компьютер, минуя sdcard
- Общая информация
- Требования
- Разделы в устройстве
- Резервное копирование всей памяти (посредством adb)
- Резервное копирование всей памяти (через WiFi)
- Резервное копирование всей памяти (через USB-модем или Wi-Fi-модем)
- Резервное копирование одного Раздела (raw = точная побитовая копия раздела)
- Резервное копирование одного Раздела (tar = копируются только файлы и папки)
Как снять дамп разделов system, kernel, data, zImage на Андроид
вкл. 30 Март 2015 . Опубликовано в Android — Общее
Как снять дамп разделов system, kernel, data, zImage на Андроид. Многие начинающие ромоделы Android или гики не знают как снять образ с Android. В данной статье подробно рассказано как узнать нужные вам /dev/block , как снять дампы с них, разобрать их или в последствие восстановиться.
Для тех кто не много не понял о чем речь. В данной статье будет подробно рассказано как снять текущее состояние с разделов Android — system, data, efs, preload, cache или выдрать ядро (zImage / boot.img). С какой целью расписываться здесь не будет , так как это уже другая история.
Необходимо для снятия образа
1. Скачайте и установите на ПК фирменную программу сайта ADB RUN (если в курсе, что такое adb или установлено Android SDK, то устанавливать не нужно)
2. Android смартфон или планшет должен быть c Root правами
Подробно о Root Android:
4. Установить драйвера если вдруг не установлены
5. MicroUSB кабель
Инструкция как снять образ с Андроид
1. Подключите устройство Android к ПК
2. Запустите программу ADB RUN и перейдите в меню (7) Manual Command > (1) Adb
Узнаем /dev/block разделов
Что такое /dev/block/? /dev/block/ — это «диски» на которых находятся разделы system, data, cache
Вариант 1
Данный способ самый простой, но к сожалению узнать где находиться ядро не возможно.
Для того чтобы узнать /dev/block/ вводим команду
Получаем список где видим список с нашими разделами и к каким /dev/block/ они примонтированы
Вариант 2
Данный способ более сложный, но за то вы точно будете знать абсолютно все ваши разделы!
Вначале лучше воспользоваться файловым менеджером Android с Root доступом например как:
После того как установили перейдите по пути
Далее вам нужно найти папку by-name, она находиться в одной из под папок в platform
Например для некоторых устройств Samsung это выглядит так:
Для устройств на Tegra 3:
Для устройств на Omap:
Для некоторых Mediatek:
Для некоторых устройств Sony:
После того как выяснили где находиться папка by-name в программу ADB RUN набираем команду
где xxxxxxxx — точный путь до папки by-name
[Обновление]
В новых версиях программы ADB RUN (с версии 3.4x.xx) узнать все разделы стало гораздо проще! Все что вам необходимо это:
- запустить ADB RUN
- Перейти в раздел Memory and Partitions -> Partitions /dev/block/
- Попробовать один из методов узнать ваши блоки
Снятие образа Android с выбранного раздела
И так когда мы уже знаем где находятся какие разделы, можно приступать к снятию образа Android (дампа) с выбранного раздела. Перед тем как начать убедитесь что у вас достаточно много свободной памяти на карте памяти!
1. Для того чтобы снять образ необходимо в ADB RUN зайти в меню (7) Manual Command > (1) Adb
2. Залогиниться в терминале под Root -ом
3. Набрать команду для снятия дампа
где XXXXXXXXX — раздел с которого вы снимаете
где NAME_razdel.img — имя которое вы присвоите при снятие образа с выборного раздела (давать имена лучше также как они указаны, если data то data)
Процедура снятия может занять определенное время, от 1 минуты до 15, в это время лучше не дергать ваш Android!
[Обновление]
В новых версиях ADB RUN появилась возможность быстро снять образ каждый раз не набирая столь длинные команды. Все что вам нужно это знать имя блока.
Когда вы уже знаете необходимый блок перейдите в ADB RUN:
- С главного меню в раздел Backup -> Backup dev/block
- Выбираем Backup
- Указываем последние данные с блока (данные после block/)
- Ждем пока снимется образ (не трогать Android)
Восстановление раздела из созданного образа Android (дампа раздела)
Когда вам будет необходимо выполнить восстановление из ранее созданного образа, нужно сделать вот, что:
Убедитесь что образ все еще находиться в разделе /sdcard — так как бекап создавался именно в этот раздел, либо переместите его обратно.
Прописать следующую команду:
где XXXXXXXXX — раздел на которой вы заливаете образ
где NAME_razdel.img — имя образа выборного раздела (давать имена лучше также как они указаны, если data то data)
Процедура восстановления может занять определенное время, от 1 минуты до 15, в это время лучше не дергать ваш Android!
[Обновление]
Для устройств Sony, HTC, Xiaomi и других устройств на которых есть режим Fastboot
могут выполнить восстановление следующим образом после ранее обязательного снятия boot.img (zImage) и system.img (factoryfs.img) обязательно скопируйте данные файлы на ПК:
1. Переведите Android в режим fastboot (bootloader) и подключить к ПК
2. Файлы boot.img и system.img переместить в папку C:/adb/progbin
3. Запустить ADB RUN и перейти в пункт Manual -> ADB
4. Набрать следующие команды (подробно о Fastboot)
Система будет восстановлена в исходное состояние! Можете продолжать эксперименты!
Источник
Анализ памяти для Android приложений
В Dalvik есть сборщик мусора, но это не значит, что можно игнорировать управление памятью. Даже наоборот — нужно быть особенно внимательным при использовании памяти, которая, как известно, на мобильных устройствах ограничена. В этой статье будут рассмотрены инструменты, которые значительно помогают следить за тем, как приложение использует память.
Некоторые проблемы от чрезмерного использования памяти вполне очевидны. Например, в вашем приложении постоянно происходит утечка памяти, когда пользователь прикасается к экрану, тогда это в конечном итоге, возможно, вызовет OutOfMemoryError, и произойдет сбой и закрытие приложения. Другие проблемы, более тонкие, чем эта могут приводить к общему спаду производительности приложения и системы в целом (потому что сборщик мусора будет вызываться более часто и на более продолжительное время).
Инструменты
Android SDK обеспечивает два основных устройства для профилирования использования памяти приложением: вкладка Allocation Tracker в DDMS и дампы кучи (heap dumps). Allocation Tracker может быть полезен в том случае, когда вы хотите узнать об использовании памяти в конкретный период времени, так как он не дает информации о полном состояния кучи, которая выделяется под приложение. За более подробной информацией об Allocation Tracker можно обратиться к статье Tracking Memory Allocations. Остальная часть этой статьи будет посвящена исследования дампов кучи, так как это более мощный инструмент.
Дамп кучи — это снимок состояния всей кучи приложения, который хранится в бинарном файле, формата HPROF. Dalvik использует формат, который похож на тот, который используется инструментом HPROF в Java, но не является точно таким же.
Есть несколько способов создать дамп кучи выполняющегося Android приложения. Первый — использовать кнопку Dump HPROF file в DDMS. Если вам нужно выбрать момент создания дампа более точно, то можно создать его программно, при помощи метода android.os.Debug.dumpHprofData().
Для анализа можно использовать стандартный инструмент jhat или Eclipse Memory Analyzer (MAT). Однако, сначала нужно конвертировать .hprof файл из Dalvik формата в J2SE HPROF формат. Для этого используется утилита hprof-conv, которая поставляется с Android SDK:
Пример: Отладка утечки памяти
В Dalvik программист не размещает что-либо явно в свободную память, поэтому могут возникать утечки, как в языках C и C++. Под «утечкой памяти» обычно понимают ситуацию, при которой вы продолжаете ссылаться на объект, который больше не нужен. Иногда, одна единственная ссылка может предотвратить вызов сборщика мусора для удаления большого набора объектов.
Давайте рассмотрим приложение Honeycomb Gallery sample app из Android SDK. Это простая фотогалерея, которая демонстрирует использование неких методов нового API в Honeycomb. Сейчас мы преднамеренно создадим утечку памяти, чтобы затем продемонстрировать метод отладки.
Представим себе, что мы хотим, чтобы приложение получало изображения по сети. Чтобы сделать его более отзывчивым к пользователю, возможно, стоит реализовать кэш для хранения недавно просмотренных изображений. Мы можем это сделать, внеся некоторые изменения в ContentFragment.java. В начале класса объявим и инициализируем новую переменную:
В этом отображении мы будем кэшировать загруженные Bitmap’ы. Теперь можно изменить метод updateContentAndRecycleBitmap() для проверки кэша перед загрузкой и добавления Bitmap’ов в кэш после загрузки:
Здесь я преднамеренно создал утечку памяти: Bitmap’ы добавляются в кэш, но не удаляются из него. В реальном приложении очевидно, что размер кэша нужно ограничивать.
Исследование кучи с помощью DDMS
Dalvik Debug Monitor Server (DDMS) — это один из главных инструментов для отладки в Android. Он является частью плагина ADT к среде разработки Eclipse, его также можно найти в папке tools/ вашего Android SDK. Для более подробной информации можно прочесть Using DDMS.
Давайте используем DDMS для анализа использования кучи нашим приложением. Вы можете запустить DDMS двумя способами:
- Из Eclipse: Window -> Open Perspective -> Other… > DDMS
- Из командной строки: запустите ddms (или ./ddms на Mac/Linux) в папке tools/
Выберите процесс com.example.android.hcgallery в левой панели и кликните на кнопку Show heap updates на панели инструментов. Затем переключитесь на вкладку VM Heap в DDMS. Вы увидите некоторую базовую информацию об использовании кучи, которая будет обновляться при каждом вызове сборщика мусора. Чтобы увидеть первое обновление, кликните на кнопку Cause GC.
Можно заметить, что «живые» объекты занимают в памяти чуть меньше 8Мб (см. на колонку Allocated ). Теперь пролистаем фотографии, и можно будет увидеть, как это число увеличивается. Так как в приложении всего 13 фотографий, то утечка памяти ограничена. В некотором смысле, это наихудший случай, который может получиться, поэтому здесь никогда не будет OutOfMemoryError.
Создание дампа кучи
Кликните по кнопке Dump HPROF file в панели инструментов DDMS, выберите место сохранения файла, и сконвертируйте его, используя утилиту hprof-conv. В этом примере, мы будем использовать отдельную версию MAT (1.0.1), её можно скачать здесь.
Если вы используете Eclipse, с установленным MAT, то после нажатия на кнопку «dump HPROF», файл автоматически конвертируется и откроется в окне Ecilpse.
Анализ дампа кучи при помощи MAT
Запустите MAT и загрузите HPROF-файл, который был только что создан. MAT — мощная утилита, и разъяснение всех её особенностей вне этого топика, поэтому я объясню только один из методов как можно определить утечку — при помощи вида «Гистограмма» (Histogram view). В этом виде можно увидеть список классов, отсортированных по числу экземпляров, shallow heap (общий размер памяти, занимаемый экземплярами), или retained heap (общая память, занимаемая экземплярами и объектами, на которые они ссылаются).
Если отсортировать по shallow heap, то можно увидеть, что вверху окажется число экземпляров byte[]. В Android 3.0 Bitmap’ы представляются в виде массивов из байтов, размер которых зависит от размера Bitmap’a. То есть понятно, что они представляют память, которая занимается нашими Bitmap’ами. Щелкните правой кнопкой на классе byte[] и выберите List Objects > with incoming references. Вы увидите список всех массивов из байтов, размещенных в куче.
Выберите один из больших объектов и раскройте его. В итоге вы увидите всю цепочку ссылок, которая образуется из-за этого объекта. Вот он — наш кэш для Bitmap’ов!
MAT не может дать точную информацию является ли это утечкой, так как он не знает, нужны ли эти объекты. Ответ знает только программист. В нашем случае, кэш очень большой, сравнительно со всем приложением, поэтому логично было бы ограничить его размер.
Сравнение дампов кучи с помощью MAT
При отладке утечек памяти, бывает полезно сравнить состояние кучи в разные моменты времени. Чтобы сделать это, создайте два HPROF файла (не забывайте их конвертировать утилитой hprof-conv).
Вот как вы можете сравнить эти два файла:
- Откройте первый файл (File > Open Heap Dump).
- Откройте гистограммный вид.
- В виде истории навигации (Window > Navigation History), щелкните правой кнопкой на histogram и выберите Add to Compare Basket.
- Откройте второй файл и повторите шаги 2 и 3.
- Переключитесь в вид Compare Basket, и кликните Compare the Results (красная иконка восклицательного знака в правом верхнем углу)
Источник
Как сделать nandroid backup устройства непосредственно на компьютер, минуя sdcard
Так случилось, что мне понадобилось создать полную копию Android устройства, в котором полностью отсутствовали обычно используемые для этого средства. Поиски меня привели на форум XDA, где и была найдена данная всеобъемлющая инструкция, которая пришлась как нельзя кстати и которой я решил поделиться с вами.
В статье имеются мои комментарии, так как применял эту инструкцию для создания backup’a планшета Teclast x98 3g.
Общая информация
Это руководство предназначено для помощи в создании полной резервной копии вашего устройства (вся память со всеми разделами) или одного раздела (в том числе sdcards и т.д.) непосредственно на компьютер:
- На уровне Блоков памяти (с помощью команды dd): для отдельных разделов или полностью всей памяти (все разделы). Резервная копия всегда будет иметь тот же размер, который имеет сохраняемый раздел.
- На уровне Файлов (с помощью команды tar): только для отдельных разделов. Копия будет содержать только файлы и папки, которые имеются на устройстве, таким образом занимая гораздо меньше места, в зависимости от того, на сколько заполненным будет раздел.
Данная инструкция применима, когда аппарат включен или находится в ClockworkMod Recovery (в данных случаях ADB будет работать, в режиме Fastboot данная инструкция не применима). Если дополнительно не будет никаких ремарок, все команды предназначены для использования в Windows. То же касается и Linux с Unix.
Требования
- Рутированное Android устройство;
- Установленный Busybox на устройстве;
- Если вы используете Linux / OS X, у вас уже имеются необходимые инструменты, для Windows скачайте Cygwin и установите вместе с ним netcat, pv и util-linux, выбрав их во время установки (от себя добавлю, что лучше пользоваться терминалом из Cygwin mintty.exe, чем родным для Windows cmd.exe, так как скорость копирования у первого доходила до 3-4 МБ\с, а у cmd.exe — максимум 400 кб\с);
- Установленный ADB;
- Убедитесь, что adb.exe находится в переменной PATH. Посмотрите здесь и здесь, или воспользуйтесь Path Manager;
- Включенный режим отладки по USB на устройстве и соответствующие драйверы, установленные в Windows. Ввод «adb devices» в терминале должен показать ваше устройство.
Разделы в устройстве
Теперь вам необходимо определить разделы и блоки на вашем устройстве, копию которых вы хотите сделать. Для копирования одного раздела можно использовать команды tar или dd, в то время как для копирования всей памяти нужно использовать только dd.
На Teclast x98 3g для определения разделов используются две команды: cat proc/partitions и mount.
127|root@android:/ # mount
mount
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/secure tmpfs rw,relatime,mode=700 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
[b]/dev/block/mmcblk0p9 /system ext4 ro,noatime,data=ordered 0 0
/dev/block/mmcblk0p7 /cache ext4 rw,nosuid,nodev,noatime,data=ordered 0 0
/dev/block/mmcblk0p6 /config ext4 rw,nosuid,nodev,noatime,data=ordered 0 0
/dev/block/mmcblk0p10 /data ext4 rw,nosuid,nodev,noatime,noauto_da_alloc,data=ordered 0 0
/dev/block/mmcblk0p8 /logs ext4 rw,nosuid,nodev,relatime,data=ordered 0 0[/b]
none /sys/kernel/debug debugfs rw,relatime 0 0
/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0
none /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0
tmpfs /mnt/libreg tmpfs rw,noexec,noatime,size=4k,mode=700,gid=1003 0 0
/dev/block/vold/179:1 /storage/sdcard_ext fuseblk rw,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0
root@android:/ # cat proc/partitions
cat proc/partitions
major minor #blocks name
179 10 30535680 mmcblk0
179 11 229376 mmcblk0p1
179 12 32768 mmcblk0p2
179 13 32768 mmcblk0p3
179 14 131072 mmcblk0p4
179 15 131072 mmcblk0p5
179 16 131072 mmcblk0p6
179 17 786432 mmcblk0p7
179 18 262144 mmcblk0p8
179 19 1048576 mmcblk0p9
259 0 27742188 mmcblk0p10
179 30 2048 mmcblk0boot1
179 20 2048 mmcblk0boot0
179 0 30657536 mmcblk1
179 1 30657504 mmcblk1p1
Обычно на Android весь блок, содержащий все разделы, расположен в /dev/block/mmcblk0, а все остальные разделы являются его подразделами. Вы можете установить parted with GPT support, чтобы просмотреть информацию о всех разделах.
Вся память телефона -> /dev/block/mmcblk0 (хотя, на некоторых телефонах, это может быть и sdcard).
Разделы -> все зависит от конкретного устройства. Обычно в /dev/block/platform/dw_mmc/by-name/ перечислены все разделы для данного устройства.
Резервное копирование всей памяти (посредством adb)
Подключите телефон с включенным режимом отладки по USB к компьютеру.
Что касается Teclast x98 3g и того случая, когда аппарат не загружается (bootloop). Очень важно, чтобы до всего этого случившегося был включен режим отладки по USB. Выключите полностью планшет, отсоедините все кабели, дайте пару секунд на «отдых» и подключите кабель от компьютера к планшету, должна появиться такая большая белая батарея, которая будет показывать, что идет процесс зарядки, вот только тогда, даже в выключенном состоянии можно будет работать с аппаратом через терминал и adb.
Запустите Cygwin Терминал и введите (при необходимости замените mmcblk0):
adb forward tcp:5555 tcp:5555
adb shell
su
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox dd if=/dev/block/mmcblk0
Вы увидите мигающий курсор на следующей строке слева. На данный момент аппарат ожидает передачи Блока по сети.
Откройте другой Cygwin Терминал и введите:
adb forward tcp:5555 tcp:5555
cd /path/to/store/the/backup
nc 127.0.0.1 5555 | pv -i 0.5 > mmcblk0.raw
Вы увидите, как начнет увеличиваться размер файла до тех пор, пока полностью не скопируется весь выбранный вами Блок. Теперь у вас имеется полный бекап аппарата в raw формате. Вы можете увидеть всё содержимое в скопированном Блоке с помощью gptfdisk, доступного для Windows, Linux и других ОС (официальный сайт или SourceForge). Аналогичное вы сможете сделать при помощи ClockworkMod Recovery, но первоначально необходимо смонтировать Раздел /system, так как в BusyBox, входящем в ClockworkMod, отсутствует netcat, потому вам необходимо использовать netcat из /system раздела Вашего устройства.
При помощи определенных инструментов в Linux вы можете изменять и извлекать необходимые Разделы из всего Блока.
Вы можете использовать ADB через WiFi, аналогично как и Wi-Fi ADB.
Резервное копирование всей памяти (через WiFi)
Необходимо:
- Установленный FTP сервер на компьютере или другом устройстве;
- Пользователь с паролем;
- Установленный порт для FTP сервера, по умолчанию 21, но в данном примере используется 40;
- Домашняя директория пользователя с правами записи.
Правилом хорошего тона будет копирование myfifo в /cache, а не в /data, так как можно случайно затереть важные данные в случае использования raw данных для восстановления.
Запустите Cygwin Терминал и введите:
adb shell
su
mkfifo /cache/myfifo
ftpput -v -u user -p pass -P 40 COMPUTER_IP block.raw /cache/myfifo
Откройте другой Cygwin Терминал и введите:
adb shell
su
dd if=/dev/block/mmcblk0p12 of=/cache/myfifo
Некоторые замечания:
- FIFOs можно сделать только на Linux Native файловых системах, FAT для этого не подойдет;
- Процесс чтения Раздела с устройства никоим образом его не видоизменяет.
Резервное копирование всей памяти (через USB-модем или Wi-Fi-модем)
Для этого необходимо отключить все сетевые соединения на компьютере, кроме того, с помощью которого вы будете осуществлять процесс копирования.
Как только соедините компьютер с Android устройством, вы сможете просмотреть IP компьютера и IP устройства в «Свойствах соединения». IP — будет являться IP самого компьютера, а Gateway будет содержать IP Android устройства.
- Wi-Fi модем: Компьютер Android устройство Интернет
- USB модем:
Компьютер Android устройство Интернет
Компьютерные Android устройство Интернет
Процесс абсолютно аналогичный передачи данных через Wi-Fi, единственное, скорость передачи данных будет значительно выше, потому что компьютер и Android устройство соединены непосредственно, вместо того, чтобы использовать роутер в качестве шлюза. В данном случае шлюзом будет само Android устройство. USB-модем имеет самый высокий уровень передачи данных.
Резервное копирование одного Раздела (raw = точная побитовая копия раздела)
Все аналогично тому, что было описано выше, только необходимо заменить mmcblk0 на соответствующий Раздел. Вы можете использовать в данном конкретном случае ПО для просмотра содержимого скопированного Раздела. В зависимости от файловой системы: DiskInternals Linux Reader, Ext2Read, Ext2 File System Driver for Windows, Ext4Explore, плагин для Total Commander и ImDisk Virtual Disk Driver. Можно также использовать ПО для восстановления данных с отдельных разделов, например, Recuva совместно с VHD Tool или инструменты командной строки, включенные в сами операционные системы.
Резервное копирование одного Раздела (tar = копируются только файлы и папки)
Теперь вы должны знать, где и какой раздел монтируется, например, Firmware смонтирована в /system, которая по сути является ROM.
В данном случае вам придется открыть три Cygwin Терминала, вследствие ограничений, накладываемых самим Android:
Откройте первый Cygwin Терминал и создайте FIFO, например, в /cach, и перенаправте tar в него:
adb forward tcp:5555 tcp:5555
adb shell
su
/system/xbin/busybox mkfifo /cache/myfifo
/system/xbin/busybox tar -cvf /cache/myfifo /system
Вы должны это сделать потому, что перенаправление tar в stdout (c «-«) не работает на Android и портит сохраняемый файл.
Откройте второй Cygwin Терминал:
adb forward tcp:5555 tcp:5555
adb shell
su
/system/xbin/busybox nc -l -p 5555 -e /system/xbin/busybox cat /cache/myfifo
Откройте третий Cygwin Терминал:
adb forward tcp:5555 tcp:5555
cd /path/to/store/the/backup
nc 127.0.0.1 5555 | pv -i 0.5 > system.tar
Полученный tar файл вы можете просмотреть с помощью Winrar, Total Commander, PeaZip и т.д. Обратите внимание, вы не должны извлекать файлы или редактировать их, так как tar формат сохраняет данные доступа и владельца для каждого файла, которые исчезают при извлечении в FAT / NTFS разделы.
Источник