Intel для разработчиков Android*: Отладка в ОС Android

Процесс выявления неполадок и ошибок в коде приложений для ОС Android* весьма схож и для архитектуры Intel® Atom™, и для архитектуры ARM*. В этой статье мы сфокусируем наше внимание на методиках отладки приложений для Android* на платформах с архитектурой Intel.

1. Предварительные требования

В этой части описывается процесс установки драйвера Intel® USB, необходимого для поддержки удаленной отладки приложений на устройствах с Intel® Atom™ и ОС Android*.

Кроме того, здесь описывается системный образ Intel® Atom™ x86 для эмулятора Android. Если физическое целевое устройство отсутствует, то можно работать с виртуальным устройством, эмулированным с помощью Android* SDK.

1.1. Драйвер Intel® USB для устройств Android

Сначала рассмотрим пакет драйвера Intel® USB для Android, с помощью которого можно подключить устройство на базе процессора Intel Atom™ к компьютеру, использующемуся для разработки. В первом примере предположим, что на компьютере установлена ОС Windows*. Аналогичные принципы действуют в Linux* и OS X*.

  • Загрузите пакет драйвера по адресу http://www.intel.com/software/android

  • Запустите установщик и разрешите установку, если отобразится окно контроля учетных записей.

  • Появится следующее окно (рис. 1). Для продолжения нажмите кнопку Next. Если установщик обнаружит старую версию драйвера, разрешите ее удаление.

Рисунок 1. Начальный экран установки драйвера USB

  • Ознакомьтесь с условиями лицензионного соглашения и примите его условия.
  • Будет предложено выбрать компоненты. Для продолжения нажмите кнопку Next
  • Выберите путь установки и нажмите Install.
  • Начнется установка драйверов USB для Android. Это может занять несколько минут (рис. 2).

Рисунок 2. Экран хода установки драйвера USB

1. После завершения установки нажмите кнопку ОК в диалоговом окне и кнопку Finish в окне мастера.

1.2. Установка системного образа Intel® Atom™ x86 для эмулятора Android

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

Move or Protect or Flag

Close

