Одной из популярных операционных систем сегодня является Android. Она установлена на миллионах мобильных устройств. Система представляет собой набор папок и файлов, которые обеспечивают ее работу. Но задумывались ли вы когда-нибудь, что сдержится в каждой папке? Некоторые имеют достаточно большой вес, поэтому рука так и тянется их удалить. Прежде чем это сделать, стоит обязательно ознакомиться, за что каждая папка отвечает и , а также насколько важна для операционной системы. Также мы расскажем, какие есть способы удалить ненужную папку.

Основные ключевые каталоги в операционной системе android

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

Стоит отметить, что список папок может отличаться в зависимости от устройства и версии системы android. Также конкретные приложения могут создавать свои папки в памяти телефона на Андроиде. Рассмотрим, какие директории имеются в Андроид.

Cache – это папка для хранения временных файлов. В ней может находиться обновление системы. Если вы не собираетесь обновляться до более свежей версии Андроида, то файл обновления вам не нужен. Удалить эту папку можно, а в некоторых случаях даже нужно.

Data – один из крупнейших каталогов, который, как можно догадаться по названию, содержит разнообразные данные. Сюда входят данные аккаунтов, информация о сохраненных паролях, точках доступа Wi-Fi и т.п. Так как данная папка содержит множество информации, рассмотрим ее подкаталоги:

  1. App – директория, в которой содержатся установочные файлы различных приложений. Ее можно удалить, если вам не нужны все скачанные на телефон приложения;
  2. Data – включает в себя настройки, сохранения и другую служебную информацию, необходимую для работы конкретных приложений. Если важных для вас данных в приложениях нет, ее также можно удалить;
  3. Clipboard – это специальный буфер обмена данными, в котором также содержаться последние скриншоты. Удалить эту папку можно, но не рекомендуется;
  4. Dalvik-cache – это область кеш-памяти для программы под названием Davlink. Данное приложение является виртуальной Java-машиной, которая позволяет телефону запускать apk-файлы приложений. Чтобы максимально ускорить этот процесс, создаются файлы в кеш-памяти. Рекомендуется регулярно чистить содержимое, но удалять dalvik-cache не стоит.

Папка efs содержит информацию о серийном номере телефона (IMEI), MAC-адресе, Bluetooth и Wi-Fi. Эту директорию удалять нельзя. Более того, рекомендуется сделать бэкап этой папки, так как ее удаление приведет к потере уникального номера вашего смартфона.

Директория etc – содержит файлы конфигурации, преимущественно используемые во время загрузки ОС, процессов различных программ, к примеру, для определения местоположения по GPS. Это одна из системных директорий, удалять которую нельзя.

Каталог lib – в нем содержатся различные библиотеки, необходимые для корректной работы функций программ и модулей. Также данная папка содержит файлы, обеспечивающие работу драйверов. Удалять ее нельзя.

Каталог mnt – содержит образы монтируемых систем. Здесь могут располагаться разделы установленной карты памяти, внутренней памяти или других виртуальных устройств. Удалять данный каталог, естественно, тоже нельзя.

Папка proc – в ней содержится вся ключевая информация касательно установленной ОС Андроид: информация о ядре, параметрах конфигурации и оборудования. Все имеющиеся файлы и папки являются виртуальными, при этом весят ноль байт. Система автоматически создает их, когда пользователь получает доступ к ним. Эту папку с правами обычного пользователя удалить нельзя.

Директория sbin – одна из ключевых папок, необходимых для работы телефона. В ней имеются исполняемые файлы всех программ, предназначенных для управления системой. Ее удалять, соответственно, нельзя.

Каталог sys содержит конфигурацию системы на данный момент. Это динамический каталог. Информация в нем постоянно меняется. Стирать эту папку нельзя.

Раздел system – «хребет» всей операционной системы, так как именно в нем расположены все файлы, без которых невозможна работа android. Каталог System (как и любые другие внутренние директории) удалять нельзя. Для ознакомления рассмотрим подробней содержимое этого каталога:

  1. App – системные обои, стандартные приложения (календарь, записная книжка, СМС) находятся в этой папке.
  2. Bin включает в себя исполняемые файлы и ссылки;
  3. Build.prop содержит огромное количество настроек по телефону, например, на сколько задерживается работа сенсора после нажатия, какова плотность экрана и другое;
  4. Fonts – информация обо всех стоковых шрифтах, поддерживаемых в телефоне.
  5. Framework – все, что необходимо для интерфейса, в частности иконки, шторки и другие графические элементы;
  6. Lib – библиотека приложений;
  7. Media – все стандартные мелодии и звуки (будильник, оповещения на SMS, мелодии вызова);
  8. Tts включает языковые пакеты.

Documents – папка, в которой могут находиться разнообразные документы, в частности файлы формата.doc и.pdf. Если содержание папки вас не интересует, ее можно удалить.

Bluetooth – содержит все файлы, которые были приняты устройством через «Блютуз». Если важных данных в ней нет, она удаляется без проблем. Может быть расположена не только во внутренней памяти, но и на SD карте.

DCIM – это специальная директория для сохранения фотографий, созданных с помощью камеры вашего смартфона. Как правило, включает в себя раздел Camera, в котором располагаются все фото. Если необходимых для вас фото на телефоне нет, то ее можно удалить. Такие разделы, как Pictures, Images, Audio, Music (при отсутствии важных файлов внутри) также можно удалить.

Методы удаления

Как можно удалить конкретную папку? Первый способ – воспользоваться стандартными функциями. Для этого необходимо:

Тебя никогда не интересовало, как работают fastboot или ADB? Или почему смартфон под управлением Android практически невозможно превратить в кирпич? Или, может быть, ты давно хотел узнать, где кроется магия фреймворка Xposed и зачем нужны загрузочные скрипты /system/etc/init.d? А как насчет консоли восстановления (recovery)? Это часть Android или вещь в себе и почему для установки сторонней прошивки обычный рекавери не подходит? Ответы на все эти и многие другие вопросы ты найдешь в данной статье.

Как работает Android

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

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

Шаг первый. ABOOT и таблица разделов

Все начинается с первичного загрузчика. После включения питания система исполняет код загрузчика, записанного в постоянную память устройства. Затем он передает управление загрузчику aboot со встроенной поддержкой протокола fastboot, но производитель мобильного чипа или смартфона/планшета имеет право выбрать и любой другой загрузчик на его вкус. Например, компания Rockchip использует собственный, несовместимый с fastboot загрузчик, для перепрограммирования и управления которым приходится использовать проприетарные инструменты.

