- Работа с файловой системой
- Чтение и сохранение файлов
- Хранение данных и файлов
- Внешняя карта памяти
- Состояние на текущий момент
- Что делать?
- Android 11
- Android sdk galaxy tab файловая система
- Подготовка и установка SDK
- Архитектура SDK
- Работа с виртуальными девайсами
- Android Debug Bridge (ADB)
- Dalvik Debug Monitor Server (DDMS)
- Ссылки
- Комментарии
Работа с файловой системой
Чтение и сохранение файлов
Работа с настройками уровня activity и приложения позволяет сохранить небольшие данные отдельных типов (string, int), но для работы с большими массивами данных, такими как графически файлы, файлы мультимедиа и т.д., нам придется обращаться к файловой системе.
ОС Android построена на основе Linux. Этот факт находит свое отражение в работе с файлами. Так, в путях к файлам в качестве разграничителя в Linux использует слеш «/», а не обратный слеш «\» (как в Windows). А все названия файлов и каталогов являются регистрозависимыми, то есть «data» это не то же самое, что и «Data».
Приложение Android сохраняет свои данные в каталоге /data/data/ / и, как правило, относительно этого каталога будет идти работа.
Для работы с файлами абстрактный класс android.content.Context определяет ряд методов:
boolean deleteFile (String name) : удаляет определенный файл
String[] fileList () : получает все файлы, которые содержатся в подкаталоге /files в каталоге приложения
File getCacheDir() : получает ссылку на подкаталог cache в каталоге приложения
File getDir(String dirName, int mode) : получает ссылку на подкаталог в каталоге приложения, если такого подкаталога нет, то он создается
File getExternalCacheDir() : получает ссылку на папку /cache внешней файловой системы устройства
File getExternalFilesDir(String type) : получает ссылку на каталог /files внешней файловой системы устройства
File getFileStreamPath(String filename) : возвращает абсолютный путь к файлу в файловой системе
FileInputStream openFileInput(String filename) : открывает файл для чтения
FileOutputStream openFileOutput (String name, int mode) : открывает файл для записи
Все файлы, которые создаются и редактируются в приложении, как правило, хранятся в подкаталоге /files в каталоге приложения.
Для непосредственного чтения и записи файлов применяются также стандартные классы Java из пакета java.io.
Итак, применим функционал чтения-записи файлов в приложении. Пусть у нас будет следующая примитивная разметка layout:
Поле EditText предназначено для ввода текста, а TextView — для вывода ранее сохраненного текста. Для сохранения и восстановления текста добавлены две кнопки.
Теперь в коде Activity пропишем обработчики кнопок с сохранением и чтением файла:
При нажатии на кнопку сохранения будет создаваться поток вывода FileOutputStream fos = openFileOutput(FILE_NAME, MODE_PRIVATE)
В данном случае введенный текст будет сохраняться в файл «content.txt». При этом будет использоваться режим MODE_PRIVATE
Система позволяет создавать файлы с двумя разными режимами:
MODE_PRIVATE : файлы могут быть доступны только владельцу приложения (режим по умолчанию)
MODE_APPEND : данные могут быть добавлены в конец файла
Поэтому в данном случае если файл «content.txt» уже существует, то он будет перезаписан. Если же нам надо было дописать файл, тогда надо было бы использовать режим MODE_APPEND:
Для чтения файла применяется поток ввода FileInputStream :
Подробнее про использование потоков ввода-вывода можно прочитать в руководстве по Java: https://metanit.com/java/tutorial/6.3.php
В итоге после нажатия кнопки сохранения весь текст будет сохранен в файле /data/data/название_пакета/files/content.txt
Где физически находится созданный файл? Чтобы увидеть его на подключенном устройстве перейдем в Android Stud в меню к пункту View -> Tool Windows -> Device File Explorer
После этого откроектся окно Device File Explorer для просмотра файловой системы устройства. И в папке data/data/[название_пакета_приложения]/files мы сможем найти сохраненный файл.
Источник
Хранение данных и файлов
В целом хранение файлов и данных можно условно разделить на две группы: во внутреннем или внешнем хранилище. Но разница между ними довольна тонка. В целом политика Гугла в отношение данных ужесточается с каждой версии системы.
Android поддерживает различные варианты хранения данных и файлов.
- Специфичные для приложения файлы. Доступ к файлам имеет только приложение, их создавшее. Файлы могут находиться во внутреннем и внешнем хранилище. У других приложений нет доступа (кроме случаев, когда файлы хранятся на внешнем хранилище). Методы getFilesDir(), getCacheDir(), getExternalFilesDir(), getExternalCacheDir(). Разрешений на доступ не требуется. Файлы удаляются, когда приложение удаляется пользователем.
- Разделяемое хранилище. Приложение может создавать файлы, которыми готово поделиться с другими приложениями — медиафайлы (картинки, видео, аудио), документы. Для медифайлов требуется разрешение READ_EXTERNAL_STORAGE или WRITE_EXTERNAL_STORAGE.
- Настройки. Хранение простых данных по принципу ключ-значение. Доступно внутри приложения. Реализовано через Jetpack Preferences. Настройки удаляются, когда приложение удаляется пользователем.
- Базы данных. Хранение данных в SQLite. На данный момент реализовано через библиотеку Room. Доступ только у родного приложения.
В зависимости от ваших потребностей, нужно выбрать нужный вариант хранения данных.
Следует быть осторожным при работе с внутренним и внешним хранилищем. Внутренне хранилище всегда есть в системе, но оно может быть не слишком большим по объёму. Вдобавок к внутреннему хранилищу, устройство может иметь внешнее хранилище. В старых моделях таким хранилищем выступала съёмная SD-карта. Сейчас чаще используют встроенную и недоступную для извлечения флеш-память. Если ваше приложение слишком большое, можно попросить систему устанавливать программу во внешнее хранилище, указав просьбу в манифесте.
В разных версиях Android требования к разрешению для работы с внешним хранилищем постоянно менялись. На данный момент (Android 10, API 29) требования выглядят следующим образом.
Приложение может иметь доступ к собственным файлам, которые находятся во внешнем хранилище. Также может получить доступ к определённым общим файлам на внешнем хранилище.
Доступ к общим файлам достигается через FileProvider API или контент-провайдеры.
Для просмотра файлов через студию используйте инструмент Device File Explorer.
Внешняя карта памяти
Когда появились первые устройства на Android, то практически у всех были внешние карточки памяти, которые вставлялись в телефон. Обычно там хранили фотки, видео и свои файлы. Всё было понятно — были различные методы для доступа к файловой системе. А потом началась чехарда. В телефонах также была и собственная «внешняя» память. Она вроде как и внешняя, но вставлена на заводе и вытащить её пользователь не мог, т.е. практически внутренняя. Затем пошла мода на телефоны, у которых была только такая внутреннее-внешняя карта. Пользователи поворчали, но привыкли. Сейчас встречаются оба варианта. Как правило, у телефонов с спрятанной картой больше памяти и выше степень водонепроницаемости.
Подобные фокусы с картой породили и другую проблему — Гугл озаботился безопасностью файлов и стала думать, как осложнить жизнь разработчику. С выходом каждой новой версии системы компания то давала добро на полный доступ к карточке, то ограничивала, то давала права с ограничениями, то откатывала свои решения назад. Короче, запутались сами и запутали всех.
Попробуем немного разобраться с этим зоопарком. Но помните, что процесс путаницы продолжается.
При подготовке материала я опирался на письма некоторых читателей сайта, которые присылали свои мысли по этому поводу. Спасибо им за структуризацию материала.
Вот что я (кажется) понял, попытавшись загрузить картинку с внешней SD карточки.
External это не External
«EXTERNAL_STORAGE» называется так не потому, что это внешняя память по отношению к устройству, а потому что она выглядит как внешняя память для компьютера, если устройство подключить кабелем к компьютеру. Причём именно выглядит, потому что обмен идёт по протоколу MTP – устройство только показывает компьютеру список папок и файлов, а при необходимости открыть или скопировать файл он специально загружается на компьютер, в отличие от настоящей флешки, файлы которой становятся файлами в файловой системе самого компьютера. Обмен по MTP позволяет устройству продолжать работать, когда оно подключено к компьютеру.
Emulated это не Emulated
Сначала я пытался прочесть файл с карточки на эмуляторе (из этого так ничего и не вышло). Функция getExternalStorageDirectory() давала мне /storage/emulated/0, и я думал, что «emulated» – это потому что на эмуляторе. Но когда я подцепил реальный планшет, слово «emulated» никуда не исчезло. Я стал рыться в интернете и обнаружил, что «Emulated storage is provided by exposing a portion of internal storage through an emulation layer and has been available since Android 3.0.» – то есть это просто кусок внутренней памяти, которая путём какой-то эмуляции делается доступной для пользователя, в отличие от собственно внутренней памяти.
При этом с точки зрения системы доступная для пользователя папка называется /storage/emulated/0, а при подключении к компьютеру по USB это просто одна из двух главных папок устройства – у меня в Windows Explorer она называется Tablet. Вторая папка у меня называется Card, и это и есть настоящая внешняя карточка.
Нет стандартных средств добраться из приложения до файлов на внешней карточке. Все попытки добраться до настоящей внешней карточки делаются с помощью неких трюков. Самое интересное, что я нашел, это статья на http://futurewithdreams.blogspot.com/2014/01/get-external-sdcard-location-in-android.html — парень читает таблицу смонтированных устройств /proc/mounts, таблицу volume daemons /system/etc/vold.fstab, сравнивает их и выбирает те тома, которые оказываются съёмными (с помощью Environment.isExternalStorageRemovable()).
Оказалось, что несистемным приложениям в принципе запрещено напрямую обращаться к съёмной карточке! Похоже, что это было так всегда, но вот начиная с версии Android 6 Marshmallow написано: внешняя карточка может быть определена как Portable либо Adoptable. Adoptable – это как бы «усыновляемая» память которая может быть «adopted», то есть взята в систему (примерно как кот с улицы в дом – это тоже называется to adopt) и использована как внутренняя. Для этого ее надо особым образом отформатировать и не вынимать, иначе не факт, что система продолжит нормально работать.
Portable – это нормальная съёмная карточка, но несистемным приложениям запрещено обращаться из программ к файлам на ней! Вот что написано в https://source.android.com/devices/storage/traditional.html:
Android 6.0 supports portable storage devices which are only connected to the device for a short period of time, like USB flash drives. When a user inserts a new portable device, the platform shows a notification to let them copy or manage the contents of that device. In Android 6.0, any device that is not adopted is considered portable. Because portable storage is connected for only a short time, the platform avoids heavy operations such as media scanning. Third-party apps must go through the Storage Access Framework to interact with files on portable storage; direct access is explicitly blocked for privacy and security reasons.
Если я правильно понял, этот самый Storage Access Framework позволяет работать с документом на карточке через диалог (открыть файл/сохранить файл), а вот прочитать или записать файл на карточке непосредственно из программы невозможно.
Общий вывод – реально из программы можно работать только с файлами на предоставляемой пользователю части встроенной памяти устройства, а на съёмной карточке – нет.
Это напоминает войну Microsoft с пользователями и разработчиками по поводу диска C:, компания уговаривала не устраивать беспорядок в корне этого диска, а ещё лучше — перенести свои файлы на другой диск. Но явных запретов не было.
Состояние на текущий момент
Гугл утверждает, что с версии Android 10 Q стандартный доступ к файлам будет прекращён. Ещё в Android 4.4 появился Storage Access Framework, который и должен стать заменой для работы с файлами.
Методы Environment.getExternalStorageDirectory() и Environment.getExternalStoragePublicDirectory() признаны устаревшими и будут недоступны. Даже если они будут возвращать корректные значения, ими вы не сможете воспользоваться.
В Android 7.0 добавили исключение FileUriExposedException, чтобы разработчики перестали использовать схему file://Uri.
Можно создавать файлы в корневой папке карточки при помощи Environment.getExternalStorageDirectory(), а также папки с вложенными файлами. Если папка уже существует, то у вас не будет доступа на запись (если это не ваша папка).
Если вы что-то записали, то сможете и прочитать. Чужое читать нельзя.
Кстати, разрешения на чтение и запись файлов не требуются, а READ_EXTERNAL_STORAGE и WRITE_EXTERNAL_STORAGE объявлены устаревшими.
Другие приложения не могут получить доступ к файлам вашего приложения. Файлы, которые вы создали через getExternalFilesDir(), доступны через Storage Access Framework, кроме файлов, созданных в корне карточки (что-то я совсем запутался). Ещё можно дать доступ через FileProvider.
При подключении USB-кабеля через getExternalFilesDir(), вы можете увидеть свои файлы и папки, а также файлы и папки пользователя. При этом файлы и папки пользователя на корневой папке вы не увидите. Вам не поможет даже adb или Device File Explorer студии.
Что делать?
Пользуйтесь методами класса Context, типа getExternalFilesDir(), getExternalCacheDir(), getExternalMediaDirs(), getObbDir() и им подобными, чтобы найти место для записи.
Используйте Storage Access Framework.
Используйте MediaStore для мультимедийных файлов.
Используйте FileProvider, чтобы файлы были видимы другим приложениям через ACTION_VIEW/ACTION_SEND.
Android 10: Появился новый флаг android:allowExternalStorageSandbox=»false» и метод Environment.isExternalStorageSandboxed() для работы с песочницей. Флаг android:requestLegacyExternalStorage=»true» для приложений, которые ещё используют старую модель доступа к файлам.
Как временное решение можно добавить в блок манифеста application атрибут android:requestLegacyExternalStorage=»true», чтобы доступ к файлам был как раньше в Android 4.4-9.0.
Android 11
Если вы создаёте файловый менеджер, то ему нужны возможности для просмотра файлов. Для этого следует установить разрешение MANAGE_EXTERNAL_STORAGE или использовать атрибут android:requestLegacyExternalStorage=»true» (см. выше).
Источник
Android sdk galaxy tab файловая система
Установка SDK, знакомство с SDK, инструменты SDK.
В этой части пробежимся по верхушкам Android Software Development Kit (SDK), посмотрим, как он устроен, какие инструменты в него входят и как с этими инструментами работать. Особо углубляться в детали не будем, лишь поиграемся с отдельными программами, чтобы понять, как там всё работает.
Текст статьи (ссылки, описания, инструкции) актуален на март 2013 года.
Подготовка и установка SDK
Итак, приступим. Прежде всего вам необходимо установить java sdk, одного только java runtime для полноценной работы Android SDK недостаточно.
Напомню, что у меня везде речь идёт только о линуксе. Для начала создаём на компьютере каталог
/android , там у нас будет лежать всё нужное для работы. Я это делаю специально, чтобы все инструменты находились в одном месте и во всех последующих статьях подразумевается, что SDK установлен ровно так, как сейчас будет описано.
Дальше скачиваем в этот каталог архив SDK (ссылку берём с официального сайта) и распаковываем (скачанный файл обычно называется как-то типа adt-bundle-linux-x86-20130219.zip , он достаточно большой):
В этом архиве находится базовая часть SDK, она распаковалась в каталог с именем типа adt-bundle-linux-x86-20130219 , можете туда зайти и посмотреть, что там вообще есть, запускать пока ничего не надо. А лежит там собственно SDK и предварительно настроенная среда разработки Eclipse со всеми необходимыми плагинами. Не переименовывайте и не перемещайте никакие файлы или каталоги внутри каталога SDK, этим вы можете сломать работу Eclipse. Более подробно о файлах в SDK можно почитать на офсайте.
Начнём с Eclipse ADT, он запускается такой командой (вместо adt-bundle-linux-x86-20130219 может быть другой путь, зависит от версии скачанного SDK, дальше во всех именах файлов я его буду обозначать как adt-bundle- ):
Можете создать симлинку или ещё как-нибудь запомнить эту команду. При первом запуске вам предложат выбрать каталог для проектов, вариант по умолчанию вполне годится, можно ничего не менять. Сразу после запуска вы увидите приветсвенный экран с короткой информацией по ADT и SDK. Всё на английском, конечно, привыкайте.
Информация Дальше в этой статье и во всех последующих последующих я буду Eclipse ADT называть просто ADT (сокращение от Android Development Toold).
Из окна ADT запускаем менеджер SDK, через меню Window → Android SDK Manager. Выглядит он примерно так:
SDK устроен по модульному принципу, модули можно устанавливать и удалять по мере необходимости. Некоторые инструменты из SDK можно запускать как в диалоговом режиме с гуёвыми окошками, так и в режиме командной строки; второй режим иногда удобнее, так как позволяет очень гибко настраивать программное окружение.
По умолчанию менеджер SDK предлагает поставить модули для самых последних версий андроида. Но нам пока этого не надо, поэтому снимем все галочки (для этого можно кликнуть по ссылке Deselect all в этом окне), но выберем модуль Android SDK Platform-tools и установим его (для этого нажмём кнопку внизу справа, на ней ещё написано что-то типа Install 1 package. , соглашаемся с условиями лицензии, ну разберётесь, короче, не в первый раз ставить программы; впрочем, этот модуль может быть уже установлен, если вы только что скачали последнюю версию SDK). В этом модуле Platform tools содержатся всякие важные программы, с ними мы чуть позднее поработаем.
Менеджер SDK весьма глючен, поэтому настоятельно советую его перезагружать после каждой установки модулей.
Архитектура SDK
В своём составе SDK содержит эмулятор андроидных платформ, он построен на базе qemu и весьма нетороплив (мягко говоря). Эмулятор позволяет создавать виртуальные устройства (Android Virtual Device или AVD в терминологии SDK), на которых можно запускать и тестировать создаваемые приложения. Советую аббревиатуру AVD запомнить, она дальше будет неоднократно всплывать.
Модули SDK можно разделить на две группы: в первую входят модули с данными для разработки приложений под конкретную версию андроидной платформы, они в списке обычно обозначены как SDK Platform внутри «папки» с названием версии платформы, также в неё входят дополнительные компоненты для конкретных девайсов, например, для планшета Samsung Galaxy Tab есть отдельный модуль Android 2.2/GALAXY Tab by Samsung Electronics.; во вторую группу входят все остальные модули (примеры кода, например, или модули для поддержки гугловых сервисов, или документация по API).
Модуль SDK Platform обычно распаковывается в каталог
/android/adt-bundle- /platforms/platform-NNN , где NNN — номер версии API платформы (число). Для каждого мажорного релиза платформы выпускается новая версия API, к примеру, для Android 2.2 номер версии API — 8, для Android 2.3.1 — 9, для Android 2.3.3 — 10, для Android 4.2.2 — 17 и так далее. В модуле содержатся файлы, необходимые для запуска данной платформы в эмуляторе андроидных платформ. Сразу же скажу, что в этом модуле не установлены гугловые сервисы для работы Google Maps, к примеру. Модули с поддержкой Google API выделены отдельно и обычно называются Google APIs by Google Inc. 1 В принципе, все модули, разворачивающиеся в каталоге
/android/adt-bundle- /platforms по структуре примерно одинаковы — там содержатся файлы, из которых создаётся образ виртуального девайса AVD.
Работа с виртуальными девайсами
Чтобы создать виртуальный девайс, нужно сначала установить модуль с образами для него, например, модуль с образом «голого» андроида (модуль с именем SDK Platform любой версии API); или образ какого-нибудь девайса, например, Galaxy Tab (модуль называется Android 2.2 (API 8)/GALAXY Tab by Samsung Electronics).
Менеджер виртуальных девайсов можно запустить либо из окна Eclipse ADT (меню Window → Android Virtual Device Manager), либо из окна менеджера SDK (меню Tools → Manage AVDS. ) Выглядит этот менеджер вот так:
Чтобы создать новый девайс, жмём New. , открывается примерно такой диалог (здесь поля уже заполнены, об их значении —после скриншота):
В поле AVD Name вводим название девайса, для начала сойдёт что-нибудь типа test-111 , из списка Device выбираем «реальный» аппарат, который мы хотим эмулировать (или просто разрешение экрана), из списка Target выбираем образ на основе которого будет создан девайс. В группе Memory options указываем параметры оперативной памяти устройства. В поле Internal storage вводим размер «встроенной флешки», также можно задать размер «внешней» флешки. Когда всё сделано, жмём OK. На остальные поля в диалоге можете пока забить, значения по умолчанию сгодятся. После некоторой паузы показывается диалог со списком фич виртуального девайса и в списке должна появиться новая строчка, выделяем её и кликаем по кнопке Start. , далее на Launch. Загрузка девайса может занять немало времени, но в итоге всё загрузится как надо: на экране появляется новое окно с изображением экрана устройства, можно по экрану кликать мышкой (это аналог тыка пальцем по экрану), можно тыкать на «хардварные» кнопки сбоку.
Информация Виртуальные девайсы физически создаются в каталоге
/.android/avd , для каждого девайса с именем NNNN там создаётся каталог NNN.avd с образами дисков и памяти, а также конфиг NNN.ini . Запускать нужный образ в эмуляторе можно такой командой (в аргументе -avd указываем имя нашего девайса, в данном случае это test-111 ): %
/android/adt-bundle-[HTML_REMOVED]/tools/emulator -avd test-111
У команды emulator есть куча разнообразных полезных параметров, полный список можно посмотреть командой:
Совет Очень рекомендую добавить каталоги
/android/adt-bundle- /tools и
/android/adt-bundle- /platform-tools в переменную окружения PATH, чтобы программы из этих каталогов можно было вызывать откуда угодно без указания полного пути. Дальше я предполагаю, что вы это сделали, поэтому имена программ буду указывать без пути к каталогу, где они лежат.
Android Debug Bridge (ADB)
В SDK есть средства подключения к девайсу с андроидом, причём они работают совершенно одинаково как с реальными, так и с виртуальными железками. На прошлом шаге мы запустили виртуальный девайс в эмуляторе, давайте теперь прицепимся к нему при помощи инструментов SDK.
Первый из них называется Android Debug Bridge — это утилита командной строки, называется adb , лежит в каталоге
/android/adt-bundle- /platform-tools и позволяет выполнять отладочные работы на подключенном устройстве.
К этому моменту у нас где-то должно болтаться окно с запущенным виртуальным девайсом, вот к нему и будем подключаться. Сначала посмотрим, какие вообще девайсы нам доступны для отладки:
Итак, видим девайс с названием emulator-5554 , с ним и будем работать. Все доступные опции программы adb можно посмотреть командой adb help , она покажет длинный список всевозможных опций с достаточно подробным описанием каждой.
Давайте посмотрим системный лог нашего виртуального девайса, это делается так (выйти из него можно через стандартный хоткей Ctrl+C ):
Анализ системного лога — это один из важнейших инструментов отладки, в лог сыплются записи о любом действии, произошедшем на устройстве, туда же пишутся детальные сообщения об ошибках выполнения программ, отладочная информация. Команда adb logcat выводит на экран все записи из лога, которые хранятся на девайсе на момент вызова, после чего продолжает работать, выводя новые сообщения по мере их генерации. У команды logcat есть опции фильтрации, в которых указывается, что именно мы хотим видеть. Полное и детальное описание этой программы можно найти на девелоперском офсайте андроида.
Ещё немного поиграемся с logcat , сначала немного про формат вывода. Вот небольшой кусок лога:
У каждой записи есть приоритет, он обозначается буквой в начале сообщения, например, D означает Debug, то есть отладку; V — это наименьший возможный приоритет, от слова Verbose. Приоритет сообщения указывается программой, которая его сгенерила, всего возможно семь приоритетов (по возрастанию значимости): Verbose, Debug, Info, Warning, Error, Fatal, Silent.
Сразу за приоритетом, после символа / указывается тег сообщения, обычно это название сервиса или программы, сгенерившей сообщение. Далее в скобках указывается PID процесса, а после двоеточия собственно текст сообщения, который программа отправила в лог.
Как вы могли заметить, при выводе записей не указывается время, когда произошло событие. Это легко исправить опциями форматирования вывода:
Эта команда печатает перед каждой записью из лога время этого события с точностью до миллисекунд. Другие опции форматирования вы найдёте на странице документации adb .
Информация Если adb видит несколько девайсов, вам придётся указать, какой именно вы хотите использовать. В местных примерах я этого не делаю, так как adb достаточно умная команда и в случае всего одного девайса подцепляется к нему автоматически, однако если девайсов несколько, придётся указать, какой именно нужно использовать при помощи опции -s : adb -s emulator-5554 logcat . Также есть две полезных опции: -d позволяет подключиться к реальному подключенному девайсу, -e — к виртуальному; то есть если у вас подключено два девайса (один виртуальный, другой реальный), то командой adb -e можно подключиться к виртуальному, а командой adb -d — к реальному без ввода идентификатора.
С логом поигрались, теперь вспомним, что на девайсе работает практически полноценный линукс, а у линукса есть терминал, в который можно зайти, выполнив команду adb shell :
В этом терминале обычно доступны самые базовые линуксовые команды типа ls , pwd , mount , однако опции этих команд могут сильно отличаться от тех, к которым вы привыкли на обычной линукс-машине. Возможности терминала там также довольно скромны, многих привычных фич bash/zsh там точно не будет. Кроме того, полноценный суперюзерский доступ по умолчанию есть только на виртуальных девайсах, производители железок предпочитают давать лишь весьма ограниченный доступ (который, однако, иногда можно расширить до полноценного суперюзерского, эта процедура называется в русском андроид-сообществе рутованием девайса или получением root-доступа).
Можете полазить по файловой системе девайса, посмотреть, что и где там лежит. Вы, несомненно, обнаружите, что от привычной линуксовой машины структура файловой системы довольно сильно отличается. К примеру, нет каталога /usr , однако есть /system , причём этот каталог примонтирован с правами только для чтения, так что даже с суперюзерским доступом туда слазить не получится.
Ещё одна полезная опция прогаммы adb называется bugreport , она собирает и выводит на экран с девайса максимум информации о конфигурации (как программной, так и аппаратной):
Dalvik Debug Monitor Server (DDMS)
Ещё один крайне полезный инструмент называется Dalvik Debug Monitor Server (DDMS), эта программа находится в каталоге
/android/adt-bundle- /tools и позволяет лазить в недра работающего девайса подобно adb , тоже работает как с виртуальными, так и с реальными железками. Однако в отличие от adb , эта программа не с интерфейсом командной строки, а с полноценным графическим интерфейсом.
Однако обычно нет необходимости запускать DDMS вручную, поскольку программа встроена в Eclipse ADT и оттуда её можно открыть через меню Window → Open Perspective → DDMS.
Если же вы решите запустить ddms вручную, то увидите такое окно:
Через DDMS можно смотреть системный лог девайса, изучать работающие процессы, ходить по файловой системе. Одна из самых полезных фич программы — снятие скриншотов с девайса, делается это через меню Device → Screen Capture или хоткеем Ctrl+S .
Вводный обзор средств SDK на этом и закончим.
Ссылки
- Developer Guide/Tools/adb — полная документация по программе adb
- Using DDMS — подробное описание DDMS на девелоперском офсайте андроида.
Читайте в следующей части: установка и настройка eclipse для нашего программного окружения
Содержимое модуля Android 2.2 (API 8)/Google APIs by Google Inc. разворачивается не в каталоге platforms , а в каталоге
/android/android-sdk-linux/add-ons/addon-google_apis-google_inc_-8 . С другими аддонами — для эмуляторов реальных устройств, например — аналогично. ↩
Комментарии
Модули SDK можно разделить на две группы: в первую входят модули с данными для разработки приложений под конкретную версию андроидной платформы, они в списке обычно обозначены как SDK Platform внутри «папки» с названием версии платформы, также в неё входят дополнительные компоненты для конкретных девайсов, например, для планшета Samsung Galaxy Tab есть отдельный модуль Android 2.2/GALAXY Tab by Samsung Electronics.
Я не смог найти у себя дополнительные компоненты для конкретных девайсов, подскажите, пожалуйста, откуда и как их установить
Они там же в списке показываются, нужно просто поискать. Ну, и не для всех девайсов там есть компоненты, конечно.
у меня на команду % adb devices пишет adb не является командой
Значит, программа из текущего каталога не видна. Можно по полному пути вызывать команду, например, типа
/android/adt-bundle- /platform-tools/adb , вместо подставить нужное значение.
Источник