Для установки дополнительного системного образа для эмулятора Android * x86 требуется Android SDK. Инструкции по установке Android SDK приведены на веб-сайте разработчиков Android (http://developer.android.com/sdk/installing.html). Дополнительный образ системы Intel® Atom™ для эмулятора Android x86 можно загрузить и установить с помощью Android SDK Manager.

Для этого выполните следующие действия:

1. Запустите Android SDK Manager.

2. В разделе Packages → Android 4.x.x (API 1x), поставьте флажок Intel Atom x86 System Image by Intel Corporation.

3. Затем нажмите кнопку Install Package, как показано на рис. 3.

Примечание. Можно установить несколько пакетов в зависимости от того, какой вариант был выбран вами или программой Android SDK Manager.

Рисунок 3. Выбор Android SDK Manager для системного образа x86

1. Прочитайте лицензионное соглашение с корпорацией Intel. Если вы принимаете условия соглашения, выберите Accept и нажмите кнопку Install, как показано на рис. 4.

Рисунок 4. Android SDK Manager — лицензионное соглашнеие

1. Android SDK Manager начнет загрузку и установку дополнения в соответствующую папку Android SDK (/add-ons/). Это может занять несколько минут в зависимости от скорости подключения к Интернету.

2.  Выберите Manage AVDs в меню Tools (рис. 5).

Рисунок 5. Android SDK Manager — управление виртуальными устройствами Android

1. Откроется Android Virtual Device Manager. Нажмите кнопку New (рис. 6).

Рисунок 6. Добавление нового виртуального устройства Android*

1. В поле Name введите имя виртуального устройства. Примечание. Имя не должно содержать пробелы.

2. Выберите Intel Atomx86 System Image (Intel Corporation) – API Level 10 в раскрывающемся списке Target (рис. 7).

Рисунок 7. Выбор системного образа Intel Atom x86 в качестве целевого виртуального устройства

1. Задайте необходимые настройки и нажмите кнопку Create AVD:

2. В окне Android Virtual Device Manager появится новое виртуальное устройство. Выберите его и нажмите кнопку Start, как показано на рис. 8.

Рисунок 8. Запуск виртуального устройства Android*

1. Откроется диалоговое окно с параметрами запуска. Укажите размер экрана и разрешающую способность в точках на дюйм (dpi), так как эмулятор не всегда правильно определяет их. Нажмите кнопку Launch (рис. 9).

Рисунок 9. Параметры запуска виртуального устройства

1. Через несколько секунд эмулятор запустится и отобразит стартовый экран (рис. 10).

Рисунок 10. Эмуляция устройства Android * на базе архитектуры Intel® в AVD*

1.3.   Отладка приложений с помощью Android Debug Bridge

Android Debug Bridge (ADB) — это инструмент для обмена данными между отладчиком на компьютере (обычно это GDB*, DDMS* (Dalvik* Debug Monitor Server) или ADT) и образом Android на целевом устройстве. Целевой образ может работать как на эмулируемом виртуальном устройстве, так и на физическом устройстве, обмен данными с которым осуществляется с помощью кабеля USB-OTG или адаптера USB-Ethernet. ADB является связующим элементом, дающим возможность отлаживать приложения Android.

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

Настройка Android Debug Bridge для удаленной отладки приложений на платформе Intel Atom практически не отличается от отладки другой архитектуры.

1.4.  Настройка ADB

Прежде всего необходимо установить на компьютере Android SDK, в том числе ADB. Инструкции см. по адресу http://developer.android.com/sdk/installing.html.

Если целевой образ запущен на физическом устройстве, то нужно включить поддержку USB-OTG или USB-Ethernet. Для поддержки USB-Ethernet требуется изменение конфигурации ядра и повторная сборка. OEM-поставщик предоставит необходимую информацию по этой процедуре.

Стандартный способ удаленной отладки приложений предусматривает использование интерфейса USB-OTG, которым оснащено большинство устройств с Android. Установка достаточно подробно описана на веб-сайте разработчиков Android: http://developer.android.com/guide/developing/device.html:

Вот основные действия

1. Объявите для приложения свойство «debuggable» в манифесте Android.

2. Включите на устройстве отладку через USB.

3. On the device, go to На устройстве откройте > Applications > Development и установите флажок USB debugging (в версии Android 4.x.x он находится в меню Settings > Developer options).

4. Настройте систему для обнаружения устройства.

      В Windows нужно установить драйвер USB для ADB — см. предварительные требования.

      При использовании Ubuntu* Linux нужно добавить файл правил udev, содержащий конфигурацию USB для каждого типа устройств, которые следует использовать при разработке. В файле правил каждый изготовитель устройств обозначается уникальным идентификатором с помощью свойства {idVendor}. Список идентификаторов изготовителей см. по адресу http://developer.android.com/tools
/device.html#VendorIds.

      Чтобы включить обнаружение устройств в Ubuntu Linux, войдите в систему с правами root и создайте файл:

/etc/udev/rules.d/51-android.rules

      Добавьте в файл каждого изготовителя, используя следующий формат:

SUBSYSTEM=="usb", ATTR{idVendor}=="????", MODE="0666", GROUP="plugdev"

Назначение MODE указывает разрешения на чтение и запись, а GROUP определяет, какой группе Unix принадлежит узел устройства.

      Выполните:

chmod a+r /etc/udev/rules.d/51-android.rules

      При подключении через USB можно узнать, подключено ли устройство, выполнив команду ADB devices из папки platform-tools/Если устройство подключено, то на экране будет показано имя устройства со словом «device».

При загруженной ОС Android подключите кабель USB-OTG к порту (мини-USB типа «b») на устройстве, а другой разъем кабеля — к порту (USB типа «A») на компьютере.

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

$ adb devices

* daemon not running. starting it now *

* daemon started successfully *

List of devices attached

0123456789ABCDEF     device

Замечание: Чтобы узнать, какое имя устройства назначено этому подключению на компьютере с Linux, можно выполнить dmesg для поиска адреса "usb-storage: device found at <num>", а затем отобразить список командой "ls -l /dev/bus/usb/*" listing to find that number.

1.5.               ADB в Windows

Загрузите и установите Eclipse Classic по адресу http://www.eclipse.org/downloads/.

Загрузите пакет Android SDK для Windows по адресу http://developer.android.com/sdk/index.html (android-sdk_r18-windows.zip, or installer_r18-windows.exe).

После установки Android SDK файл adb.exe будет находиться в папке <install-dir>\android-sdk\platform-tools.

1.6.               Передача данных между сервером и клиентом в ADB

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

      Клиент, запускаемый на компьютере разработчика. Можно вызвать клиент из оболочки с помощью команды ADB. Другие средства Android, такие как подключаемый модуль ADT и DDMS, также создают клиенты ADB.

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

      Демон, запускаемый на каждом экземпляре эмулятора или на каждом устройстве в виде фонового процесса.

При запуске клиента ADB клиент сначала проверяет, запущен ли уже процесс сервера ADB. Если нет, то клиент запускает процесс сервера. Сервер после запуска подключается к локальному TCP-порту 5037 и прослушивает команды, отправленные клиентами ADB. Все клиенты ADB используют порт 5037 для обмена данными с сервером ADB.

Затем сервер устанавливает подключения ко всем запущенным эмуляторам и устройствам. Для обнаружения эмуляторов и устройств сервер проверяет все порты с нечетными номерами в диапазоне от 5555 до 5585 (этот диапазон используется эмуляторами и устройствами). При обнаружении демона ADB устанавливается подключение к этому порту. Обратите внимание, что каждый эмулятор или устройство получает пару портов с последовательными номерами: порт с четным номером для подключения консоли и порт с нечетным номером для подключения ADB. Например:

 Emulator 1, console: 5554

 Emulator 1, adb: 5555

 Emulator 2, console: 5556

 Emulator 2, adb: 5557 ...

Как показано выше, к ADB на порту 5555 подключен тот экземпляр эмулятора, консоль которого прослушивает порт 5554.

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

1.7.  Запуск ADB

Введите «adb shell». Символ # указывает, что подключение успешно установлено.

$ adb shell

1.8.               Основные команды ADB для устройств

Перечисленные ниже команды помогают передать отлаживаемое приложение на целевое устройство или в эмулятор с помощью командной строки. Это может быть удобно, особенно если отсутствует подключение терминала ssh.

  adb push <local> <remote>    - копирование файла или папки на устройство

  adb pull <remote> [<local>]  - копирование файла или папки с устройства

  adb sync [ <directory> ]     - копировать с компьютера на устройство только при наличии изменений

                                 (параметр -l — отобразить список, но не копировать)

                                 (см. 'adb help all')

  adb shell                    - интерактивный запуск удаленной оболочки

  adb shell <command>          - выполнить удаленную команду оболочки

  adb emu <command>            - выполнить команду консоли эмулятора

  adb logcat [ <filter-spec> ] - просмотр журнала устройства

  adb forward <local> <remote> - перенаправлять подключения сокета

                                 Параметры перенаправления:

                                   tcp:<port>

                                   localabstract:<unix domain socket

     name>

                                   localreserved:<unix domain socket

                       name>

localfilesystem:<unix domain socket name>

                                   dev:<character device name>

                                   jdwp:<process pid> (только удаленный)

  adb jdwp                     - показать список всех PID процессов с JDWP

     transport

  adb install [-l] [-r] [-s] <file> - передать файл пакета на устройство и установить его

                                 ('-l' блокировка пересылки приложения)

                                 ('-r' переустановить приложение, сохранив его данные)

                                 ('-s' установить на карту памяти SD, а не во внутреннюю флэш-память)

  adb uninstall [-k] <package> - удалить пакет приложения с устройства

                                 ('-k' сохранить папки данных и кэша)

Дополнительные сведения об установке и использовании ADB см. по адресу http://developer.android.com/guide/developing/
tools/adb.html.

1.9.               Использование подключаемого модуля средств отладки Android для Eclipse

Для устройств на базе архитектуры Intel процесс установки не имеет существенных отличий от описанного по адресу http://developer.android.com/sdk/eclipse-adt.html#installing.

Подключаемый модуль средств отладки Android (ADT) обеспечивает все возможности интегрированной отладки приложений в среде Eclipse для эмуляторов и устройств с архитектурой Intel. Поддерживается два представления отладки с различными наборами функций.

Можно переключаться между ними по мере необходимости; каждое из них обладает определенными преимуществами.

1.10.  Представление Debug в Eclipse

Представление отладки в Eclipse предоставляет доступ к следующим вкладкам:

      Debug - отображение уже отлаженных и отлаживаемых в настоящий момент приложений Android и запущенных в настоящий момент потоков

      Variables - когда заданы точки останова, отображение значений переменных при выполнении кода

      Breakpoints - список точке останова в коде приложения

      LogCat - просмотр сообщений в журнале системы в реальном времени. Вкладка LogCat также доступна в представлении DDMS.

Чтобы открыть представление Debug Perspective, щелкните Window > Open Perspective > Debug. Дополнительные сведения см. в документации к отладчику Eclipse.

1.11.  Представление DDMS

Представление DDMS в Eclipse обеспечивает доступ к всем функциям DDMS из среды разработки Eclipse. Доступны следующие разделы DDMS:

Devices           - список физических и виртуальных устройств, подключенных к ADB.

Emulator Control  - выполнение различных действий с устройством.

LogCat            - просмотр сообщений в журнале системы в реальном времени.

Threads           - отображение запущенных в настоящее время потоков в виртуальной машине.

Heap              - использование кучи виртуальной машиной.

Allocation Tracker - просмотр выделения памяти объектам.

File Explorer     - работа с файловой системой устройства.

1.12.  Среда запуска приложений для отладки

При отладке приложения Android для архитектуры Intel разница заключается в настройке отладки целевого устройства.

Чтобы выбрать устройство с помощью диспетчера Android Virtual Device Manager, входящего в состав Android SDK, откройте меню Window > AVD Manager в Eclipse. Необходимо выбрать Intel Atom (x86) в качестве целевого EABI для образа ОС и эмуляции устройства (рис. 11).

Рисунок 11. Выбор устройства с процессором Intel® Atom™ в Android Virtual Device Manager

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

В остальном отладка приложения Android для архитектуры Intel практически не отличается от отладки приложений Android для архитектуры ARM.

2.    Intel® Hardware Accelerated Execution Manager

Intel Hardware Accelerated Execution Manager (Intel® HAXM) — это ядро аппаратной виртуализации (гипервизор), основанное на технологии виртуализации Intel (Intel VT) и ускоряющее разработку приложений для Android. В сочетании с образами эмулятора Android x86, предоставляемыми корпорацией Intel, и официальным выпуском Android SDK Manager решение Intel HAXM обеспечивает более быструю эмуляцию Android на системах с поддержкой Intel VT.

Системный образ эмулятора Android* 4.0.4 (Ice Cream Sandwich) с архитектурой x86 позволяет запускать эмулятор Android на компьютере, используемом для разработки. При использовании Android SDK можно тестировать приложения на виртуальном устройстве Android с архитектурой Intel, пользуясь всеми возможностями архитектуры Intel и технологии Intel VT.

Для установки образа эмулятора можно использовать Android SDK Manager.

Установка Intel HAXM возможна с помощью Android SDK Manager (рис. 12). Для работы Intel HAXM необходим Android SDK версии 17 или более поздней. Дополнительная информация приведена на веб-сайте разработчиков Android (http://developer.android.com/sdk/).

Рисунок 12. Загрузка Intel® Hardware Accelerated Execution Manager

Intel HAXM выпускается для платформ Linux, Windows и iOS. В примере описывается установка на 64-разрядную версию Ubuntu, поскольку это основная платформа для сборки Android, проверенная и поддерживаемая корпорацией Google.

Ниже описываются действия по установке, включению KVM на платформе Ubuntu и запуск эмулятора Intel Android x86 с поддержкой аппаратной виртуализации Intel. AVD с использованием Intel HAXM работает значительно быстрее и с меньшими задержками, чем без гипервизора.

2.1.               Установка KVM

1. Чтобы узнать, поддерживает ли процессор аппаратную виртуализацию, просмотрите выходные данные следующей команды:

$ egrep -c '(vmx|svm)' /proc/cpuinfo

Если эта команда возвращает 0, то ЦП не поддерживает аппаратную виртуализацию.

2. Установите средство проверки ЦП:

$ sudo apt-get install cpu-checker

3. Теперь можно узнать, поддерживает ли процессор KVM:

$kvm-ok

a. Если появится текст:

"INFO: Your CPU supports KVM extensions
INFO: /dev/kvm exists
KVM acceleration can be used"

то виртуальная машина сможет работать быстрее с расширениями KVM.

b. Если появится текст:

"INFO: KVM is disabled by your BIOS
HINT: Enter your BIOS setup and enable Virtualization Technology (VT),
and then hard poweroff/poweron your system
KVM acceleration can NOT be used"

 

то необходимо включить Intel VT в BIOS компьютера.

2.2.               Использование 64-разрядного ядра

Запуск 64-разрядного ядра в операционной системе физического компьютера рекомендуется, но не требуется. 64-разрядное ядро необходимо, чтобы предоставлять виртуальным машинам больше 2 ГБ ОЗУ. 32-разрядное ядро позволяет выделить одной виртуальной машине не более 2 ГБ ОЗУ. Кроме того, в 64-разрядной системе могут размещаться как 32-разрядные, так и 64-разрядные гостевые системы. В 32-разрядной системе могут размещаться только 32-разрядные гостевые системы.

1. Чтобы узнать, поддерживает ли процессор 64-разрядную архитектуру, выполните команду:

$ egrep -c ' lm ' /proc/cpuinfo

Если выводится 0, то процессор не является 64-разрядным. Если выводится 1 или больше, то процессор является 64-разрядным. Примечание. lm означает «Long Mode», то есть 64-разрядный ЦП.

2. Чтобы узнать, является ли запущенное ядро 64-разрядным, выполните команду:

$ uname -m

Значение x86_64 будет означать, что выполняется 64-разрядное ядро. Значения i386, i486, i586 или i686 означают 32-разрядное ядро.

2.3.               Установка KVM

Для установки KVM выполните следующие действия.

1. В Ubuntu 10.04 или более поздней версии:

$ sudo apt-get install qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils

Можно пропустить запрос «Postfix Configuration», показанный на рис. 13, выбрав «No Configuration»

Рисунок 13. Параметр «Postfix Configuration» при установке KVM:

 

1. Теперь добавьте свою учетную запись имя_пользователя в группы kvm и libvirtd:

$ sudo adduser your_user_name kvm
$ sudo adduser your_user_name libvirtd

После установки потребуется заново войти в систему, чтобы ваша учетная запись стала активным членом групп kvm и libvirtd. Члены этой группы могут запускать виртуальные машины.

2. Чтобы проверить успешность установки, можно использовать команду:

$ sudo virsh -c qemu:///system list

2.4.               Запуск виртуального устройства Android

Запустить эмулятор Android для x86 Intel (рис. 14) можно с помощью следующей команды:

$ <SDK directory>/tools/emulator-x86 -avd Your_AVD_Name -qemu -m 2047 -enable-kvm

где Your_AVD_Name - выбранное вами имя, параметр '-qemu' предоставляет доступ к qemu, а параметр '-m' указывает объем памяти для эмулируемой системы Android (т.е. для гостевой системы). Если задать слишком малое значение памяти, может снизиться производительность из-за частой работы с файлом подкачки.

Рисунок 14. AVD c Android в Intel® Architecture Emulation

2.5.               Использование AVD Manager в среде Eclipse для запуска виртуального устройства

Следующие действия рекомендуются для отладки приложений с помощью AVD в среде Eclipse:

1. В Eclipse щелкните папку с проектом Android и выберите Run > Run Configurations.

2. В левой части диалогового окна Run Configurations выберите конфигурацию запуска проекта Android или создайте новую конфигурацию.

3. Перейдите на вкладку Target tab.

4. Выберите созданное ранее виртуальное устройство с архитектурой Intel.

5. В поле Additional Emulator Command Line Options введите:

-qemu -m 2047 -enable-kvm

6. Запустите проект Android с помощью этой конфигурации запуска.

2.6.    Запуск Android в Oracle* VirtualBox*

Запуск полного образа ОС Android на настольном ПК в виртуальной машине Oracle VirtualBox можно использовать в качестве альтернативы KVM и QEMU на платформе Windows, особенно если разработчикам требуется создавать и отлаживать встроенный код Android.

В этом разделе описывается:

      Сборка установщика VirtualBox Android 4.0.x для x86 из официального образа VirtualBox Google x86 vbox-x86-eng (входит в состав структуры исходного кода Android 4.0.1);

      Использование ядра Linux 2.6, предоставленного корпорацией Intel, для добавления определенных функций в VirtualBox,

      Использование installer.vdi для установки Android ICS 4.0 в VirtualBox.

В дополнение к эмулятору виртуальных устройств Google, поддерживаемому технологией Intel HAXM, образ VirtualBox Android для x86 работает в виртуальной среде с настоящей архитектурой Intel. Это быстрое и мощное средство для быстрой разработки и тестирования приложений. Загрузка Android 4.0.x в VirtualBox на типовом компьютере с процессором Intel® Core™ i5 занимает около 20 секунд. Решение VirtualBox популярно среди разработчиков Android благодаря своей скорости, производительности и удобству, особенно при разработке решений для платформ с архитектурой Intel. На рынке пока доступно относительно немного планшетов и смартфонов Android с процессорами Intel, поэтому удобнее использовать для разработки виртуальную среду, а не подключать физическое устройство с помощью USB. Это особенно удобно, если и компьютер, на котором ведется разработка, и устройство Android оснащены процессорами с архитектурой Intel.

2.7.               Образы сборки Google x86 VirtualBox для Android 4.x

Если вы уже пользовались хранилищем исходного кода Google Android 4.0.x, то, вероятно, заметили, что Google выпускает версию образа VirtualBox для архитектуры x86 под названием vbox_x86-eng. С помощью команды lunch перед началом сборки можно отобразить первые три целевых образа, предоставляемые для Android 4.0.x:

$ lunch

1. full-eng
2. full_x86-eng
3. vbox_x86-eng

В целевом образе vbox_x86-eng (№3) разработчики приложений и систем могут создать пакеты android_disk.vdi и android installer.vdi. Эти пакеты можно использовать для запуска Android 4.x в среде VirtualBox для разработки приложений и интеграции систем на платформах Windows, Linux и OS X*.

2.7.1.  Загрузка структуры исходного кода и установка репозитория

Для установки, инициализации и настройки репозитория выполните следующие действия (подробные сведения см. по адресу http://source.android.com/source/downloading.html):

$ mkdir ~/bin
$ PATH=~/bin:$PATH
$ curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo
$ chmod a+x ~/bin/repo
$ mkdir ANDROID_TOP_PATH
$ cd ANDROID_TOP_PATH

Для получения списка доступных ветвей (из корневой папки извлечения в репозиторий Android) используйте команду:

$ git --git-dir .repo/manifests/.git/ branch -a

Run Выполните команду repo init для получения новейшего списка доступных веток репозитория с самыми последними обновлениями:

$ repo init -u https://android.googlesource.com/platform/manifest -b android-4.0.1_r1

 

Для использования средства проверки кода Gerrit* потребуется адрес электронной почты, подключенный к зарегистрированной учетной записи Google. Убедитесь, что это действующий адрес, с помощью которого можно получать сообщения. Вашей сборке будет назначена версия ядра и номер сборки, эта информация будет отображаться на странице Android/settings/about phone/.

После успешной инициализации появится сообщение об инициализации Repo в рабочей папке. Теперь внутри папки клиента должна находиться папка .repo, в которой будут храниться файлы, например, манифест.

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

$ repo sync

По умолчанию доступ к исходному коду Android является анонимным. Во избежание перегрузки серверов каждому IP-адресу выделяется определенная квота.

2.7.2. Сборка собственного ядра с поддержкой мыши

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

1. Загрузите дополнительный образ для эмулятора Android * x86 с помощью Android SDK Manager.

2. Создайте новую папку и распакуйте в нее kernel_sdk_x86.tar.gz, чтобы создать папку в структуре кода ядра.

3. Перейдите в папку, где находятся файлы ядра.

Теперь нужно изменить конфигурацию, чтобы она соответствовала оборудованию, используемому в качестве системы VirtualBox, а затем заново выполнить сборку. Графический интерфейс menuconfig позволяет сделать это достаточно удобно:

$ cp ANDROID_TOP_PATH/your_kernel_path/arch/x86/configs/vbox_defconfig  .config

$ make CC=gcc-4.4 CXX=g++-4.4 ARCH=x86 menuconfig

Компиляция и загрузка может занять несколько минут.

После этого используйте:

  • Клавиши со стрелками вверх и вниз для навигации,
  • Клавишу «Ввод» для выбора (или развертывания),
  • Клавишу «y» или пробел для добавления компонента.

Чтобы включить поддержку мыши, перейдите в раздел: Device Driver > Input Device Support > Mice.

Примечание: Приложение menuconfig можно использовать для проверки доступности всех компонентов, необходимых для поддержки приложения или интеграции системы. Для разработчиков приложений также важно протестировать работу приложения на стандартных сборках Android. Только такой подход может гарантировать наибольшую совместимость с устройствами Android различных производителей.

После внесения необходимых изменений в конфигурация ядра, наконец, можно его скомпилировать. Компиляция проходит довольно быстро, поэтому я использовал небольшое значение параметра «-j». Помните, что если не указать параметры CC и CCX, то в данном случае компиляция завершится преждевременно без явной ошибки, поскольку будет использоваться версия 4.6.

$ make CC=gcc-4.4 CXX=g++-4.4 ARCH=x86 –j8

Параметр –j указывает количество доступных ядер для компиляции. В приведенном выше примере предполагается использовать четырехъядерной системы с технологией гиперпоточности Intel.

После успешного завершения сборки последняя строка журнала сборки будет выглядеть так

Kernel: arch/x86/boot/bzImage is ready

2.7.1.  Добавление исправленного ядра

Образ ядра bzImage необходимо переименовать в kernel-vbox и скопировать в папку /ANDROID_TOP_PATH/prebuilt/android-x86/kernel/kernel-vbox:

$ cp /ANDROID_TOP_PATH/kernel/arch/x86/boot/bzImage   /ANDROID_TOP_PATH/prebuilt/android-x86/kernel/kernel-vbox

2.7.2.  Ускорение компиляции с помощью CCACHE

Можно существенно ускорить последующие сеансы компиляции с помощью кэша компилятора. Чтобы выделить кэш объемом 50 ГБ, выполните следующие действия:

1. Установите программу CCcache и создайте папку для ccache

$ sudo apt-get install ccache
$ sudo mkdir /ANDROID_TOP_PATH/ccache
$ sudo chown $LOGNAME  /ANDROID_TOP_PATH/ccache

2. Настройте переменные среды для поддержки ccache, изменив ~/.bashrc

$ sudo gedit ~/.bashrc

3. Добавьте:

export CCACHE_DIR=/ANDROID_TOP_PATH/ccache
export USE_CCACHE=1

4. Задайте размер ccache.

$ ccache -F 100000
$ ccache -M 50G

2.7.3.  Сборка Android 4.0.x с новым ядром

Настройка среды:

$ /ANDROID_TOP_PATH/> source build/envsetup.sh

Для версии ICS 4.0.1 появится:

including device/samsung/maguro/vendorsetup.sh
including device/samsung/tuna/vendorsetup.sh
including device/ti/panda/vendorsetup.sh
including sdk/bash_completion/adb.bash

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

$ lunch

Затем нужно выбрать нужный образ из списка:
1. full-eng
2. full_x86-eng
3. vbox_x86-eng
4. full_maguro-userdebug
5. full_tuna-userdebug
6. full_panda-eng

Which would you like? [full-eng]   

Примечание: Необходимо выбрать 3. vbox_x86-eng.

PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=4.0.1
TARGET_PRODUCT=vbox_x86
TARGET_BUILD_VARIANT=eng
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=x86
TARGET_ARCH_VARIANT=x86
HOST_ARCH=x86 HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=ITL41D

Запустите команду make

$ make -j8

2.8.               Сборка диска VirtualBox и установщика Android

Теперь нужно собрать Android_disk.vdi и installer_vdi:

$ make android_disk_vdi  installer_vdi  -j8

При успешной сборке в журнале сборки появится следующий текст:

Done with VirtualBox bootable disk image -[ out/target/product/vbox_x86/android_disk.vdi ]-
Done with VirtualBox bootable installer image -[ out/target/product/vbox_x86/installer.vdi ]-

 

Создав android_disk.vdi, можно выбратьNew > Create New Virtual Machine в VirtualBox и использовать android_disk.vdi в качестве существующего образа диска виртуальной машины, на которой теперь будет автоматически загружаться Android 4.0.x.

Настройка параметров запуска VirtualBox* весьма проста. Перейдите в меню Settings > About this phone чтобы просмотреть данные о сборке (рис. 15):

 

Рисунок 15. Информация о сборке Android 4.0.x в Oracle VirtualBox

2.9.               Использование диска установщика Android для создания крупного виртуального раздела

Даже если размер файлов в VirtualBox расширен до 550 МБ, этого недостаточно для загрузки приложений для тестирования. Необходимо установить Android на раздел гораздо большего размера (желательно свыше 4 ГБ).

Выберите Machine > New в меню VirtualBox и используйте мастер создания виртуальных машин, чтобы создать крупный диск в разделе конфигурации контроллера IDE.

Затем в меню Settings > Storage виртуальной машины добавьте файл installer.vdi в качестве диска Primary IDE Slave, как показано на рис. 16. Теперь можно приступить к установке Android на более крупный диск, который был только что создан.

Рисунок 16. Настройка параметров хранения данных для виртуальной машины

1. Запустите эмулятор

2. Нажмите клавишу F12, чтобы войти в меню загрузки в BIOS. Выберите загрузку со второго диска

3. Используйте grub, чтобы выбрать вариант установки: 2. Boot from Primary Slave (рис. 17)

Рисунок 17. Загрузка образа установщика в VirtualBox

When you see “При появлении надписи «Done processing installer config» введите команду ”, type "reboot"

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

$ installer

После перезагрузки можно увидеть, что Android работает с более крупного диска, поэтому можно безопасно удалить installer.vdi из ветви Storage в разделе IDE Controller settings.

2.10.               Последовательный порт

По умолчанию на виртуальной машине включена поддержка последовательного порта. Тем не менее, нужно инициализировать и настроить порт COM1 перед его использованием. Выполните следующие инструкции, чтобы создать в VirtualBox именованный поток .vbox_pipe в домашней папке. В командной строке введите:

$ VBoxManage modifyvm Android --uart1 0x03f8 4

$ VBoxManage modifyvm Android --uartmode1 server /home/user/.vbox_pipe

 

Также можно использовать интерфейс VirtualBox: на вкладке SSerial Ports в меню Virtual Machine Settings включите COM1 как «Host Pipe» и выберите Create Pipe для /home/user/.vbox_pipe.

Для подключения используйте команду:

$ socat unix-client:$HOME/.vbox_pipe stdout

Примечание: Переменные среды (такие как $HOME) могут не поддерживаться в VirtualBox, поэтому придется явным образом указать полный путь, например /home/user/.vbox_pipe.

2.11.  Ethernet

Порт Ethernet (eth0) включен в образе для DHCP. Для подключения к нему через ADB потребуется найти назначенный DHCP-адрес.

Если используется мостовое подключение Ethernet, получить адрес можно либо из командной строки оболочки из последовательного порта, либо с помощью меню Developer Tools > Terminal Emulator с помощью команды:

$ netcfg

Если используется только хост-адаптер vboxnet0, следует использовать адрес 192.168.56.101.

2.12.  Заключительные заметки

Итак, теперь образ VirtualBox с Android 4.0.x полностью собран на основе официального образа Google vbox-x86 (рис. 18).

Рисунок 18. ОС Android полностью загружена на виртуальной машине VirtualBox

3.    Отладка с помощью GDB, the GNU Project Debugger

Android NDK включает GDB, отладчик GNU, позволяющий запускать, приостанавливать, изучать и изменять программы. На устройствах Android и на встроенных устройствах GDB настраивается в клиент-серверном режиме. Программа работает на устройстве в качестве сервера и удаленного клиента. Рабочая станция разработчика подключается к нему и отправляет команды отладки, как для локального приложения. Сам по себе отладчик GDB является программой командной строки. Сначала рассмотрим базовую модель его использования, а потом перейдем к интеграции в Eclipse CDT.

При отладке с помощью GDB обработкой передачи данных отладки занимается gdbserver на устройстве, но можно использовать и драйвер USB-Ethernet с ADB для обработки транспортного уровня передачи данных, по которому gdbserver обменивается данными по протоколу TCP/IP с GDB на компьютере разработчика.

Существует приложение gdbclient, настраивающее среду обмена данными отладки и запускающее gdbserver на отлаживаемом устройстве.

Использование: gdbclient EXECUTABLE :PORT [PROG_PATH]

EXECUTABLE  имя исполняемого файла (по умолчанию: app_process)

PORT        порт подключения (по умолчанию:1234)

PROG_PATH   полный путь к исполняемому файлу в целевой системе (например: ex /system/bin/mediaserver)

Если параметр PROG_PATH задан, gdclient пытается запустить gdbserver и присоединить его к запущенному PROG_PATH.

Для запуска gdbserver явным образом можно использовать следующую команду:

# gdbserver :1234 --attach 269

Attached; pid = 269

Listening on port 1234

 

Приведенные ниже пошаговые инструкции по запуску сеанса отладки показывают, что ADB по-прежнему используется для передачи данных отладки, даже если отладка выполняется с помощью GDB, а не ADT или DDMS. Предположим, что используется порт 1234.

Запустите процесс:

gdbserver :1234 /system/bin/executable

или подключитесь к существующему процессу.

gdbserver :1234 --attach pid

Перенаправьте локальный порт 1234 рабочей станции на устройство с помощью adb:

adb forward tcp:1234 tcp:1234

Запустите особую версию gdb, находящуюся в области prebuilt структуры исходного кода:

prebuilt/Linux/toolchain-eabi-4.x.x/bin/i686-android-linux-gdb (Linux)

prebuilt/darwin-x86/toolchain-eabi-4.x.x/bin/i686-android-linux-gdb (Darwin)

Если особую версию GDB не удается найти, выполните команду find prebuilt –name i686-android-linux-gdbin в структуре исходного кода, чтобы найти и запустить последнюю версию. Необходимо скопировать исполняемый файл в папку symbols, а не в главную папку Android, поскольку файл в главной папке очищен от символьной информации.

В GDB укажите расположение общих библиотек для загрузки:

set solib-absolute-prefix /absolute-source-path/out/target/product/product-name/symbols

set solib-search-path /absolute-source-path/out/target/product/product-name/symbols/system/lib

Следите за правильностью указываемых папок: GDB может не выдать сообщение в случае ошибки. Подключитесь к устройству с помощью команды GDB:

(gdb) target remote :1234

Параметр :1234 указывает на подключение к порту 1234 локального компьютера, соединенному с устройством с помощью ADB.

Теперь можно начать отладку встроенного кода C/C++ на платформе Android с помощью GDB привычным образом. При наличии Eclipse (эта среда, по всей видимости, уже установлена, если вы используете Android SDK для разработки приложений на базе Dalvik*/Java*) можно использовать интеграцию Eclipse и GDB для прямого добавления точек останова и анализа программы.

В Eclipse можно с легкостью добавлять точки останова и в Java, и в C/C++: достаточно щелкнуть левое поле текстового редактора. Точки останова Java поддерживаются без дополнительной настройки благодаря подключаемому модулю ADT, управляющему отладкой посредством Android Debug Bridge. Но для CDT это не так, поскольку это решение не поддерживает Android. В этом случае вставка точки останова ничего не даст, если не настроить CDT для использования GDB в составе NDK. При этом необходимо связать GDB с приложением Android для его отладки. Сначала включите в приложении режим отладки, выполнив следующие действия:

1. Важно не забыть включить флаг отладки в проекте Android. Это нужно сделать в файле манифеста приложения AndroidManifest.xml. Не забудьте указать соответствующую версию SDK для встроенного кода:

<?xml version="1.0" encoding="utf-8"?> <manifest ...> <uses-sdk android:minSdkVersion="10"/> <application ... android:debuggable="true"> ...

2. Включение флага отладки в манифесте автоматически включает режим отладки встроенного кода. Но режим отладки также управляется и флагом APP_OPTIM. Если этот флаг был вручную задан в файле Android.mk, убедитесь, что для него установлено значение debug (а не release), или просто удалите его:

APP_OPTIM := debug

3. Теперь нужно настроить клиент GDB, который будет подключаться к устройству. Заново скомпилируйте проект и подключите устройство или запустите эмулятор. Запустите приложение и оставьте его в запущенном состоянии. Убедитесь, что приложение загружено, а его PID доступен. Для проверки можно открыть список процессов с помощью следующей команды (в Windows используйте Cygwin):

$ adb shell ps |grep gl2jni

Должна быть возвращена одна строка:

app_75 13178 1378 201108 68672 ffffffff 80118883 S com.android.gl2jni

4. Откройте окно терминала и перейдите в папку проекта. Выполните команду ndk-gdb (она находится в папке Android NDK, например, android-ndk-r8\):

$ ndk-gdb

Эта команда не отобразит сообщение, но создаст три файла в папке obj\local\x86:

      gdb.setup: это файл конфигурации для клиента GDB.

      app_process: этот файл берется непосредственно с устройства. Это исполняемый файл системы, он запускается при запуске системы и разветвлении для запуска нового приложения. Этот ссылочный файл нужен для GBD для обнаружения его отметок. Это двоичная точка входа приложения.

      libc.so: этот файл также берется с устройства. Это стандартная библиотека С в Android (ее часто называют «bionic»), она используется в GDB для отслеживания всех встроенных потоков, созданных во время выполнения.

5.  В папке проекта создайте копию файла obj\local\x86\gdb.setup под именем gdb2.setup. Откройте его и удалите следующую строку, которая требует, чтобы клиент GDB подключался к серверу GDB на устройстве (эта операция будет выполняться самой средой Eclipse):

(gdb) target remote :1234

6. В главном меню Eclipse откройте Run | Debug Configurations... и создайте новую конфигурацию отладки в элементе приложения C/C++ с именем GL2JNIActivityDefault. Эта конфигурация будет запускать клиент GDB на компьютере и подключаться к серверу GDB, запущенному на устройстве.

7. На вкладке Main (рис. 19) задайте для проекта собственную папку проекта, а приложение C/C++ нужно направить на папку obj\local\ x86\app_process с помощью кнопки Browse (можно использовать как абсолютный, так и относительный путь).

Рисунок 19. Конфигурации отладки приложений C/C++

1. Выберите тип запуска Standard Create Process Launcher (рис. 20), щелкнув ссылку Select other... в нижней части окна.

Рисунок 20. Выбор предпочитаемого способа запуска

1. Перейдите к файлу отладчика, установите тип отладчика gdbserver, выберите в качестве отладчика GDB файл android-ndk-r8\toolchains\x86-4.4.3\prebuilt\windows\bin\i686-android-linux-gdb.exe. Командный файл GDB (рис. 21) должен указывать на файл gdb2.setup, находящийся в папке \obj\local\x86 (можно использовать как абсолютный, так и относительный путь).

Рисунок 21. Окно параметров отладчика

1. Перейдите на вкладку Connection (рис. 22) и в раскрывающемся списке Type выберите TCP. Оставьте значения по умолчанию для полей Host name or IP address и Port number (localhost, 5039).

Рисунок 22. Параметры подключения в окне параметров отладчика

1. Настроим Eclipse для запуска сервера GDB на устройстве. Создайте копию файла android-ndk-r8\ndk-gdb и откройте его в текстовом редакторе. Найдите строку:

$GDBCLIENT -x `native_path $GDBSETUP`

Закомментируйте эту строку, поскольку клиент GDB будет запускаться самой средой Eclipse:

#$GDBCLIENT -x `native_path $GDBSETUP`

2. В главном меню Eclipse откройте Run | External Tools | External Tools | Configurations... (рис. 23) и создайте новую конфигурацию GL2JNIActivity_GDB. Эта конфигурация будет запускать сервер GDB на устройстве.

3. На вкладке Main настройте параметр Location так, чтобы он указывал на наш измененный файл ndk-gdb в папке android-ndk-r8. Задайте папку, в которой находится приложение, в качестве рабочей папки. При необходимости можно настроить аргументы в текстовом поле Arguments:

  • verbose: подробное отображение данных консоли Eclipse.
  •  force: автоматически закрывать все предыдущие сеансы.
  • start: позволить серверу GDB запустить приложение вместо подключения к приложению после его запуска. Этот параметр полезен при отладке только встроенного кода, без Java.

Рисунок 23. Конфигурации внешних инструментов

1. Запустите приложение обычным образом.

2. После запуска приложения можно либо запустить ndk-gdb напрямую из консоли, либо запустить внешнюю конфигурацию GL2JNIActivity_GDB, которая запустит сервер GDB на устройстве. Сервер GDB получает команды отладки, отправленные удаленным клиентом GDB, и выполняет локальную отладку приложения.

3. Откройте jni\gl_code.cpp и задайте точку останова (рис. 24) в setupGraphics, дважды щелкнув левое поле текстового редактора (также можно щелкнуть правой кнопкой мыши и выбрать команду Toggle breakpoint).

Рисунок 24. Настройка точек останова

1. И наконец, запустите конфигурацию приложения GL2JNIActivity Default C/C++, чтобы запустить клиент GDB. Он передает команды отладки из Eclipse CDT на сервер GDB. С точки зрения разработчика такой процесс схож с отладкой локального приложения.

3.    The Intel® Graphics Performance Analyzer (Intel® GPA)

Существуют определенные решения для отладки обработки графики. Решение Intel® GPA System Analyzer, входящее в семейство Intel® Graphics Performance Analyzers (Intel® GPA) и поддерживающее устройства Android с процессорами Intel, поможет разработчикам приложений и драйверов оптимизировать свои решения для OpenGL* ES.

В этом разделе содержатся инструкции по настройке и использованию Intel GPA с устройством Android, подключенном через USB. При подключении к устройству инструмент Intel GPA System Analyzer предоставляет метрики производительности API OpenGL ES, ЦП и ГП, а также предоставляет множество переопределений состояния графического конвейера для помощи в анализе производительности приложения OpenGL ES.

Для применения Intel GPA System Analyzer на устройствах Android с архитектурой x86 нужно проверить целевой компьютер и версию ее микропрограммы.

Чтобы приступить к сбору метрики, нужно установить Intel GPA System Analyzer на клиентскую систему и подключить ее к целевому устройству:

  1. Установите Intel GPA 2012 на клиентский компьютер с ОС Windows или Linux.
  2. Запустите Intel GPA System Analyzer.
  3. Убедитесь, что устройства с Android подключено к клиентскому компьютеру с помощью кабеля USB.
  4. Подождите, пока клиентская система обнаружит подключенные устройства — это может занять до 10 секунд. Найденные устройства будут показаны в диалоговом окне. Список устройств обновляется через каждые 5–6 секунд.
  5. Выберите устройство, к которому нужно подключиться, и нажмите кнопку Connect (рис. 25). Intel GPA System Analyzer скопирует нужные компоненты на устройство и создаст список установленных приложений. Можно прервать процесс подключения, нажав кнопку Stop.

Рисунок 25. Выбор подключенного устройства

1. Выберите нужное приложение в списке доступных приложений. В списке приложений (рис. 26) отображаются все пользовательские и системные приложения, установленные на устройстве Android.

Рисунок 26. Список приложений

  1. 1. Приложение будет запущено, его данные появятся в окне Intel GPA System Analyzer.
  2. 2. Чтобы переключиться к другому приложению, нажмите кнопку Back. При этом запущенное приложение будет принудительно закрыто.
  3. 3. Чтобы переключиться к другому целевому устройству, нажмите кнопку Back. Графическая архитектура PowerVR состоит из следующих основных модулей, преобразующих полученные трехмерные данные приложения в готовое изображение: ускоритель обработки фрагментов (TA), обработчик синтеза изображения (ISP), обработчик текстур и теней (TSP). Метрики Intel GPA в группе «GPU» соответствуют одному из этих основных модулей, а порядок метрик в их списке определяет порядок модулей в графическом конвейере (рис. 27).

Рисунок 27. Окно Intel® GPA System Analyzer

4.    Системная отладка ОС Android на устройстве с процессором Intel® Atom™

До этого мы говорили о разработке и отладке приложений, будь то выполняемые модули Java* или встроенный код двоичных и общих объектов архитектуры Intel® x86.

Для системных интеграторов и производителей устройств также важно работать с драйверами устройств и системным ПО. Это особенно важно, если нужно реализовать поддержку какого-либо дополнительного устройства или при первом переносе ОС на новое устройство с Intel® Atom™.

В следующих разделах мы рассматриваем решения для отладки на основе стандарта IEEE 1149.1 (JTAG). Мы рассматриваем все архитектурные различия между ARM* и Intel®, способные повлиять на отладку на уровне системы.

4.1. Отладка JTAG

 Для отладки микропрограмм, системного ПО уровня ОС и драйверов устройств наиболее распространенным методом является использование интерфейса JTAG. Стандарт JTAG IEEE 1149.1 определяет «стандартный тестовый порт доступа и архитектуру граничного сканирования для портов тестового доступа, применяемых для тестирования печатных плат». Этот стандарт часто называют просто интерфейсом отладки JTAG. Из стандарта тестирования печатных плат он превратился в ставший стандартом интерфейс для отладки платформ независимо от ОС и на уровне ОС.

Дополнительные сведения о JTAG и его использовании в отладке современного ПО см. в статье Рэнди Джонсона и Стюарта Кристи «JTAG 101; IEEE 1149.x and Software Debug» по адресу http://download.intel.com/design/intarch/papers/321095.pdf.

С точки зрения производителей устройств, разработчиков приложений и драйверов, понимание взаимодействия между драйверами и программными компонентами в различных подсистемах микросхем и устройств важно для определения стабильности платформы. С точки зрения проверки микросхем низкоуровневый комплект ПО обеспечивает тестовую среду, позволяющую сымитировать факторы нагрузки, которым платформа будет подвергаться при ее реальном использовании. Для работы с современными системами требуется понимать, как работают все их компоненты вместе в реальной обстановке; положительных результатов тестирования отдельных компонентов недостаточно. Именно на этом уровне и используется отладка на базе JTAG. Благодаря связи JTAG с аппаратным уровнем можно экспортировать сведения о состоянии в ОС Android на целевом устройстве.

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

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

Процессор Intel® Atom™ Z2460 поддерживает граничное сканирование IEEE-1149.1 и IEEE-1149.7 (JTAG), интерфейс параллельной трассировки MPI PTI, а также трассировку инструкций на базе Branch Trace Storage (BTS) с помощью порта Intel XDP, совместимого с JTAG.

Различные поставщики JTAG предлагают решения для отладки систем с поддержкой Android, в том числе следующие:
• Wind River (http://www.windriver.com/products/JTAG-debugging/)
• Lauterbach (http://www.lauterbach.com)
• Intel (http://software.intel.com - access restrictions may apply)

4.2. Отладка ОС Android

Отладка платформ Android осложняется тем, что обычно система Android стремится перейти в состояние простоя и сна для оптимизации расхода электроэнергии. Таким образом, отладка режима пониженного потребления электроэнергии становится непростой задачей

• Можно поддерживать функциональность JTAG в некоторых состояниях пониженного потребления электроэнергии
• Там, где это невозможно, следует запускать JTAG сразу же после включения питания набора микросхем, отвечающего за работу JTAG.

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

Системный отладчик на основе агента отладки или интерфейса JTAG очень полезен для решения ряда важных задач разработки ОС.

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

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

На рис. 28 показаны подробные сведения об атрибутах преобразования страниц и таблицы дескрипторов в окнах Intel® JTAG Debugger. Для платформы x86 характерна высокая гибкость в определении глубины таблиц преобразования и точность адресации блоков памяти. Такое удобство доступа и представления памяти играет важную роль для разработки системы на уровне ОС.


Рисунок 28. Примеры представления конфигурации памяти в отладчике

5.1. Отладка драйверов устройств

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

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

Рисунок 29. Регистры устройства в окне Bitfield Editor

Анализ кода после распаковки сжатого ядра Android zImage в память осуществляется путем высвобождения управления выполнением в отладчике до достижения start_kernel. При этом предполагается, что был загружен файл vmlinux, содержащий символьную информацию ядра. На этом этапе можно использовать программные точки останова. До этого момента в процессе загрузки следует использовать только аппаратные точки останова на базе регистров (чтобы избежать ситуации, когда отладчик попытается записать инструкции точек останова в память, которая еще не инициализирована). Затем ОС успешно загружается после достижения цикла бездействия mwait_idle.

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

5.2. Аппаратные точки останова

Как и в ARM, процессоры Intel поддерживают инструкции программных точек останова, а также аппаратные точки останова для данных и кода. В архитектуре ARM обычно имеется набор выделенных регистров для точек останова и точек наблюдения. В стандартной реализации поддерживается по 2 регистра каждого из этих типов. Когда эти регистры содержат значения, процессор проверяет данные доступа, чтобы задать адрес в памяти для регистра счетчика программы или доступ к памяти на чтение или запись. При осуществлении доступа выполнение останавливается. Такое поведение отличается от программных точек останова: их выполнение останавливается при получении инструкции точки останова. Поскольку инструкция точки останова заменяет инструкцию сборки, которая должна находиться в заданном адресе памяти, выполнение останавливается до момента, в котором была бы выполнена инструкция.

Реализация аппаратных точек останова в архитектурах Intel и ARM очень похожа, но у Intel чуть выше гибкость.

На всех ядрах процессоров Intel Atom имеется 4 регистра DR, где хранятся адреса, сравниваемые с полученными адресами шины памяти до (иногда после) выборки памяти.

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

  • 00 – прерывание при выполнении инструкции
  • 01 – прерывание только при записи данных
  • 10 – не задано ЛИБО (если архитектура допускает) прерывание при чтении или записи ввода-вывода
  • 11 – прерывание при чтении или записи данных, но не при выборке инструкций

Таким образом, все 4 аппаратные точки останова могут служить как точками останова, так и точками наблюдения. Точки наблюдения могут работать в режиме только записи либо чтения и записи (или ввода-вывода).

5.2.Отладка для разных платформ: Intel® Atom™ и ARM

Многие разработчики, работающие с Intel Atom, могут обладать опытом разработки главным образом для RISC-процессоров с фиксированной длиной инструкций. Такая архитектура используется в процессорах MIPS и ARM. Модель перекрестной отладки для архитектур Intel Atom и ARM не имеет существенных отличий. Многие принципиальные методы и проблемы отладки совпадают.

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

Между процессорами Intel Atom и ARM существует ряд различий, о которых должны знать разработчики. Эти различия описываются в следующих разделах.

5.3. Инструкции различной длины

В наборах инструкций IA-32 и Intel 64 используются инструкции разной длины. На отладчик это влияет следующим образом: отладчик не может просто исследовать код с фиксированными 32-разрядными интервалами. Необходимо интерпретировать и дизассемблировать машинные инструкции приложения на основе контекста этих инструкций. Расположение следующей инструкции зависит от расположения, размера и правильного декодирования предыдущей инструкции. В архитектуре АРМ, напротив, отладчику достаточно следить за последовательностью кода, переключающую из режима ARM в режим Thumb или в расширенный режим Thumb и обратно. В пределах одного режима все инструкции и адреса памяти имеют размер либо 32, либо 16 разрядов. Разработчики микропрограмм и драйверов устройств, которым требуется точно адресовать вызовы к определенным регистрам устройства и использовать окно памяти отладчика, должны понимать возможное влияние инструкций различной длины.

 

5.4. Аппаратные прерывания

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

    • 0 сброс
    •  1 отмена
    • 2 отмена данных
    •  3 отмена упреждающей выборки
    • 4 неопределенная инструкция
    •  5 прерывание (IRQ)

 

  •  6 Fast быстрое прерывание (FIRQ)

 

 

Назначаются адресам с 0x0 по 0x20. Эта область памяти защищена, в ней невозможно перераспределение. Обычно все векторные расположения с 0x0 по 0x20 содержат переходы к адресу памяти, где находится настоящий код обработчика исключений. Предполагается, что по адресу 0х0 будет находиться переход к расположению микропрограммы или загрузочного кода платформы. Из-за такого подхода реализация аппаратных прерываний и обработчиков сигналов ОС в архитектуре ARM является менее гибкой, но с более высоким уровнем стандартизации. «Поймать» прерывание отладчиком очень просто: достаточно установить аппаратную точку останова в расположении вектора в диапазоне адресов с 0x0 по 0x20.

В архитектуре Intel используется выделенный контроллер аппаратных прерываний. Прерывания

  •  0 системный таймер
  • 1 клавиатура
  • 2 каскадный второй контроллер прерывания
  •  3 COM2 - serial interface
  •  4 COM1 - serial interface
  • 5 LPT - параллельный интерфейс LPT
  •  6 контроллер дисковода для гибких дисков
  •  7 доступное прерывание
  •  8 часы CMOS реального времени
  •  9 звуковой адаптер
  • 10 сетевой адаптер
  • 11 доступное прерывание
  • 12 доступное прерывание
  • 13 числовой процессор
  • 14 - интерфейс жесткого диска IDE
  •  15 - интерфейс жесткого диска IDE

недоступны напрямую в адресном пространстве памяти процессора, но обрабатываются путем доступа к контроллеру прерываний Intel 8259. В списке прерываний видно, что контроллер поддерживает прямую обработку аппаратных прерываний ввода-вывода подключенных устройств, которые обрабатываются посредством прерываний IRQ или быстрых прерываний на платформе ARM. Эта возможность упрощает реализацию правильной обработки прерываний в архитектуре Intel на уровне ОС, особенно для ввода-вывода устройств. Сопоставление программных исключений, таких как отмены или сбои сегментации, также обрабатываются более гибко в архитектуре Intel; оно осуществляется портом контроллера прерываний, адресация к которому осуществляется через таблицу дескрипторов прерываний (IDT). Сопоставление IDT аппаратным прерываниям определяется системными программами. Кроме того, невозможно с легкостью получать такие исключения при отладке, не учитывающей системные программы. В архитектуре Intel для отладки программных событий, переключающих аппаратные прерывания, требуется определенное знание уровня ОС. Необходимо знать, каким образом сигналы ОС этих исключений соотносятся с контроллером прерываний. Даже в отладчике системного уровня сопоставленная в памяти таблица сигналов из ОС будет перехватывать исключения на уровне ОС, а не на аппаратном уровне.

5.5. Одношаговые инструкции

В архитектуре ARM нет явных одношаговых инструкций. В архитектуре Intel одношаговые переходы уровня сборки часто реализуются в отладчике напрямую с помощью таких инструкций. В ARM однократный переход инструкции реализуется в виде команды «выполнять до прерывания». Отладчик должен проверить код, чтобы убедиться в том, что учитываются все пути кода (особенно при отступлении от инструкции ветви). С точки зрения реализации отладчика при этом возникают некоторые издержки, но их объем незначителен, поскольку реализация «выполнять до прерывания» все равно будет требоваться для переходов в высокоуровневом языке. Разработчики ПО должны учитывать это различие, поскольку оно может вызвать слегка иное поведение переходов.

5.6. Сопоставление виртуальной памяти

Реализация таблицы дескрипторов и преобразования страниц для сопоставления виртуальной памяти очень похожи, по крайней мере по принципу работы. В архитектуре Intel глобальная и локальная таблицы дескрипторов (GDT и LDT) позволяют управлять уровнем вложенности страниц памяти в виртуальном адресном пространстве. На рис. 30 показана функция преобразования страниц отладчика, графически представлено преобразование линейного адреса в физический в архитектуре Intel.

Рисунок 30. Преобразование страниц в архитектуре Intel®.

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

Рисунок 31. Преобразование страниц в ARM

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

Механизм преобразования страниц Intel обеспечивает более высокую гибкость в работе с памятью системы и механизмов, используемых уровнем ОС для выделения определенных блоков памяти, таких как защищенных блоков для выполнения приложений. Но при этом разработчикам становится сложнее получить полную картину виртуализации памяти и устранить утечки памяти и нарушения доступа к памяти (сбои сегментации). Такая проблема была бы менее важна для полнофункциональных ОС с большим объемом памяти. Операционные системы реального времени, более зависимые от правильной работы с памятью, более уязвимы для таких неполадок. 

6   Intel® Hyper-Threading Technology

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

7. Итоги

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

Существует полнофункциональный набор сред отладки, поддерживающий все возможности, необходимые разработчикам приложений на Java, разработчикам приложений на C/C++, а также разработчикам системного программного обеспечения.

Отладка программ на устройствах с процессорами Intel поддерживается стандартными пакетами Android SDK и Android NDK корпорации Google. Кроме того, корпорация Intel и другие компании предоставляют решения для отладки, в том числе для отладки программ и производительности графической подсистемы.

Если вы обладаете навыками отладки и разработки приложений для устройств Android с архитектурой ARM, то эти навыки можно использовать и для архитектуры Intel. Доступные средства отладки и разработки, основанные на Android* SDK и расширяемые решениями Intel и других компаний, также могут быть уже знакомы по опыту работы с ARM*. Поэтому при отладке программ для устройств с Intel® Atom™ вряд ли можно встретить какие-либо существенные отличия от работы с устройствами с ARM.