Протокол fastboot, в свою очередь, представляет собой систему управления загрузчиком с ПК, которая позволяет выполнять такие действия, как разлочка загрузчика, прошивка нового ядра и recovery, установка прошивки и многие другие. Смысл существования fastboot в том, чтобы иметь возможность восстановить смартфон в начальное состояние в ситуации, когда все остальные средства не работают. Fastboot останется на месте, даже если в результате экспериментов ты сотрешь со смартфона все разделы NAND-памяти, содержащие Android и recovery.

Получив управление, aboot проверяет таблицу разделов и передает управление ядру, прошитому в раздел с именем boot, после чего ядро извлекает в память RAM-образ из того же раздела и начинает загрузку либо Android, либо консоли восстановления. NAND-память в Android-устройствах поделена на шесть условно обязательных разделов:

  • boot - содержит ядро и RAM-диск, обычно имеет размер в районе 16 Мб;
  • recovery - консоль восстановления, состоит из ядра, набора консольных приложений и файла настроек, размер 16 Мб;
  • system - содержит Android, в современных девайсах имеет размер не менее 1 Гб;
  • cache - предназначен для хранения кешированных данных, также используется для сохранения прошивки в ходе OTA-обновления и поэтому имеет размер, сходный с размерами раздела system;
  • userdata - содержит настройки, приложения и данные пользователя, ему отводится все оставшееся пространство NAND-памяти;
  • misc - содержит флаг, определяющий, в каком режиме должна грузиться система: Android или recovery.

Кроме них, также могут существовать и другие разделы, однако общая разметка определяется еще на этапе проектирования смартфона и в случае aboot зашивается в код загрузчика. Это значит, что: 1) таблицу разделов нельзя убить, так как ее всегда можно восстановить с помощью команды fastboot oem format; 2) для изменения таблицы разделов придется разлочить и перепрошить загрузчик с новыми параметрами. Из этого правила, однако, бывают исключения. Например, загрузчик того же Rockchip хранит информацию о разделах в первом блоке NAND-памяти, так что для ее изменения перепрошивка загрузчика не нужна.

Особенно интересен раздел misc. Существует предположение, что изначально он был создан для хранения различных настроек независимо от основной системы, но в данный момент используется только для одной цели: указать загрузчику, из какого раздела нужно грузить систему - boot или recovery. Эту возможность, в частности, использует приложение ROM Manager для автоматической перезагрузки системы в recovery с автоматической же установкой прошивки. На ее же основе построен механизм двойной загрузки Ubuntu Touch, которая прошивает загрузчик Ubuntu в recovery и позволяет управлять тем, какую систему грузить в следующий раз. Стер раздел misc - загружается Android, заполнил данными - загружается recovery… то есть Ubuntu Touch.

Шаг второй. Раздел boot

Если в разделе misc не стоит флаг загрузки в recovery, aboot передает управление коду, расположенному в разделе boot. Это не что иное, как ядро Linux; оно находится в начале раздела, а сразу за ним следует упакованный с помощью архиваторов cpio и gzip образ RAM-диска, содержащий необходимые для работы Android каталоги, систему инициализации init и другие инструменты. Никакой файловой системы на разделе boot нет, ядро и RAM-диск просто следуют друг за другом. Содержимое RAM-диска такое:

  • data - каталог для монтирования одноименного раздела;
  • dev - файлы устройств;
  • proc - сюда монтируется procfs;
  • res - набор изображений для charger (см. ниже);
  • sbin - набор подсобных утилит и демонов (adbd, например);
  • sys - сюда монтируется sysfs;
  • system - каталог для монтирования системного раздела;
  • charger - приложение для отображения процесса зарядки;
  • build.prop - системные настройки;
  • init - система инициализации;
  • init.rc - настройки системы инициализации;
  • ueventd.rc - настройки демона uventd, входящего в состав init.

Это, если можно так выразиться, скелет системы: набор каталогов для подключения файловых систем из разделов NAND-памяти и система инициализации, которая займется всей остальной работой по загрузке системы. Центральный элемент здесь - приложение init и его конфиг init.rc, о которых во всех подробностях я расскажу позже. А пока хочу обратить внимание на файлы charger и ueventd.rc, а также каталоги sbin, proc и sys.

Файл charger - это небольшое приложение, единственная задача которого - вывести на экран значок батареи. Он не имеет никакого отношения к Android и используется тогда, когда устройство подключается к заряднику в выключенном состоянии. В этом случае загрузки Android не происходит, а система просто загружает ядро, подключает RAM-диск и запускает charger. Последний выводит на экран иконку батареи, изображение которой во всех возможных состояниях хранится в обычных PNG-файлах внутри каталога res.

Файл ueventd.rc представляет собой конфиг, определяющий, какие файлы устройств в каталоге sys должны быть созданы на этапе загрузки системы. В основанных на ядре Linux системах доступ к железу осуществляется через специальные файлы внутри каталога dev, а за их создание в Android отвечает демон ueventd, являющийся частью init. В нормальной ситуации он работает в автоматическом режиме, принимая команды на создание файлов от ядра, но некоторые файлы необходимо создавать самостоятельно. Они перечислены в ueventd.rc.

Каталог sbin в стоковом Android обычно не содержит ничего, кроме adbd, то есть демона ADB, который отвечает за отладку системы с ПК. Он запускается на раннем этапе загрузки ОС и позволяет выявить возможные проблемы на этапе инициализации ОС. В кастомных прошивках в этом каталоге можно найти кучу других файлов, например mke2fs, которая может потребоваться, если разделы необходимо переформатировать в ext3/4. Также модеры часто помещают туда BusyBox, с помощью которого можно вызвать сотни Linux-команд.

Каталог proc для Linux стандартен, на следующих этапах загрузки init подключит к нему procfs, виртуальную файловую систему, которая предоставляет доступ к информации обо всех процессах системы. К каталогу sys система подключит sysfs, открывающую доступ к информации о железе и его настройкам. С помощью sysfs можно, например, отправить устройство в сон или изменить используемый алгоритм энергосбережения.

Файл build.prop предназначен для хранения низкоуровневых настроек Android. Позже система обнулит эти настройки и перезапишет их значениями из недоступного пока файла system/build.prop.


Выносы из текста

  • Fastboot останется на месте, даже если в результате экспериментов ты сотрешь со смартфона содержимое всех разделов NAND-памяти
  • Раздел recovery полностью самодостаточен и содержит миниатюрную операционную систему, которая никак не связана с Android
  • Слегка изменив файл fstab, мы можем заставить init загрузить систему с карты памяти

Шаг второй, альтернативный. Раздел recovery

В том случае, если флаг загрузки recovery в разделе misc установлен или пользователь включил смартфон с зажатой клавишей уменьшения громкости, aboot передаст управление коду, расположенному в начале раздела recovery. Как и раздел boot, он содержит ядро и RAM-диск, который распаковывается в память и становится корнем файловой системы. Однако содержимое RAM-диска здесь несколько другое.

В отличие от раздела boot, выступающего в роли переходного звена между разными этапами загрузки ОС, раздел recovery полностью самодостаточен и содержит миниатюрную операционную систему, которая никак не связана с Android. У recovery свое ядро, свой набор приложений (команд) и свой интерфейс, позволяющий пользователю активировать служебные функции.

В стандартном (стоковом) recovery таких функций обычно всего три: установка подписанных ключом производителя смартфона прошивок, вайп и перезагрузка. В модифицированных сторонних recovery, таких как ClockworkMod и TWRP, функций гораздо больше. Они умеют форматировать файловые системы, устанавливать прошивки, подписанные любыми ключами (читай: кастомные), монтировать файловые системы на других разделах (в целях отладки ОС) и включают в себя поддержку скриптов, которая позволяет автоматизировать процесс прошивки и многие другие функции.

С помощью скриптов, например, можно сделать так, чтобы после загрузки recovery автоматически нашел на карте памяти нужные прошивки, установил их и перезагрузился в Android. Эта возможность используется инструментами ROM Manager, auto-flasher, а также механизмом автоматического обновления CyanogenMod и других прошивок.

Кастомные рекавери также поддерживают скрипты бэкапа, располагающиеся в каталоге /system/addon.d/. Перед прошивкой recovery проверяет наличие скриптов и выполняет их перед тем, как произвести прошивку. Благодаря таким скриптам gapps не исчезают после установки новой версии прошивки.

Команды fastboot

Чтобы получить доступ к fastboot, необходимо установить Android SDK, подключить смартфон к ПК с помощью кабеля и включить его, зажав обе кнопки громкости. После этого следует перейти в подкаталог platform-tools внутри SDK и запустить команду

Fastboot devices

На экран будет выведено имя устройства. Другие доступные команды:

  • fatsboot oem unlock - разлочка загрузчика на нексусах;
  • update файл.zip - установка прошивки;
  • flash boot boot.img - прошивка образа boot-раздела;
  • flash recovery recovery.img - прошивка образа раздела recovery;
  • flash system system.img - прошивка образа системы;
  • oem format - восстановление разрушенной таблицы разделов;

Шаг третий. Инициализация

Итак, получив управление, ядро подключает RAM-диск и по окончании инициализации всех своих подсистем и драйверов запускает процесс init, с которого начинается инициализация Android. Как я уже говорил, у init есть конфигурационный файл init.rc, из которого процесс узнает о том, что конкретно он должен сделать, чтобы поднять систему. В современных смартфонах этот конфиг имеет внушительную длину в несколько сот строк и к тому же снабжен прицепом из нескольких дочерних конфигов, которые подключаются к основному с помощью директивы import. Тем не менее его формат достаточно простой и по сути представляет собой набор команд, разделенных на блоки.

Каждый блок определяет стадию загрузки или, выражаясь языком разработчиков Android, действие. Блоки отделены друг от друга директивой on, за которой следует имя действия, например on early-init или on post-fs. Блок команд будет выполнен только в том случае, если сработает одноименный триггер. По мере загрузки init будет по очереди активировать триггеры early-init, init, early-fs, fs, post-fs, early-boot и boot, запуская таким образом соответствующие блоки команд.


Если конфигурационный файл тянет за собой еще несколько конфигов, перечисленных в начале (а это почти всегда так), то одноименные блоки команд внутри них будут объединены с основным конфигом, так что при срабатывании триггера init выполнит команды из соответствующих блоков всех файлов. Это сделано для удобства формирования конфигурационных файлов для нескольких устройств, когда основной конфиг содержит общие для всех девайсов команды, а специфичные для каждого устройства записываются в отдельные файлы.

Наиболее примечательный из дополнительных конфигов носит имя initrc.имя_устройства.rc, где имя устройства определяется автоматически на основе содержимого системной переменной ro.hardware. Это платформенно-зависимый конфигурационный файл, который содержит блоки команд, специфичные для конкретного устройства. Кроме команд, отвечающих за тюнинг ядра, он также содержит примерно такую команду:

Mount_all ./fstab.имя_устройства

Она означает, что теперь init должен подключить все файловые системы, перечисленные в файле./fstab.имя_устройства, который имеет следующую структуру:

Имя_устройства_(раздела) точка_монтирования файловая_система опции_фс прочие опции

Обычно в нем содержатся инструкции по подключению файловых систем из внутренних NAND-разделов к каталогам /system (ОС), /data (настройки приложений) и /cache (кешированные данные). Однако слегка изменив этот файл, мы можем заставить init загрузить систему с карты памяти. Для этого достаточно разбить карту памяти на три 4 раздела: 1 Гб / ext4, 2 Гб / ext4, 1 Гб / ext4 и оставшееся пространство fat32. Далее необходимо определить имена разделов карты памяти в каталоге /dev (для разных устройств они отличаются) и заменить ими оригинальные имена устройств в файле fstab.


В конце блока boot init, скорее всего, встретит команду class_start default, которая сообщит, что далее следует запустить все перечисленные в конфиге службы, имеющие отношение к классу default. Описание служб начинается с директивы service, за которой следует имя службы и команда, которая должна быть выполнена для ее запуска. В отличие от команд, перечисленных в блоках, службы должны работать все время, поэтому на протяжении всей жизни смартфона init будет висеть в фоне и следить за этим.

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

Команды init.rc

Процесс init имеет встроенный набор команд, многие из которых повторяют стандартный набор команд Linux. Наиболее примечательные из них:

  • exec /путь/до/команды - запустить внешнюю команду;
  • ifup интерфейс - поднять сетевой интерфейс;
  • class_start имя_класса - запустить службы, относящиеся к указанному классу;
  • class_stop имя_класса - остановить службы;
  • insmod /путь/до/модуля - загрузить модуль ядра;
  • mount ФС устройство каталог - подключить файловую систему;
  • setprop имя значение - установить системную переменную;
  • start имя_службы - запустить указанную службу;
  • trigger имя - включить триггер (выполнить указанный блок команд);
  • write /путь/до/файла строка - записать строку в файл.

Шаг четвертый. Zygote и app_process

На определенном этапе загрузки init встретит в конце конфига примерно такой блок:

Service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class default socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd

Это описание службы Zygote, ключевого компонента любой Android-системы, который ответственен за инициализацию, старт системных служб, запуск и остановку пользовательских приложений и многие другие задачи. Zygote запускается с помощью небольшого приложения /system/bin/app_process, что очень хорошо видно на приведенном выше куске конфига. Задача app_proccess - запустить виртуальную машину Dalvik, код которой располагается в разделяемой библиотеке /system/lib/libandroid_runtime.so, а затем поверх нее запустить Zygote.

Когда все это будет сделано и Zygote получит управление, он начинает формирование среды исполнения Java-приложений с помощью загрузки всех Java-классов фреймворка (сейчас их более 2000). Затем он запускает system_server, включающий в себя большинство высокоуровневых (написанных на Java) системных сервисов, в том числе Window Manager, Status Bar, Package Manager и, что самое важное, Activity Manager, который в будущем будет ответственен за получение сигналов о старте и завершении приложений.

После этого Zygote открывает сокет /dev/socket/zygote и уходит в сон, ожидая данные. В это время запущенный ранее Activity Manager посылает широковещательный интент Intent.CATEGORY_HOME, чтобы найти приложение, отвечающее за формирование рабочего стола, и отдает его имя Zygote через сокет. Последний, в свою очередь, форкается и запускает приложение поверх виртуальной машины. Вуаля, у нас на экране появляется рабочий стол, найденный Activity Manager и запущенный Zygote, и статусная строка, запущенная system_server в рамках службы Status Bar. После тапа по иконке рабочий стол пошлет интент с именем этого приложения, его примет Activity Manager и передаст команду на старт приложения демону Zygote

INFO

В терминологии Linux RAM-диск - это своего рода виртуальный жесткий диск, существующий только в оперативной памяти. На раннем этапе загрузки ядро извлекает содержимое диска из образа и подключает его как корневую файловую систему (rootfs).

В процессе загрузки Android отображает три разных загрузочных экрана: первый появляется сразу после нажатия кнопки питания и прошит в ядро Linux, второй отображается на ранних этапах инициализации и записан в файл /initlogo.rle (сегодня почти не используется), последний запускается с помощью приложения bootanimation и содержится в файле /system/media/bootanimation.zip.

Кроме стандартных триггеров, init позволяет определять собственные триггеры, которые могут срабатывать от самых разных событий: подключения устройства к USB, изменения состояния смартфона или изменения состояния системных переменных.

Кроме всего прочего, Activity Manager также занимается убийством фоновых приложений при нехватке памяти. Значения порогов свободной памяти содержатся в файле /sys/module/lowmemorykiller/parameters/minfree.

Все это может выглядеть несколько непонятно, но самое главное - запомнить три простые вещи:

Во многом Android сильно отличается от других ОС, и с наскоку в нем не разобраться. Однако, если понять, как все работает, открываются просто безграничные возможности. В отличие от iOS и Windows Phone, операционка от гугла имеет очень гибкую архитектуру, которая позволяет серьезно менять ее поведение без необходимости писать код. В большинстве случаев достаточно подправить нужные конфиги и скрипты.

Иногда некоторые приложения на Android чем-то не устраивают пользователя. В качестве примера можно привести назойливую рекламу. А то бывает и так - всем хороша программа, да только перевод в ней или кривой, или вовсе отсутствует. Или, например, программа триальная, а получить полную версию возможности нет. Как же изменить ситуацию?

Введение

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

Чтобы сделать все это самостоятельно, потребуются хотя бы начальные знания языка Java, на котором пишутся приложения для Android, и языка XML, который используется в Android повсеместно - от описания самого приложения и его прав доступа до хранения строк, которые будут выведены на экран. Также понадобится умение обращаться со специализированным консольным софтом.

Итак, что же представляет собой пакет APK, в котором распространяется абсолютно весь софт для Android?

Декомпиляция приложений

В статье мы работали только с дизассемблированным кодом приложения, однако если в большие приложения вносить более серьезные изменения, разобраться в коде smali будет гораздо сложнее. К счастью, мы можем декомпилировать код dex в Java-код, который будет хоть и не оригинальным и не компилируемым обратно, но гораздо более легким для чтения и понимания логики работы приложения. Чтобы сделать это, нам понадобятся два инструмента:

  • dex2jar - транслятор байт-кода Dalvik в байт-код JVM, на основе которого мы сможем получить код на языке Java ;
  • jd-gui - сам декомпилятор, позволяющий получить из байт-кода JVM читаемый код Java . В качестве альтернативы можно использовать Jad (www.varaneckas.com/jad); хоть он и довольно старый, но в некоторых случаях генерирует более читаемый код, нежели Jd-gui.

Использовать их следует так. Сначала запускаем dex2jar, указывая в качестве аргумента путь до apk-пакета:

% dex2jar.sh mail.apk

В результате в текущем каталоге появится Java-пакет mail.jar, который уже можно открыть в jd-gui для просмотра Java-кода.

Устройство APK-пакетов и их получение

Пакет приложения Android, по сути, является обычным ZIP-файлом, для просмотра содержимого и распаковки которого никаких специальных инструментов не требуется. Достаточно иметь архиватор - 7zip для Windows или консольный unzip в Linux. Но это что касается обертки. А что внутри? Внутри же у нас в общем случае такая структура:

  • META-INF/ - содержит цифровой сертификат приложения, удостоверяющий его создателя, и контрольные суммы файлов пакета;
  • res/ - различные ресурсы, которые приложение использует в своей работе, например изображения, декларативное описание интерфейса, а также другие данные;
  • AndroidManifest.xml - описание приложения. Сюда входит, например, список требуемых разрешений, требуемая версия Android и необходимое разрешение экрана;
  • classes.dex - компилированный байт-код приложения для виртуальной машины Dalvik;
  • resources.arsc - тоже ресурсы, но другого рода - в частности, строки (да-да, этот файл можно использовать для русификации!).

Перечисленные файлы и каталоги есть если не во всех, то, пожалуй, в абсолютном большинстве APK. Однако стоит упомянуть еще несколько не столь распространенных файлов/каталогов:

  • assets - аналог ресурсов. Основное отличие - для доступа к ресурсу необходимо знать его идентификатор, список asset’ов же можно получать динамически, используя метод AssetManager.list() в коде приложения;
  • lib - нативные Linux-библиотеки, написанные с помощью NDK (Native Development Kit).

Этот каталог используют производители игр, помещая туда движок игры, написанный на C/C++, а также создатели высокопроизводительных приложений (например, Google Chrome). С устройством разобрались. Но как же получить сам файл пакета интересующего приложения? Поскольку без рута с устройства забрать файлы APK не представляется возможным (они лежат в каталоге /data/app), а рутить не всегда целесообразно, имеется как минимум три способа получить файл приложения на компьютер:

  • расширение APK Downloader для Chrome ;
  • приложение Real APK Leecher ;
  • различные файлообменники и варезники.

Какой из них использовать - дело вкуса; мы предпочитаем использовать отдельные приложения, поэтому опишем использование Real APK Leecher, тем более что написан он на Java и, соответственно, работать будет хоть в винде, хоть в никсах.

После запуска программы необходимо заполнить три поля: Email, Password и Device ID - и выбрать язык. Первые два - e-mail и пароль твоего гуглоаккаунта, который ты используешь на устройстве. Третий же является идентификатором устройства, и его можно получить, набрав на номеронабирателе код # #8255## и затем найдя строку Device ID. При заполнении надо ввести только ID без префикса android-.

После заполнения и сохранения нередко выскакивает сообщение «Error while connecting to server». Оно не имеет отношения к Google Play, поэтому смело его игнорируй и ищи интересующие тебя пакеты.

Просмотр и модификация

Допустим, ты нашел интересующий тебя пакет, скачал, распаковал… и при попытке просмотра какого-нибудь XML-файла с удивлением обнаружил, что файл не текстовый. Чем же его декомпилировать и как вообще работать с пакетами? Неужели необходимо ставить SDK? Нет, SDK ставить вовсе не обязательно. На самом деле для всех шагов по распаковке, модификации и упаковке пакетов APK нужны следующие инструменты:

  • архиватор ZIP для распаковки и запаковки;
  • smali - ассемблер/дизассемблер байт-кода виртуальной машины Dalvik (code.google.com/p/smali);
  • aapt - инструмент для запаковки ресурсов (по умолчанию ресурсы хранятся в бинарном виде для оптимизации производительности приложения). Входит в состав Android SDK, но может быть получен и отдельно;
  • signer - инструмент для цифровой подписи модифицированного пакета (bit.ly/Rmrv4M).

Использовать все эти инструменты можно и по отдельности, но это неудобно, поэтому лучше воспользоваться более высокоуровневым софтом, построенным на их основе. Если ты работаешь в Linux или Mac OS X, то тут есть инструмент под названием apktool . Он позволяет распаковывать ресурсы в оригинальный вид (в том числе бинарные XML- и arsc-файлы), пересобирать пакет с измененными ресурсами, но не умеет подписывать пакеты, так что запускать утилиту signer придется вручную. Несмотря на то что утилита написана на Java, ее установка достаточно нестандартна. Сначала следует получить сам jar-файл:

$ cd /tmp $ wget http://bit.ly/WC3OCz $ tar -xjf apktool1.5.1.tar.bz2

$ wget http://bit.ly/WRjEc7 $ tar -xjf apktool-install-linux-r05-ibot.tar.bz2

$ mv apktool.jar ~/bin $ mv apktool-install-linux-r05-ibot/* ~/bin $ export PATH=~/bin:$PATH

Если же ты работаешь в Windows, то для нее есть превосходный инструмент под названиемVirtuous Ten Studio , который также аккумулирует в себе все эти инструменты (включая сам apktool), но вместо CLI-интерфейса предоставляет пользователю интуитивно понятный графический интерфейс, с помощью которого можно выполнять операции по распаковке, дизассемблированию и декомпиляции в несколько кликов. Инструмент этот Donation-ware, то есть иногда появляются окошки с предложением получить лицензию, но это, в конце концов, можно и потерпеть. Описывать его не имеет никакого смысла, потому что разобраться в интерфейсе можно за несколько минут. А вот apktool, вследствие его консольной природы, следует обсудить подробнее.


Рассмотрим опции apktool. Если вкратце, то имеются три основные команды: d (decode), b (build) и if (install framework). Если с первыми двумя командами все понятно, то что делает третья, условный оператор? Она распаковывает указанный UI-фреймворк, который необходим в тех случаях, когда ты препарируешь какой-либо системный пакет.

Рассмотрим наиболее интересные опции первой команды:

  • -s - не дизассемблировать файлы dex;
  • -r - не распаковывать ресурсы;
  • -b - не вставлять отладочную информацию в результаты дизассемблирования файла dex;
  • —frame-path - использовать указанный UI-фреймворк вместо встроенного в apktool. Теперь рассмотрим пару опций для команды b:
  • -f - форсированная сборка без проверки изменений;
  • -a - указываем путь к aapt (средство для сборки APK-архива), если ты по какой-то причине хочешь использовать его из другого источника.

Пользоваться apktool очень просто, для этого достаточно указать одну из команд и путь до APK, например:

$ apktool d mail.apk

После этого в каталоге mail появятся все извлеченные и дизассемблированные файлы пакета.

Препарирование. Отключаем рекламу

Теория - это, конечно, хорошо, но зачем она нужна, если мы не знаем, что делать с распакованным пакетом? Попробуем применить теорию с пользой для себя, а именно модифицируем какую-нибудь софтину так, чтобы она не показывала нам рекламу. Для примера пусть это будет Virtual Torch - виртуальный факел. Для нас эта софтина подойдет идеально, потому что она под завязку набита раздражающей рекламой и к тому же достаточно проста, чтобы не потеряться в дебрях кода.


Итак, с помощью одного из приведенных способов скачай приложение из маркета . Если ты решил использовать Virtuous Ten Studio, просто открой APK-файл в приложении и распакуй его, для чего создай проект (File -> New project), затем в контекстном меню проекта выбери Import File. Если же твой выбор пал на apktool, то достаточно выполнить одну команду:

$ apktool d com.kauf.particle.virtualtorch.apk

После этого в каталоге com.kauf.particle.virtualtorch появится файловое дерево, похожее на описанное в предыдущем разделе, но с дополнительным каталогом smali вместо dex-файлов и файлом apktool.yml. Первый содержит дизассемблированный код исполняемого dex-файла приложения, второй - служебную информацию, необходимую apktool для сборки пакета обратно.

Первое место, куда мы должны заглянуть, - это, конечно же, AndroidManifest.xml. И здесь мы сразу встречаем следующую строку:

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

$ apktool b com.kauf.particle.virtualtorch

В каталоге com.kauf.particle.virtualtorch/build/ появится результирующий APK-файл. Однако установить его не получится, так как он не имеет цифровой подписи и контрольных сумм файлов (в нем просто нет каталога META-INF/). Мы должны подписать пакет с помощью утилиты apk-signer. Запустили. Интерфейс состоит из двух вкладок - на первой (Key Generator) создаем ключи, на второй (APK Signer) подписываем. Чтобы создать наш приватный ключ, заполняем следующие поля:

  • Target File - выходной файл хранилища ключей; в нем обычно хранится одна пара ключей;
  • Password и Confirm - пароль для хранилища;
  • Alias - имя ключа в хранилище;
  • Alias password и Confirm - пароль секретного ключа;
  • Validity - срок действия (в годах). Значение по умолчанию оптимально.

Остальные поля, в общем-то, необязательны - но необходимо заполнить хотя бы одно.


WARNING

Чтобы подписать приложение с помощью apk-signer, ты должен установить Android SDK и указать полный путь до него в настройках приложения.

Вся информация предоставлена исключительно в ознакомительных целях. Ни редакция, ни автор не несут ответственности за любой возможный вред, причиненный материалами данной статьи.

Теперь этим ключом можно подписать APK. На вкладке APK Signer выбираем только что сгенерированный файл, вводим пароль, алиас ключа и пароль к нему, затем находим файл APK и смело жмем кнопку «Sign». Если все пройдет нормально, пакет будет подписан.

INFO

Так как мы подписали пакет нашим собственным ключом, он будет конфликтовать с оригинальным приложением, а это значит, что при попытке обновить софтину через маркет мы получим ошибку.

Цифровая подпись необходима только стороннему софту, поэтому если ты занимаешься модификацией системных приложений, которые устанавливаются копированием в каталог /system/app/, то подписывать их не нужно.

После этого скидываем пакет на смартфон, устанавливаем и запускаем. Вуаля, реклама пропала! Вместо нее, однако, появилось сообщение, что у нас нет интернета или отсутствуют соответствующие разрешения. По идее, этого могло бы и хватить, но сообщение выглядит раздражающе, да и, если честно, нам просто повезло с тупым приложением. Нормально написанная софтина, скорее всего, уточнит свои полномочия или проверит наличие интернет-соединения и в противном случае просто откажется запускаться. Как быть в этом случае? Конечно, править код.

Обычно авторы приложений создают специальные классы для вывода рекламы и вызывают методы этих классов во время запуска приложения или одной из его «активностей» (упрощенно говоря, экранов приложения). Попробуем найти эти классы. Идем в каталог smali, далее com (в org лежит только открытая графическая библиотека cocos2d), далее kauf (именно туда, потому что это имя разработчика и там лежит весь его код) - и вот он, каталог marketing. Внутри находим кучу файлов с расширением smali. Это классы, и наиболее примечателен из них класс Ad.smali, по названию которого нетрудно догадаться, что именно он выводит рекламу.

Мы могли бы изменить логику его работы, но гораздо проще будет тупо убрать вызовы любых его методов из самого приложения. Поэтому выходим из каталога marketing и идем в соседний каталог particle, а затем в virtualtorch. Особого внимания здесь заслуживает файл MainActivity.smali. Это стандартный для Android класс, который создается Android SDK и устанавливается в качестве точки входа в приложение (аналог функции main в Си). Открываем файл на редактирование.

Внутри находится код smali (местный ассемблер). Он довольно запутанный и трудный для чтения в силу своей низкоуровневой природы, поэтому мы не будем его изучать, а просто найдем все упоминания класса Ad в коде и закомментируем их. Вбиваем строку «Ad» в поиске и попадаем на строку 25:

Field private ad:Lcom/kauf/marketing/Ad;

Здесь создается поле ad для хранения объекта класса Ad. Комментируем с помощью установки знака ### перед строкой. Продолжаем поиск. Строка 423:

New-instance v3, Lcom/kauf/marketing/Ad;

Здесь происходит создание объекта. Комментируем. Продолжаем поиск и находим в строках 433, 435, 466, 468, 738, 740, 800 и 802 обращения к методам класса Ad. Комментируем. Вроде все. Сохраняем. Теперь пакет необходимо собрать обратно и проверить его работоспособность и наличие рекламы. Для чистоты эксперимента возвращаем удаленную из AndroidManifest.xml строку, собираем пакет, подписываем и устанавливаем.

Наш подопытный кролик. Видна реклама

Оп-па! Реклама пропала только во время работы приложения, но осталась в главном меню, которое мы видим, когда запускаем софтину. Так, подождите, но ведь точка входа - это класс MainActivity, а реклама пропала во время работы приложения, но осталась в главном меню, значит, точка входа другая? Чтобы выявить истинную точку входа, вновь открываем файл AndroidManifest.xml. И да, в нем есть следующие строки:

Они говорят нам (и, что важнее, андроиду) о том, что активность с именем Start должна быть запущена в ответ на генерацию интента (события) android.intent.action.MAIN из категории android.intent.category.LAUNCHER. Это событие генерируется при тапе на иконку приложения в ланчере, поэтому оно и определяет точку входа, а именно класс Start. Скорее всего, программист сначала написал приложение без главного меню, точкой входа в которое был стандартный класс MainActivity, а затем добавил новое окно (активность), содержащее меню и описанное в классе Start, и вручную сделал его точкой входа.

Открываем файл Start.smali и вновь ищем строку «Ad», находим в строках 153 и 155 упоминание класса FirstAd. Он тоже есть в исходниках и, судя по названию, как раз и отвечает за показ объявлений на главном экране. Смотрим дальше, идет создание экземпляра класса FirstAd и интента, по контексту имеющего отношение к этому экземпляру, а дальше метка cond_10, условный переход на которую осуществляется аккурат перед созданием экземпляра класса:

If-ne p1, v0, :cond_10 .line 74 new-instance v0, Landroid/content/Intent; ... :cond_10

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

#if-ne p1, v0, :cond_10 goto:cond_10

Больше упоминаний FirstAd в коде нет, поэтому закрываем файл и вновь собираем наш виртуальный факел с помощью apktool. Копируем на смартфон, устанавливаем, запускаем. Вуаля, вся реклама исчезла, с чем нас всех и поздравляем.

Итоги

Эта статья лишь краткое введение в методы вскрытия и модификации Android-приложений. За кадром остались многие вопросы, такие как снятие защиты, разбор обфусцированного кода, перевод и замена ресурсов приложения, а также модификация приложений, написанных с использованием Android NDK. Однако, имея базовые знания, разобраться во всем этом - лишь вопрос времени.

Это опять я и мои инструкции для чайников и кофейников с картинками.

На этот раз я подробно расскажу о замене системных компонентов ОС Android на примере установки модификации строки состояния.

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

Нам понадобится:

  • Менеджер файлов, который умеет работать с root-правами и разрешениями файлов. Лучше всего подойдет Root Explorer (Вы же его купили, да?)
  • Сам модифицированный файл, который мы хотим положить наместо системного (ссылка в конце статьи).

Теперь используем одну из удобных функций Root Explorer. Сделаем долгий тап по нужному файлу, чтобы вызвать контекстное меню

И щелкаем по пункту "Zip this file ", чтобы сохранить файл в zip-архиве на SD-карте. После архивации получим такое сообщение:

Нажимаем кнопкй "Stay ", чтобы остаться в папке и сделать еще кое-что.

Теперь всё готово для замены файла.
Я уже говорил про права доступа у каждого файла. Чтобы их воссоздать на новом файле, надо сначала посмотреть их у старого. Они представлены рядом символов "rwxrwxrwx ". 1-я триада - права владельца, 2-я - группы владельца, 3-я - всех остальных пользователей. У нашего файла права "rw-r--r--".

Теперь переходим на SD-карту, находим там модифицированный файл и из его контекстного меню выбираем пункт "Copy ", но не торопимся выбирать сразу папку "/system/app ", потому что мы тут же повредим систему. Вместо этого копируем файл в специальную папку для временных файлов "/data/local/tmp ", чтобы привести файл в вид, который примет система.
Для начала вызовем контекстное меню файла и выберем пункт "Rename " и введем имя файла "SystemUI.apk ". Именно так, потому что в Linux регистр букв в имени имеет значение, т.е. "systemui.apk " и "SystemUI.apk " - это разные файлы.
Далее надо изменить права на файл, потому что сейчас они почти наверняка выставлены неправильно. Для этого опять вызываем контекстное меню файла долгим тапом и выбираем пункт "Permissions ". Для нашего значени "rw-r--r--" флажки надо расставить так:

Нажимаем "OK " и снова вызываем контекстное меню. Теперь надо изменить владельца и группу для этого приложения. Для этого выбираем пункт "Изменить владельца ". Появится окно с информацией о текущем владельце файла.
Тут надо сделать маленькое отступление.
В папке "/system/app " всеми файлами владеет пользователь "root" (uid=0) и группа "root" (gid=0), а в папке "/system/framework " властвует пользователь "system" (gid=1000) и группа "system" (gid=1000).
Исходя из вышесказанного, выставляем нужные значения и нажимаем "OK ".
И в третий раз вызываем контекстное меню для файла и в нем выбираем пункт "Copy " и в диалоге копирования переходим в папку "/system/app ". Теперь смело нажимаем "Paste " и читаем дальше внимательно.
Практически сразу система сообщит, что процесс строки состояния внезапно завершился, и предложит его запустить. Всё попытки будут неудачными. Между появлениями окон надо успеть сделать ряд действий. Перед нажатием кнопки надо вызвать меню выключения аппарата, оно окажется под предупреждением. Теперь надо расположить палец примерно в левой стороне кнопки. Теперь надо очень быстро щелкнуть три раза пальцем, что успеть закрыть предупреждение, выбрать пункт выключения и подтвердить свои намерения.
Теперь ждем выключения телефона, заново его запускаем и наслаждаемся результатом или не наслаждаемся и ищем ошибки.

Системные приложения Google, такие как Gmail, Google Карты, Google+, Gtalk можно сносить, но сервисы лучше оставить, так как их отсутствие приведет к сбоям в работе Play Market, игр и других программ, частым ошибкам.

Кроме того, нельзя удалять Адреса и Навигацию, если планируется использование Google Maps, но можно избавиться от Просмотра улиц, так как оно он не входит в это приложение.

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

Родные программы расположены в папке /system/app и представлены файлами с расширениями apk и odex. Если прошивка деодексированная, то тут имеются только apk. Чтобы попасть в папку нужно использовать сторонний файловый менеджер, например, Root Explorer.

Удалять приложения можно вручную и через дополнительные программы. В первом случае надо:

  • через Root Explorer зайти в /system/app;
  • нажать на кнопку «Права R/W» вверху справа, перемонтировав папку для записи;
  • поставить галки на удаляемые apk и odex файлы приложения, у которых одинаковое название;
  • внизу выбрать значок с ножницами;

  • перейти в папку на флешке;
  • далее «Переместить сюда».

Использовать именно перемещения нужно, потому что файлы при необходимости можно будет вернуть.

Для упрощения процедуры можно установить Uninstaller pro.

Используют ее так:

  • после первого запуска нужно предоставить ему права суперпользователя;
  • нажать кнопку назад;
  • в списке программ найти нужную и нажать на нее;
  • затем «Удалить» и согласиться.

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

Если стандартная программа была обновлена, то сначала нужно обновление удалить стандартным способом:

  • зайти в «Настройки»;
  • «Приложения»;
  • выбрать нужное;
  • «Удалить обновление».

После стирания основных файлов остаточные располагаются в следующих папках:

  • /system/lib содержит библиотеки.so, которые нужны для работы связанных приложений, они не соответствуют названию основного файла и их ни в коем случае нельзя трогать, так как это может убить устройство;
  • /data/dalvik-cache - их надо удалять, для этого лучше делать hard reset.

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

Обновление: как указано ниже пользователем864555, это еще одно решение

«Этот код отключает приложение SystemUI, которое является фактически панелью меню. Какую эту модификацию вы также получите пространство этой панели системы, но обязательно запустите кнопку« Назад »или что-то для выхода».

Обновление: Вот третий метод. Способ сделать это программно или с помощью командной строки. Найдено здесь: http://android.serverbox.ch/?p=306

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

В блоге также показано, как реализовать его в своем приложении для Android, помните, что для него требуется root, и, возможно, это не идеальная идея, если ваше приложение не работает в киоске или вашем собственном устройстве, не используйте этот метод для приложение, опубликованное на рынке Android или в любом месте.

Чтобы остановить / удалить / отключить системную панель (необходимо выполнить команду su перед выдачей этой команды):

Для восстановления системной панели просто выполните эту команду:

Это так просто. Надеюсь, ICS скоро выпустят вместе с исходным кодом, чтобы каждый мог создавать Android для наших киосковских таблеток.

В Android 2.3 и ниже вы можете сделать приложение полноэкранным, а затем «захватить» кнопки меню / назад / поиска, просто вернув false onKeyDown () … и зарегистрировав приложение как стандартное приложение для запуска дома, нет выхода из приложения.

В Android 3.0 (Honeycomb) всегда присутствуют кнопки навигации (системная панель), я бы хотел скрыть это. Является ли это возможным?

FYI, я не публикую это приложение на Android Market. Это внутреннее приложение для устройств, которые будут использоваться внутри, мне нужно защитить устройство.

На большинстве современных смартфонах и планшетах установленная операционная система Андроид. Всеми файлами находящимися на смартфоне или планшете можно управлять непосредственно через само мобильное устройство, а так же можно делать это при помощи компьютера, к которому подключен смартфон или планшет.

Одной из программ для управления файлами Андроид через стационарный компьютер является Mobogenie. При помощи данной программы можно не только управлять файлами на мобильном девайсе но и скачивать через Интернет на него новые игры, музыку, видео и картинки. Программа подключена к сервису через который можно закачать нужные файлы.

Сама по себе программа проста и понятна, после запуска она ищет мобильное устройство и если не находит его, то предлагает подключить и для удобства предлагает просмотреть руководство как подключится через usb кабель.

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

Закачивать различные файлы можно прямо на устройство либо можно скачать файл на компьютер, а потом через папку программы закачать на девайс.

Структура и назначение папок и файлов в Android

Все скаченные файлы можно найти в меню task(s), оно расположено в самом нижу. Там же, нажав на надпись в верху окна open downloads folder можно открыть папку куда скачиваются все файлы на компьютер. Для того что бы сделать резервную копию или же воспользоваться файловым менеджером что управлять файлами на Андроиде, следует зайти в меню toolkit.

В общем программа для управления файлами Андроид через компьютер Mobogenie хорошо облегчает работу с мобильными устройствами.

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

Распространение: бесплатно.
Операционная система: Windows XP, Windows Vista, Windows 7, Windows 8, Windows 10.
Интерфейс: английский.
Сайт программы mobogenie.com

Android ADB — это плагин для Total Commander , который позволяет получить полный доступ к файловой системе Android , и другим некоторым функциям системы.

Как отредактировать или заменить системные файлы и папки?

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

Особенности:

  • Управление приложениями (установка, удаление и резервное копирование)
  • Иконки приложений и их метаданные в столбцах
  • Логи, отчеты об ошибках, логи ядра, Shell
  • Перезагрузка из меню (Выключение, перезагрузка, рекавери)
  • Скриншоты (Простое копирование из папки.screenshot).
  • Подключение нескольких устройств с возможностью переименования
  • Подходит для девайсов с рутом и без него
  • Полная поддержка юникода
  • Поддержка x32 и x64 систем
  • Интеграция с командной строкой TC
  • Выполнение команд копирования и перемещения в фоне
  • Настраиваемые столбцы данных о файлах
  • Полное управление файловой системой
  • Копирование между двумя устройствами
  • Изменение разрешений файлов
  • ADB USB и беспроводной ADB (нет необходимости устанавливать Android SDK)
  • Поддержка авто монтирования устройства
  • Debug логи
  • Разные настройки

Требования:

— На телефоне должна быть включена «Отладка по USB «

— Должны быть установлены драйвера телефона

— WiFi ADB для беспроводного подключения (Можно найти на Google Play ), если нужен

— Android SDK для работы плагина не нужен!

Установка:

Если вы попытаетесь открыть архив в Total Commander , то менеджер автоматически спросит у вас об установке плагина.

В ТС открываем сетевое окружение, выглядит как «\» возле перечисленных дисков. Выбираем \ADB, затем ваш телефон MSM8225*, возможно понадобиться перезагрузить Total Commander .

Скриншоты:

Скачать ADBplugin_v7.3.zip 7247

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

Для того чтобы вносить изменения в код, требуются элементарные навыки программирования практически на любых языках (желательно - Java и C++). Для замены графики сгодятся прямые руки и умение работать в графическом редакторе.

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

Изменение графики в системных приложениях Андроид

Для того чтобы просто заменить либо видоизменить исходную графику (поменять цвета кнопок, перерисовать картинки и т.п.), достаточно иметь на компьютере стандартный архиватор WinRAR. На аппарате при этом у пользователя должны быть права «рут» (аналог учетной записи администратора на Windows), а также желательно иметь альтернативный рекавери (CWM) и рут-эксплорер (для доступа к файловой системе Андроид непосредственно в самом девайсе).

В первую очередь необходимо включить в аппарате «Отладку по USB», затем подключить его к компьютеру при помощи USB-кабеля и установить необходимые драйвера. Обычно они находятся на виртуальном диске, который появляется при подключении к компьютеру.

Затем нужно также скачать в сети Интернет ADB-плагин для файлового менеджера. Данный плагин позволяет видеть всю систему Андроид как подключенный диск с папками. Все системные приложения находятся по адресу /system/app, а также /system/framework. Найдя нужное приложение, просто копируем его на компьютер. Если плагин не ставится, можно с помощью рут-эксплорера скопировать приложение с расширением apk на съемную SD-карту, а затем уже с нее уже на компьютер.

Папки в Android-смартфоне и что они означают

После копирования нужного приложения можно приступать к редактированию графики. К слову, все картинки в приложениях Андроид сохраняются в формате png, который легко открывается любым графическим редактором. Открыв файл приложения с помощью WinRAR, можно увидеть ряд папок. Нас будет интересовать только папка res, внутри которой обнаружится, в свою очередь, очень много разных папок. Из них необходимы только те, которые имеют в своем названии слово «drawable».

Теперь вспомним наш тип девайса и разрешение его экрана. Если это смартфон, а разрешение равно 240х320, то нас будут интересовать преимущественно папки drawable и drawable-ldpi. Если разрешение 320х480 - соответственно папки drawable и drawable-mdpi, а для разрешения 480х800 - папки drawable и drawable-hdpi. В дополнение к ним обычно присутствуют также папки, в названии которых есть слово «land» - это графика для портретного режима, т.е. когда девайс наклоняют.

Если в руках планшет, то нас будут интересовать только папки drawable и drawable-mdpi при любом разрешении экрана.

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

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

Подправленное приложение закачивается обратно в аппарат либо при помощи рут-эксплорера (сначала файл копируется на SD-карту, а с нее — уже в девайс), либо после выхода в рекавери - сразу с компьютера в папку /system/app или /system/framework. Далее нужно обязательно выставить при помощи соответствующих опций в рут-эксплорере или плагине ADB разрешения на файл. Они должны быть формата 644. После перезагрузки аппарата можно посмотреть результат работы обновленного приложения.

Редактирование исходного кода системных приложений

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

1) Установить на компьютер необходимый пакет программ в их последних версиях: Java SE Runtime Environment и Android SDK Windows (программы для работы с приложениями и их компонентами), APKtool или APKManager либо Firmware_tool (одна из трех программ для разборки и декомпиляции системных приложений), редактор NotePad++ (для внесения изменений в исходный код системных приложений Андроид).

2) Включить в аппарате «Отладку по USB», подключить его к компьютеру при помощи USB-кабеля, установить необходимые драйвера для работы с девайсом.

3) При помощи одной из вышеназванных программ для работы с кодом приложений необходимо извлечь из телефона в соответствующую папку программы папку /system/framework (полностью) и системные приложения из папки /system/app. Например, для программы Firmware_tool файлы из телефона необходимо скопировать в папку C:Firmwaretoolfw_project1_source2_system.img_unpacked в соответствующие подпапки (приложения - в папку app, файлы из framework - в папку framework). При использовании как этой, так и других программ нужно обязательно прочесть инструкцию к ним.

4) Установить «опорный framework», т.е. набор правил, в соответствии с которыми будет осуществляться декомпиляция (т.е. разборка кода) и компиляция (т.е. сборка кода) приложений.

На этом подготовка к работе с системными приложениями завершена.

Выгрузка приложений из девайса и их загрузка обратно осуществляется аналогично процедуре, описанной в разделе «Изменение графики в системных приложениях Андроид».

Редактирование кода приложений Андроид обычно производится с помощью редактора NotePad++ — одного из самых удобных текстовых редакторов, имеющих опцию подсветки синтаксиса выбранного языка программирования. Как правило, при редактировании можно также попутно менять графику с помощью выбранного графического редактора.

По завершению редактирования измененное приложение загружается обратно в девайс, а сам аппарат нужно перезагрузить. Более продвинутые редакторы для отладки приложений перед их закачкой в девайс используют различные эмуляторы, например, Eclipse от компании Google.