Эта статья является продолжением серии из двух статей, в которой рассматриваются проблемы, возникающие в процессе портирования преложений на OpenGL на платформу Google Android. В данной статье рассматриваются ограничения, связанные с различиями расширений OpenGL, поддержкой операций с плавающей запятой, сжатыми форматами текстур и библиотекой OpenGL Utility Library (GLU). Кроме того, здесь описана настройка системы разработки для Android на базе процессоров Intel® Atom и пути достижения максимально возможной производительности в средствах эмуляции виртуального устройства Android при использовании OpenGL ES.

В первой части данной серии статей содержится информация об использовании OpenGL ES на платформе Android с помощью пакета средств разработки программного обеспечения (SDK) или пакета Android NDK (Native Development Kit) и о том, по какому принципу выбирается тот или иной пакет. В ней описаны различные примеры приложений OpenGL ES в SDK и NDK и интерфейс Java* Native Interface, позволяющий комбинировать компоненты Java и C/C++.

Препятствия при портировании приложений OpenGL для настольных ПК

API-интерфейс OpenGL ES 1.1 является подмножеством API-интерфейсов OpenGL 1.x, которые использовались в настольных системах Linux* и Windows* на протяжении десятилетий. Аналогично API-интерфейс OpenGL ES 2.0 является подмножеством API-интерфейса OpenGL 2.0 для настольных систем. Поэтому любое портирование следует начать с оценки набора функций OpenGL, используемых в коде приложения, определения того насколько стар этот код и какие его части необходимо переписать по причине различий между используемой версией OpenGL и целевой версией OpenGL ES на Android.

Основные различия между OpenGL 2.0 и OpenGL ES 2.0 можно разделить на три категории: спецификации геометрии, преобразования геометрии и изменения в языке GLSL (OpenGL Shading Language). OpenGL 2.0 позволяет задавать спецификацию геометрии четырьмя способами: с помощью непосредственного режима (immediate mode), списков отображения (display lists), массивов вершин (vertex arrays) и объектов буфера вершин (vertex buffer objects). OpenGL ES 2.0 не поддерживает непосредственный режим (блоки glBeginи glEnd) и списки отображения, поэтому задавать геометрию необходимо с помощью массивов вершин или объектов буфера вершин.

В OpenGL 2.0 есть функции для загрузки матриц модели-вида (model view), проекции (projection) и текстуры (texture), а также функции, упрощающие совместное использование этих матриц, например glTranslate, glRotateи glScale. В OpenGL ES 2.0 нет ни этих функций, ни функций освещения, поскольку фиксированный конвейер (fixed-function pipeline) был заменен на модель программирования шейдеров. В OpenGL ES 2.0 расчеты матриц и освещения должны выполняться в вершинном шейдере (vertex shader).

Язык шейдеров для OpenGL ES 2.0 (GLSL ES) также является подмножеством языка шейдеров для настойной версии OpenGL 2.0 (GLSL). Одно основное отличие состоит в том, что язык GLSL включает в себя встроенные переменные для доступа к состояниям в фиксированном конвейере вершинного шейдера (например, gl_ModelViewMatrix). Поскольку OpenGL ES 2.0 не поддерживает фиксированный конвейер, эти переменные не поддерживаются в GLSL ES.

В OpenGL ES 2.0 отсутствуют следующие функции OpenGL 2.0:

• Спецификация геометрии с помощью непосредственного режима
• Спецификация геометрии с помощью списка отображения
• Обработка всего фиксированного конвейера
• Фиксированные преобразования и освещенность
• Матричный стек и преобразования матриц
• Пользовательские плоскости отсечения
• Сглаживание и пунктирное отображение линий и многоугольников
• Пиксельные прямоугольники и растровые изображения
• Одномерные текстуры и некоторые режимы обертывания текстур
• Запросы на перекрытие
• Туман

Примечание. Сведения о других отличиях OpenGL 2.0 от OpenGL ES 2.0 см. по адресу http://software.intel.com/en-us/articles/targeting-3d-applications-for-mobile-devices-powered-by-opengl-and-opengl-es.

Портирование из других встроенных систем

Приложение OpenGL ES обычно проще портировать на Android из других встроенных систем, чем из настольных систем с OpenGL, поскольку в большинстве встроенных систем, как и в Android, используются спецификации OpenGL ES 1.1 и 2.0. При портировании кода OpenGL ES из другой встроенной системы наиболее важные отличия обычно касаются поддержки расширений OpenGL ES, а именно сжатых форматов текстур. Еще одним источником проблем могут стать различия в поддержке операций с плавающей запятой между встроенными системами.

Поддержка операций с плавающей запятой

Ранние реализации OpenGL ES 1.0 и 1.1 поставлялись в двух версиях — Commonи Common-Lite. Версия Common предназначалась для процессоров с поддержкой аппаратной обработки операций с плавающей запятой; версия Common-Lite — для процессоров без такой поддержки, требующих использования расчетов с фиксированной запятой. Поскольку для Android требуются процессоры, поддерживающие операции с плавающей запятой, такие как Intel Atom, необходимость в использовании фиксированной запятой не возникает никогда, и образы системы Android, предоставленные компанией Google, включают в себя только драйверы Common для OpenGL ES 1.1 (с поддержкой плавающей запятой). Стандарт Khronos для OpenGL ES 2.0 предусматривает только операции с плавающей запятой. Это нужно учитывать при портировании игры OpenGL ES 1.0 или 1.1 из другой встроенной системы, использующей реализацию Common-Lite стандарта OpenGL ES, поскольку вы должны будете преобразовать все имеющиеся в коде расчеты с фиксированной запятой в формат с плавающей запятой (так как в Android доступна только версия Common стандарта OpenGL ES). Драйверы Common и Common-Lite во встроенных системах Linux обычно имеют имена, похожие на libGLESv1_CM.soи libGLESv1_CL.so.

Если код OpenGL портируется из приложения для настольных ПК, то, скорее всего, в нем уже используются операции с плавающей запятой. Однако следите за тем, чтобы код не включал в себя операции с плавающей запятой с двойной точностью. Android поддерживает операции с плавающей запятой с двойной точностью, но OpenGL ES поддерживает только одинарную точность. По этой причине перед переносом кода OpenGL ES 1.1 или 2.0 необходимо преобразовать все значения с двойной точностью в значения с одинарной точностью.

Расширения OpenGL

Одно из наиболее значительных препятствий при портировании кода OpenGL на другую платформу возникает в связи с использованием в коде приложения расширений OpenGL и библиотеки EGL (Embedded System Graphics Library). Необходимо на раннем этапе портирования выяснить, какие расширения используются в старом коде, и сравнить их с расширениями, доступными на целевых устройствах Android. Расширение — это реализованный разработчиками графического процессора способ предоставления доступа к специальным возможностям графического процессора, выходящими за рамки стандартных спецификаций OpenGL. Для каждого использованного в старом коде расширения, недоступного на целевой платформе, потребуется написать новый код, позволяющий обойтись без этого расширения, или использовать другое расширение.

Поддерживаемые расширения существенно различаются в разных версиях OpenGL и даже на разных платформах Android из-за различий в архитектуре графического процессора. Системы с процессорами Intel Atom оснащаются графическими процессорами PowerVR*, представляющими наиболее распространенную архитектуру графических процессоров в современных мобильных устройствах. При создании приложений для Android не следует полагаться на то, что определенное расширение OpenGL ES будет доступно на любом устройстве. Приложение должно запрашивать список доступных расширений OpenGL ES во время выполнения. Такие списки расширений можно получить из драйверов OpenGL ES и EGL с помощью следующих функций:

• glGetString(GL_EXTENSIONS); 
• eglQueryString(eglGetCurrentDisplay(), EGL_EXTENSIONS);

Имена всех функций и перечислений, необходимых для вызова расширений, определены в файлах заголовков glext.h, gl2ext.hи eglext.h, поэтому после того, как приложение проверит доступность определенного расширения во время выполнения, его можно будет непосредственно вызвать.

На веб-сайте Google Play предлагается полезное приложение OpenGL Extensions Viewer (GLview), выполняющее данный запрос и отображающее полученную информацию для любого устройства Android, на котором оно запускается. Было бы неплохо, если бы вы сами протестировали несколько устройств Android на наличие нужных расширений средством, подобным GLview. Кроме того, Khronos поддерживает реестр API-интерфейсов OpenGL ES для всех известных расширений OpenGL ES — используйте этот важный источник информации.

Сжатые форматы текстур

Наиболее важные расширения OpenGL ES обеспечивают поддержку сжатых текстур. Эта важная технология используется в большинстве 3D-игр для снижения требований к памяти и повышения производительности, но форматы, применяемые в OpenGL ES, определяются только расширениями и поэтому различаются для каждой платформы. К сожалению, единственным форматом, который поддерживается на всех устройствах Android (кроме устройств первого поколения, не поддерживавших OpenGL ES 2.0) является ETC1 (Ericsson Texture Compression). Формат ETC1 обеспечивает точность только 8 бит на пиксель и не поддерживает альфа-канал. Так как в большинстве игр используются сжатые текстуры с альфа-каналом, это часто затрудняет процесс портирования. Несколько архитектурно-зависимых форматов для различных платформ Android поддерживают альфа-канал, но при их использовании ваша игра будет работать только на устройствах Android с данной архитектурой графического процессора. В таблице 1 приведен список архитектур графических процессоров и соответствующих сжатых форматов текстур для Android.

Таблица 1. Архитектурно-зависимые сжатые форматы текстур с поддержкой альфа-канала

Графический процессор PowerVR на системах с процессором Intel Atom помимо ETC1 поддерживает форматы PVRTC. PVRTC поддерживает альфа-канал и точность 2 или 4 бит на пиксел, что помогает значительно уменьшать размер текстур по сравнению с форматом ETC1. PVRTC — самый массовый формат после ETC1, который также используется на всех поколениях устройств Apple iPhone*, iPod touch* и iPad*, поэтому он обеспечивает некоторую совместимость с устройствами Android на процессорах Intel Atom за рамками базового стандарта OpenGL ES, что имеет важное значение при портировании игр на платформы Android и Apple iOS*. Тем не менее остаются устройства Android с другими архитектурами графических процессоров, для которых также требуется решение. Если в вашем приложении используются любые архитектурно-зависимые форматы текстур, оно должно запрашивать расширения OpenGL ES во время выполнения для определения доступных форматов и использовать только текстуры, которые были сжаты в этом формате. Нужно принять непростое проектное решение. Варианты таковы:

• Не поддерживать устройства Android с другими архитектурами графических процессоров.
• Предоставить текстуры, сжатые во всех трех архитектурно-зависимых форматах.
• Не использовать сжатие текстур с альфа-каналом.
• Разделить цветовые и альфа-компоненты на пары файлов ETC1 и совмещать их во фрагментном шейдере (fragment shader).

Приняв решение о том, какие архитектурно зависимые форматы должны присутствовать в вашем приложении, не забудьте объявить их в файле манифеста, как будет описано далее. Дополнительные сведения см. в статье о поддержке сжатия текстур [Eng].

Библиотека GLU

Версии OpenGL для настольных ПК обычно включают в себя библиотеку утилит OpenGL (GLU), содержащую функции для упрощения работы. В библиотеку GLU входят функции, не относящиеся напрямую к OpenGL и необязательные для использования OpenGL, но они могут быть полезны при создании 3D-приложений для OpenGL. Обычно библиотека GLU включает в себя функции для конструирования матриц модели-вида и проекции, выполнения общих матричных расчетов, расчета поверхностей с произвольной геометрией (quadric), тесселяции полигонов (tessellation), генерации мип-карт (mipmap) и вывода сообщений об ошибках. Во многих играх OpenGL для настольных ПК используются некоторые функции GLU, что может вызвать проблемы, поскольку в Android реализован только минимум возможностей GLU и они доступны только в SDK. Эти классы перечислены в таблице 2.

Таблица 2. Сводная информация о классах Android с поддержкой функций GLU

В OpenGL ES 1.1 и 2.0 поддерживается генерация мип-карт и отсутствует поддержка расчета поверхностей с произвольной геометрией и тесселяции полигонов. Если эти функции необходимы, существуют другие реализации GLU с открытым исходным кодом, более полные и совместимые с Android NDK, например GLU ES.

Объявление OpenGL ES в файле манифеста

Приложения, требующие OpenGL ES, должны содержать соответствующую декларацию в файле манифеста. Это поможет предотвратить установку вашего приложения на устройства, не поддерживающие требуемую версию OpenGL ES. В следующих примерах показан правильный синтаксис обязательных параметров манифеста в файле AndroidManifest.xml.

OpenGL ES 1.1:

• <uses-feature android:glEsVersion="0x00010001" android:required="true" />
• <uses-sdk android:minSdkVersion="4"/>

OpenGL ES 2.0:

• <uses-feature android:glEsVersion="0x00020000" android:required="true" />
• <uses-sdk android:minSdkVersion="8"/>

В Android 4.0 (API level 14) было представлено важное изменение — аппаратное ускорение OpenGL ES теперь включено по умолчанию для всех приложений, в которых декларируется параметр minSdkVersionсо значением 14 или выше. Приложения могут включать ускорение на более низких уровнях API путем добавления атрибута android:hardwareAccelerated=“true”в тег <application>. Если ваше приложение использует новые функции Android 4.0, требующие аппаратного ускорения OpenGL ES, например класс TextureView, его необходимо включить в файле манифеста, иначе эти функции не будут работать.

Если ваше приложение использует класс NativeActivity, он должен быть объявлен в файле манифеста и должно быть указано имя библиотеки общих объектов, содержащей действие NativeActivity. Параметр minSdkVersionтакже должен иметь значение 9 или выше. См. пример в образце приложения native-activity в NDK.

Если в вашем приложении используются сжатые текстуры, их следует объявить, как показано далее. Это не помешает установке вашего приложения на устройствах, не поддерживающих данные функции, поэтому по-прежнему важно во время выполнения запросить данные об имеющихся на устройстве расширениях для необходимых архитектурно-зависимых форматов. С помощью этих параметров манифеста внешние службы, такие как Google Play, отфильтровывают приложения, не работающие на устройствах, которые не поддерживают необходимые форматы текстур.

Параметры манифеста, необходимые при использовании сжатых форматов текстур:

• <supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
• <supports-gl-texture android:name="GL_OES_compressed_paletted_texture" />
• <supports-gl-texture android:name="GL_IMG_texture_compression_pvrtc" />

Настройка системы разработки под Android для процессоров Intel Atom

При настройке своей системы разработки под Android обязательно выберите версию Android со встроенной поддержкой процессоров Intel Atom. Таким образом, вы сможете запускать свои приложения на устройствах Intel Atom и использовать системные образы AVD (Android Virtual Devices) с эмуляцией Intel Atom. В таблице 3 собрана информация обо всех основных версиях Android до сегодняшнего дня и о том, для каких из них доступны системные образы с эмуляцией встроенных процессоров Intel Atom.

Таблица 3. Сводная информация о версиях Android с поддержкой OpenGL ES и процессоров Intel® Atom

Версии Android 2.3.3 (Gingerbread), 4.0.3 (Ice Cream Sandwich) и 4.1 (Jelly Bean) полностью поддерживают процессоры Intel Atom, включая драйверы для OpenGL ES 1.0, 1.1 и 2.0. Просто выберите одну из этих версий в Android SDK Manager и убедитесь, что в списке есть системный образ Intel x86 Atom System Image. Кроме того, загрузите и установите Intel® Hardware Accelerated Execution Manager (HAXM), который указывается в разделе Extrasв SDK Manager. Если вы еще не установили средство Android SDK Manager, его можно загрузить по адресу http://developer.android.com/sdk/index.html.

SDK Manager загружает программу установки HAXM и помещает ее в папку Extras, но для завершения установки необходимо запустить программу установки HAXM вручную. Необходимо также включить функцию Virtualization Technology в меню установки ROM BIOS на компьютере, который используется для разработки. Программа установки HAXM находится в папке …\android-sdk\extras\intel\Hardware_Accelerated_Execution_Manager. При запуске эмулятора x86 AVD с правильно установленным средством HAXM отображается следующее сообщение: "HAX is working and emulator runs in fast virt mode" (Средство HAX запущено, и эмулятор работает в быстром виртуальном режиме)

Использование системных образов x86 и HAXM с эмулятором AVD

Любому разработчику приложений для встроенных систем известно, насколько ускоряет работу эмулятор виртуального устройства. Но с системным образом ARM эмулятор AVD работает невыносимо медленно, поскольку он должен эмулировать каждую инструкцию ARM в системе разработки на базе Windows или Linux. На типичном эмуляторе AVD с ARM одна лишь загрузка Android может занять 5 минут. Для решения этой проблемы компания Intel выпустила средство HAXM, запускающее системные образы Android x86 непосредственно с помощью функции Virtualization Technology, встроенной в новые процессоры Intel для настольных ПК. Если вы установите и будете использовать это средство для работы с AVD и системным образом Intel Atom x86, это позволит значительно ускорить разработку приложений, и для начала работы вам даже не понадобится устройство с Intel Atom.

Компания Google добавила поддержку OpenGL ES 2.0 в эмулятор AVD, начиная с версии SDK Tools 17 (Android 4.0.3 r2) в апреле 2012 года. Это позволяет транслировать вызовы OpenGL ES 2.0 в функции API OpenGL 2.0, доступные в операционной системе компьютера, что намного ускоряет обработку 3D-графики. Однако эта функция должна быть специально включена при создании AVD; иначе вызовы OpenGL ES 2.0 возвращают ошибку. В операционной системе Windows или Linux на компьютере также должны быть установлены драйверы для OpenGL 2.0 (или более поздней версии), что, в свою очередь, обычно требует наличия установленного отдельного графического адаптера. Эмуляция OpenGL ES 2.0 работает в системных образах ARM и x86, но для достижения максимальной производительности используйте системный образ x86 с включенным HAXM. Разница в производительности огромна.

Чтобы включить эмуляцию OpenGL ES 2.0, выберите AVD в средстве AVD Manager и щелкните Edit (Изменить). Затем в окне Hardware Properties (Свойства оборудования) щелкните New (Создать); прокрутите вниз список свойств и найдите элемент GPU emulation (Эмуляция графического процессора), затем щелкните OK. Измените значение этого свойства с noна yesи щелкните Edit AVD (Изменить AVD), затем щелкните OKдля сохранения изменений. Должно появиться сообщение hw.gpu.enabled=yes.

До версии SDK Tools 17 эмуляция AVD поддерживала только OpenGL ES 1.0 и 1.1. Включение эмуляции графического процессора необязательно для версии 1.1, поскольку эмуляция может выполняться без помощи операционной системы компьютера, хотя и намного медленнее. Пакет SDK Tools не может эмулировать версию 2.0 без помощи операционной системы компьютера, и при ее отсутствии AVD просто закрывает ваше приложение, когда пытается инициализировать OpenGL ES 2.0.

В качестве первоначального теста для проверки эмуляции OpenGL ES 2.0 используйте образец приложения HelloEffects. Образец GLES20TriangleRenderer при выполнении на AVD просто восстанавливает версию 1.1, поэтому он неприменим в качестве теста. Все образцы OpenGL ES 2.0, включенные в Android SDK и NDK, достаточно примитивны и не должны рассматриваться как полноценные тесты эмуляции OpenGL 2.0.

Intel® Graphics Performance Analyzers

Еще одним важным набором средств, доступных разработчикам приложений на базе OpenGL ES для устройств Android с процессорами Intel Atom, являются анализаторы производительности графики Intel® (Intel® GPA). Этот набор средств позволяет в режиме реального времени отслеживать десятки критически важных системных метрик, оценивающих параметры ЦП, графического процессора и OpenGL ES. Анализаторы Intel GPA выполняются в системах разработки Windows или Ubuntu Linux и взаимодействуют с компонентами драйверов, работающих на целевом устройстве Android, через отладочный интерфейс Android. Проведя несколько экспериментов, вы можете быстро визуально выявить критические секции графического конвейера и определить наиболее перспективные пути оптимизации кода.

Получить дополнительные сведения и загрузить последнюю версию Intel GPA (2012 R4) для разработки под Android можно по адресу http://software.intel.com/en-us/vcsource/tools/intel-gpa?cid=sem121p7972.

Заключение

Постоянное улучшение поддержки OpenGL ES и C/C++ в Android помогло устранить часть трудностей, связанных с портированием игр и других приложений, интенсивно использующих 3D-графику, на платформу Android, в том числе на устройства на базе процессоров Intel Atom. Тем не менее некоторые препятствия остаются, и важно изучить их, прежде чем начинать проект портирования игры. Наиболее важные препятствия касаются отличий в поддержке расширений OpenGL и сжатых форматов текстур на Android. Можно порадоваться тому, что компании Google и Intel за последние годы совершили внушительный скачок вперед, усовершенствовав средства разработки для OpenGL ES 2.0, и перед разработчиками ПО открылись широкие возможности по адаптации накопившегося к сегодняшнему дню огромного количества игр, игровых движков и других старых программ на базе стандарта OpenGL.

Об авторе

Клэй Д. Монтгомери (Clay D. Montgomery) является одним из ведущих разработчиков драйверов и приложений для OpenGL во встроенных системах. Он участвовал в разработке аппаратных графических ускорителей, графических драйверов, API-интерфейсов и приложений OpenGL для различных платформ в компаниях STB Systems, VLSI Technology, Philips Semiconductors, Nokia, Texas Instruments, AMX и в качестве независимого консультанта. Он сыграл важную роль в разработке некоторых первых драйверов OpenGL ES, OpenVG* и SVG, приложений для платформ Freescale i.MX и TI OMAP* и графических ядер Vivante, AMD и PowerVR. Кроме того, он подготовил и провел ряд семинаров по разработке на базе OpenGL ES во встроенных системах Linux и являлся представителем нескольких компаний консорциума Khronos Group.

Аннотация

В этой статье подробно описываются способы разработки и портирования приложений Android для платформы Intel Atom, а также рассматриваются наиболее применяемые способы разработки приложений с помощью Android Native Development Kit (NDK) и оптимизации их производительности.

1. Классификация приложений Android

Приложения Android можно разделить на два типа, как показано на Рис. 1.

• Приложения Dalvik включают код Java* и используют только официальные API из пакета SDK, а также необходимые файлы ресурсов, например XML- и PNG-файлы. Такие приложения компилируются в APK-файлы.
• Приложения Android NDK, содержащие код Java и файлы ресурсов, а также исходный код на языке C/C++ и (иногда) код на ассемблере. Весь собственный код компилируется в библиотеку динамической компоновки (SO-файл), а затем вызывается кодом Java в основной программе с помощью механизма JNI.

Рисунок 1:Два типа приложений Android

2. Android Native Development Kit

2.1 Введение

Android Native Development Kit (NDK) — это мощное средство для разработки приложений Android, обладающее следующими возможностями:

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

2.2 Описание средств

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

2.3 Установка HAXM

Установить HAXM можно либо с помощью Android SDK Manager (рекомендуется), либо вручную, загрузив программу установки с веб-сайта Intel. Для автоматического обновления используйте установку с помощью Android SDK Manager, как показано на Рис. 2. ^[1]

Рисунок 2:Установка Intel HAXM с помощью Android SDK Manager

Также можно загрузить соответствующий установочный пакет с сайта http://www.intel.com/software/ru-ru/androidна базовую платформу, а затем следовать пошаговым инструкциям для установки.

2.3.1 Настройте HAXM

При запуске HAXM требуется системный образ Android x86 корпорации Intel. Загрузить системный образ можно с помощью Android SDK Manager или вручную с сайта Intel® Developer Zone.

После успешной установки образы эмулятора автоматически выполняются с помощью двоичного файла emulator-x86 в составе Android SDK. Работа эмулятора Android ускоряется с помощью Intel VT, что ускоряет процесс разработки.

3. Разработка и преобразование приложений NDK для архитектуры Intel Atom

3.1 Разработка приложений NDK Intel Atom

После успешной установки NDK уделите несколько минут ознакомлению с документами, находящимися в папке <ndk>/docs/, особенно OVERVIEW.html и CPU-X86.html. Это полезно для понимания механизма NDK и принципов его использования.

Разработку приложений NDK можно разделить на 5 этапов, как показано на Рис. 3:

Рисунок 3:Процесс разработки приложений NDK

Для иллюстрации этих 5 этапов используется демонстрационное приложение hello-jni. Демонстрационное приложение находится в папке NDK Root\samples\hello-jni [5]. Демонстрационное приложение hello-jni — это простое приложение в составе NDK. Это приложение получает строку из собственного метода в общей библиотеке и использует эту строку в пользовательском интерфейсе приложения.

3.1.1. Создайте собственный код

Создайте новый проект Android и поместите собственный исходный код в папку <project>/jni/. Содержимое проекта показано на рис. 4. Эта демонстрация включает простую функцию в собственном коде с именем Java_com_example_hellojni_HelloJni_stringFromJNI(). Как показано в исходном коде, эта функция возвращает строку из JNI.

Рисунок 4:Создание собственного кода

3.1.2 Создайте файл MakeFile Android.mk

Приложения NDK по умолчанию предназначены для платформы ARM. Для сборки приложений NDK для платформы Intel Atom необходимо добавить строку APP_ABI := x86 в файл MakeFile.

Рисунок 5:Создание файла MakeFile

3.1.3 Скомпилируйте собственный код

Соберите собственный код, выполнив сценарий ndk-build в папке проекта. Сценарий находится в папке NDK верхнего уровня. Результат показан на Рис. 6.

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

Средства сборки автоматически копируют очищенные общие библиотеки в нужное расположение в папке проекта приложения.

3.1.4 Вызов собственного кода из Java

После успешного развертывания общей библиотеки можно вызвать функцию со стороны Java. Код показан на рис. 7. В коде Java создается вызов собственной функции stringFromJNI(), которая загружает общую библиотеку с помощью System.loadlibrary().

Рисунок 7:Вызов собственного кода из Java

3.1.5 Отладка с помощью GDB

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

• Приложение NDK собрано с помощью ndk-build
• Приложению NDK установлен атрибут debuggable в Android.manifest
• Приложение NDK выполняется под управлением Android 2.2 (или более поздней версии)
• Запущено только одно устройство назначения
• Папка, в которой находится adb, добавлена в PATH

Используйте команду ndk-gdb для отладки приложения. Можно либо задать точку останова, либо выполнять пошаговую отладку, чтобы отслеживать изменения значения переменной, как показано на Рис. 8.

Рисунок 8:Отладка приложения NDK с помощью GDB

3.2 Портирование существующих приложений NDK на устройства с Intel Atom

В этом разделе предполагается, что у нас есть приложение Android для платформы ARM, и перед его развертыванием на платформе Intel Atom требуется его преобразовать.

Процесс портирования приложений Android на платформу Intel Atom аналогичен процессу разработки. Действия показаны на Рис. 9.

Рисунок 9:Преобразование приложений Android для платформы Intel Atom

3.2.1 Преобразование приложений Dalvik

Приложения Dalvik могут выполняться на устройствах с процессорами Intel Atom напрямую. Пользовательский интерфейс необходимо адаптировать к устройству назначения. У устройств с экраном высокого разрешения, например у планшетов с экраном разрешением 1280*800 или выше, выделяемая по умолчанию память может не соответствовать требованиям приложения, из-за чего может оказаться невозможно запустить это приложение. Для устройств с экраном высокого разрешения рекомендуется увеличить объем выделяемой по умолчанию памяти.

3.2.2 Портирование приложений Android NDK

Портирование приложений NDK немного сложнее, чем для приложений Dalvik. Все приложения NDK можно разделить на три типа на основе следующих свойств в собственном коде:

• Приложение включает только код C/C++, не связанный с оборудованием
• Приложение использует стороннюю библиотеку динамической компоновки
• Приложение использует код ассемблера, тесно связанный с платформами архитектуры, отличной от IA

Только код C/C++, не связанный с оборудованием

1. Перекомпилируйте код, чтобы приложение успешно выполнялось на платформе Intel Atom.
2. Откройте проект NDK, найдите файл Android.mk, добавьте строку APP_ABI := armeabi armeabi-v7a x86в файл Android.mk и заново скомпилируйте код с помощью сценария ndk-build.
3. Если файл Android.mk не найден, используйте команду ndk-build APP_ABI="armeabi armeabi-v7a x86"для сборки проекта.
4. Заново упакуйте приложение для поддерживаемых платформ x86.

Если собственный код использует стороннюю библиотеку динамической компоновки, общую библиотеку необходимо перекомпилировать в версию x86 для платформы Intel Atom.

Если собственный код включает код ассемблера, тесно связанный с платформами архитектуры, отличной от IA, необходимо переписать код на ассемблере для IA или на C/C++.

4. Рекомендуемые способы разработки собственного кода

4.1 Принудительное выравнивание памяти

Из-за различий между архитектурами, платформами и компиляторами размер данных одних и тех же структур данных может различаться на разных платформах. Без принудительного выравнивания памяти возможны ошибки загрузки или несовпадение объема данных. ^[2]

В следующем примере кода показана разница в размере одной и той же структуре данных на разных платформах:

struct TestStruct {
int mVar1;
long long mVar2;
int mVar3;
};

Это простая структура с тремя переменными: mVar1, mVar2, и mVar3.

mVar1 — целочисленное значение, оно будет занимать 4 байта
mVar2 — длинное целое, оно будет занимать 8 байтbr /> mVar3 — также целочисленное и будет занимать 4 байта.

Сколько места потребуется на платформах ARM и Intel Atom?

Объем скомпилированных данных для платформ ARM и Intel Atom (с использованием компилятора по умолчанию) показан на Рис. 10. На платформе ARM автоматически применяется двойное выравнивание malign, и переменные занимают 24 байта, тогда как на платформе x86 они занимают 16 байт.

Рисунок 10:Выделение памяти при компиляции с флагами по умолчанию

8-байтовая (64-разрядная) переменная mVar2 дает другой результат для TestStruct, поскольку в ARM требуется 8-байтовое выравнивание для 64-разрядных переменных, таких как mVar2. В большинстве случаев это не приводит к неполадкам, поскольку при сборке приложения для платформы x86 вместо ARM требуется полная повторная сборка.

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

Параметр компилятора GCC -malign-double обеспечивает одинаковое выравнивание памяти на платформах x86 и ARM.

Рисунок 11:Выделение памяти при добавлении флагов -malign-double

4.2 Портирование инструкций NEON* в SSE ^[3]

4.2.1 NEON

Технология ARM NEON* используется главным образом в мультимедиа, например в смартфонах и приложениях для телевидения высокой четкости. Согласно документации ARM*, это технология на базе 128-разрядной системы SIMD, представляющая собой расширение процессоров ARM* серии Cortex*–A. Это расширение обеспечивает по крайней мере трехкратное повышение производительности по сравнению с архитектурой ARM* v5 и двукратное — по сравнению с ARM* v6. Дополнительные сведения о технологии NEON см. по адресу: http://www.arm.com/products/processors/technologies/neon.php.

4.2.2 SSE: аналог Intel

SSE — это потоковое расширение SIMD для архитектуры Intel IA. Процессоры Intel Atom в настоящее время поддерживают набор расширений SSSE3 и более ранние версии, но пока не поддерживают SSE4.x. SSE — это 128-разрядная система, обрабатывающая упаковку данных с плавающей запятой. Началом данной модели выполнения следует считать технологию MMX. SSx — новое поколение, заменившее MMX. Дополнительные сведения см. в разделе "Volume 1: Basic Architecture"в Intel 64 and IA-32 Architectures Software Developer’s Manuals. Описание SSE, приведенное в разделе 5.5, содержит инструкции по SSE, SSE2, SSE3 и SSSE3. Эти операции с данными перемещают упакованные значения с плавающей запятой с заданной точностью между регистрами XMM или между этими регистрами и памятью. Регистры XMM служат в качестве замены регистров MMX.

4.2.3 Из NEON в SSE на уровне ассемблера

В руководстве для разработчиков содержатся ссылки на все команды SSE(x), но разработчикам также рекомендуется ознакомиться с различными командами SSE на уровне ассемблера, доступными по этой ссылке: http://neilkemp.us/src/sse_tutorial/sse_tutorial.html. Для доступа к базовой информации и к образцам кода используйте оглавление.

Аналогичным образом, следующее руководство ARM содержит сведения о NEON и небольшие образцы кода ассемблера в разделе 1.4 ”Developing for NEON”: http://infocenter.arm.com/help/topic/com.arm.doc.dht0002a/DHT0002A_introducing_neon.pdf.

Основные различия при сравнении ассемблерного кода NEON и SSE:

• • Порядок следования байтов. Процессоры Intel поддерживают только прямой порядок (от младшего к старшему), а процессоры ARM* поддерживают как прямой, так и обратный порядок (от старшего к младшему). В приведенных примерах в коде ARM* используется прямой порядок байтов, как и необходимо для платформы Intel. Примечание. При компиляции для ARM подразумевается использование определенных флагов. Например, при компиляции для ARM* с помощью GCC* используются флаги –mlittle-endian и –mbig-endian. Дополнительные сведения см. по адресу http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html.
• Степень детализации. В приведенных примерах простого ассемблерного кода сравним инструкцию ADDPS в SSE (Intel) с инструкцией VADD.ix в NEON (например, при x = 8 или 16). В последнем случае уровень детализации обрабатываемых данных более высокий.

Примечание. Разумеется, приведенный список различий не является исчерпывающим. Существуют и другие различия между NEON и SSE.

4.2.4 Из NEON в SSE на уровне C/C++

При преобразовании кода C/C++ NEON в SSE могут возникать самые разные проблемы с API. Всегда помните: предполагается, что встроенный код сборки не используется, а используется только настоящий код C/C++. Инструкции NEON также включают некоторые собственные библиотеки C. Эти инструкции представляют собой код C, но их невозможно выполнить на платформе Intel, их необходимо переписывать.

5. Оптимизация производительности приложений

5.1 Настройка производительности

В процессе кодирования используйте следующие методы оптимизации производительности приложения на платформе Intel Atom.

5.1.1 Используйте встроенные функции

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

Встраивание позволяет сократить издержки в следующих случаях:

• Вызовы функций (включая передачу параметров и размещение адреса объектов в стеке)
• Сохранение фрейма стека вызывающей стороны
• Настройка нового стека
• Передача возвращенного значения
• Восстановление прежнего фрейма стека
• Возврат

5.1.2 Используйте Float вместо Double

В большинстве случаев использование значений типа Float вместо Double ускоряет процесс вычисления данных и позволяет снизить нагрузку на память устройств с процессором Intel Atom.

5.1.3 Многопоточный код

Многопоточное кодирование позволяет использовать функцию гиперпоточности процессоров Intel Atom для повышения производительности всей системы и ускорения обработки данных. Дополнительные сведения о многопоточности см. по адресу: http://www.intel.com/content/www/ru/ru/architecture-and-technology/hyper-threading/hyper-threading-technology.html.

5.2 Создание высокопроизводительных приложений с помощью установки различных флагов компилятора

Сборка собственного кода в приложениях Android выполняется с помощью GCC. При компиляции на платформе Intel Atom рекомендуется добавить следующие флаги:

-march=atom
-msse4
-mavx
-maes

Дополнительные сведения о параметрах компилятора см. в разделе: http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html

6. Заключение

В этом документе описывается разработка и оптимизация приложений для платформ Intel Atom, а также разработка и портирование приложений NDK.

Основные рассмотренные вопросы:

• В большинстве случаев приложения Android можно запускать на платформе Intel Atom напрямую. Для приложений NDK необходимо перекомпилировать собственный код. Если приложение содержит код ассемблера, эту часть кода необходимо переписать.
• Для повышения производительности приложений Android используйте функции архитектуры Intel (IA).
• Добавьте флаги компиляции для данной платформы, чтобы повысить эффективность кода сборки GCC.

Цель

Эта статья представляет собой инструкцию базового уровня по созданию собственных приложений Android* (на базе NDK) для устройств с архитектурой Intel® (IA). Также мы рассмотрим вопрос портирования на платформу IA приложений Android NDK, созданных для устройств с другой архитектурой.

Введение

Приложения Android* могут включать собственный код, созданный с помощью пакета Native Development Kit (NDK). Этот пакет дает разработчикам возможность повторного использования устаревшего кода, создавать код для низкоуровневого взаимодействия с оборудованием, а также реализовывать функции, которые невозможно или затруднительно создавать другими способами.

Эта статья содержит базовые сведения о создании приложений на базе NDK для архитектуры Intel, а также простые примеры портирования приложений на базе NDK на устройства с архитектурой Intel. Для демонстрации мы будем использовать пошаговый сценарий разработки простого приложения.

Мы исходим из того, что вы уже установили среду разработки Android, включая Android SDK и NDK, а также настроили emulator-x86 для тестирования приложений. Дополнительные сведения см. в разделе сообщества Android на веб-сайте Intel. Для простоты среды разработки мы по большей части используем средства Linux* для командной строки.

Создание приложения Android на базе NDK для устройств с архитектурой IA — пошаговая инструкция для простого приложения

Предположим, что у нас есть код, использующий язык C и ассемблер для анализа CPUID (дополнительные сведения о CPUID см. по адресу http://en.wikipedia.org/wiki/CPUID*). Ниже приведен исходный код нашего приложения на языке C: файла cpuid.c (приводится исключительно для демонстрации).

Нам нужно вызвать cpuid_parse из приложения Android (только для демонстрационных целей — функция cpuid_parse предполагает наличие заранее выделенного буфера) и отобразить выходные данные в приложении.

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

1. Создание проекта Android по умолчанию

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

На приведенном выше снимке экрана мы сначала создали каталог labs/lab2, а затем использовали средство командной строки android для создания проекта по умолчанию. Мы указали android-15 в качестве уровня API и назвали наше приложение CPUIdApp с пакетом com.example.cpuid.

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

Ниже приведен снимок экрана эмулятора Android x86 с ICS после выполнения описанного выше процесса.

Теперь можно изменить приложение для использования нативного кода.

2. Вызов нативного кода из Java

В проекте Android по умолчанию создается исходный код Java для типичного проекта вида hello world с заданным пространством имен пакета (например, com.example.cpuid). На приведенном ниже снимке экрана показан исходный код, созданный для основного файла исходного кода Java.

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

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

Это очень простой способ объявления и использования собственных вызовов JNI в коде Java приложений Android. Затем мы будем использовать средство «javah» для создания заглушек заголовков JNI для собственного кода, добавления или изменения нативного кода для соответствия собственным заголовкам JNI.

3. Использование средства javah для создания заглушек заголовков JNI для собственного кода

Теперь нам нужно изменить собственный код так, чтобы он соответствовал спецификации вызовов JNI. Средство javah помогает автоматически создать нужные заглушки заголовков JNI на основе файлов исходного кода Java. Средству javah требуется скомпилированный файл класса Java для создания заголовков. Поэтому мы используем средство ant, чтобы быстро создать файлы классов Java, как показано на приведенном ниже снимке экрана (команда ant debug).

Используйте средство javah для создания заголовка JNI, как показано на снимке экрана (второе выделенное желтым поле). Будет создан каталог jni и заглушка заголовка на основе класса Java. На приведенном ниже снимке экрана показа созданная заглушка заголовка JNI.

Создайте соответствующий файл исходного кода C (com_example_cpuid_CPUIdApp.c) для заголовка, созданного выше. Ниже приведен исходный код:

Мы вызываем собственный код cpuid_parse и возвращаем обработанный буфер в виде строки JNI. Теперь все готово к компиляции собственного кода с помощью NDK x86.

4. Сборка собственного кода с NDK для x86

Дополнительные сведения об установке и использовании NDK для IA см. в разделе сообщества Android на сайте Intel /en-us/articles/ndk-for-ia).

Пакет Android NDK использует системы сборки, для которой требуется настраиваемый файл makefile Android.mk, который должен находиться в папке jni проекта для компиляции собственного кода. В файле Android.mk указываются все файлы собственного исходного кода C/C++ для компиляции, заголовки и тип сборки (например: shared_library).

Ниже приведен код файла makefile Android для нашего проекта (jni/Android.mk)

Это простой сценарий с двумя файлами исходного кода на языке C со сборкой общей библиотеки.

Теперь мы можем выполнить команду ndk-build APP_ABI=x86 для сборки собственного кода и создать общую библиотеку. Система сборки Android также предоставляет дополнительный необязательный файл Application.mk, с помощью которого можно указать дополнительные параметры конфигурации. Например, мы можем указать все поддерживаемые ABI в файле Application.mk. Команда ndk-build создает собственные общие библиотеки для всех архитектур.

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

5. Пересборка, установка и запуск приложения Android NDK для IA

Мы можем использовать команду ant debug clean, чтобы очистить старые файлы сборки, а повторная команда ant debug заново запустит полную пересборку проекта Android. Используйте adb для переустановки приложения на устройстве назначения или эмуляторе x86, как показано на снимке экрана ниже.

На приведенном ниже снимке экрана показан значок приложения в эмуляторе x86 и результат выполнения приложения в эмуляторе x86.

Мы успешно собрали приложение Android на базе NDK.

Использование набора инструментов NDK x86 для портирования существующих приложений на базе NDK на устройства с архитектурой IA

Приложения Android с нативным кодом, как правило, имеют стандартную структуру проекта с папкой jni, содержащей собственный исходный код, и соответствующими файлам сборки Android.mk/Application.mk. В предыдущем разделе мы рассмотрели простой пример с собственным исходным кодом и соответствующим файлом Android.mk.

Пакет Android NDK позволяет сразу указать все целевые ABI в файле Application.mk и автоматически создать собственные общие библиотеки для всех целевых платформ. Система сборки Android автоматически упакует все целевые собственные библиотеки внутри APK, а во время установки диспетчер пакетов Android установит только ту собственную библиотеку, которая соответствует архитектуре платформы назначения.

Можно вызвать ndk-build или указать библиотеку в Application.mk.

Дополнительные сведения см. по адресу http://developer.android.com/sdk/ndk/index.html.

Для портрования существующего приложения Android с нативным кодом, которое в настоящий момент не предназначено для архитектуры x86, применяется процесс изменения приложения для поддержки IA. В большинстве случаев этот процесс довольно прост (как мы рассмотрели выше), если приложение не использует специализированные конструкции или ассемблер исключительно для одной определенной архитектуры. Возможны другие проблемы, например, выравнивание памяти или использование инструкций, применяемых для определенных платформ. Дополнительные сведения см. по адресу: /en-us/articles/ndk-android-application-porting-methodologies.

Выводы

В этой статье мы рассмотрели создание и портирование приложений Android на базе NDK на архитектуру IA. Мы рассмотрели пошаговый процесс создания приложения на базе NDK для IA от начала до конца. Также мы рассмотрели простой процесс портирования существующих приложений Android на базе NDK на архитектуру IA с помощью средств пакета NDK.

Введение

Эти рекомендации помогут вам установить образ Intel® Atom x86 для Android* Jelly Bean, что может пригодиться при разработке на платформе Intel x86.

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

Чтобы установить образ для эмулятора Android x86, требуется пакет Android SDK. Инструкции по установке и настройке пакета Android SDK см. на сайте для разработчиков Android (http://developer.android.com/sdk/).

Замечание: Для ускорения образа x86 для Android можно использовать Intel Hardware Accelerated Execution Manager (HAXM). Дополнительные сведения см. в разделе "Оптимизация"в этом документе.

Известные проблемы:

• Неполадки камеры: сбой камеры при записи видео в системном образе Android 4.2. Эта проблема описана в следующих статьях: http://code.google.com/p/android/issues/detail?id=41227
• Неполадки браузера: на компьютерах с 32-разрядной Windows Vista браузер вызывает произвольные аварийные сбои эмулятора. Эта проблема описана в следующих статьях: http://code.google.com/p/android/issues/detail?id=42733
• Неполадки стабильности: возможен аварийный сбой эмулятора, если значение ОЗУ устройства в AVD равно 1024. В настоящее время Intel ведет дополнительное изучение этой неполадки.

Установка

Загрузка с помощью Android SDK Manager

1. Запустите Android SDK Manager.
2. В разделе Android 4.2 (API 17) выберите Intel x86 Atom System Image:
   
   
3. Затем нажмите кнопку Install Package.
4. Прочитайте лицензионное соглашение с корпорацией Intel. Если вы принимаете условия соглашения, выберите Accept и нажмите кнопку Install.
5. Диспетчер SDK Manager загрузит и извлечет системный образ в нужное расположение в папке Android SDK.

Использование системного образа

1. Запустите Android AVD Manager и создайте новое виртуальное устройство AVD, выбрав для параметра Target значение Android 4.2 – API Level 17, а для параметра CPU/ABI — значение Intel Atom (x86).

   Образ Intel Atom x86 для Android Jelly Bean может использовать аппаратные возможности графического процессора (GPU) для повышения производительности в играх, программах с высокой графической нагрузкой и при обработке элементов пользовательского интерфейса. Для наивысшей производительности установите флажок Use Host GPU при создании образа.

   Примечание:Функциональность и производительность GPU зависит от установленного в компьютере видеоадаптера и графических драйверов. Ускорение GPU необходимо включать для каждого AVD.
   
   

   Примечание:Если значение Intel Atom (x86) параметра CPU/ABI недоступно, проверьте правильность установки системного образа.

2. Нажмите кнопку Create AVD.
3. Виртуальное устройство AVD успешно создано и готово к использованию:
   
   

Оптимизация

Ускорение CPU

Производительность образа Intel Atom x86 для Android Jelly Bean можно повысить с помощью аппаратной виртуализации на основе технологии Intel VT-x.

Если на вашем компьютере установлен процессор Intel с поддержкой VT-x, рекомендуется использовать Intel Hardware Acceleration Execution Manager (HAXM) вместе с этим системным образом. Дополнительные сведения о Intel HAXM см. по адресу http://www.intel.com/software/android.

Примечание:Решение Intel HAXM поддерживает только операционные системы Windows и OS X. Для серверов на базе Linux повышения производительности эмуляторы можно обеспечить с помощью виртуальной машины на базе ядра (KVM). Сведения об установке и настройке KVM в ОС Ubuntu см. в этом руководстве: https://help.ubuntu.com/community/KVM/Installation

<sub>Copyright (C) 2013 Intel Corporation. All rights reserved.
Intel, Atom, and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.
All products, computer systems, dates, and figures specified are preliminary based on current expectations, and are subject to change without notice.
* Другие имена и торговые марки могут быть собственностью третьих лиц.</sub>

Распространение устройств Android* открыло новую эру в области разработки игр: в игры стало возможным привнести «волшебство» сенсорного управления, но при этом создателям игр пришлось столкнуться с целым рядом новых проблем. Во всей истории видеоигр разработчикам приходилось адаптировать свои игры для мышей, клавиатур, джойстиков, других игровых контроллеров. Сенсорные экраны — это еще один интерфейс управления, реализация которого сопряжена с дополнительными затратами на разработку и контроль качества, особенно для существующих игр. Далее мы рассмотрим некоторые часто встречающиеся проблемы и возможные способы их решения.

Основы сенсорного управления

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

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

Механика интерфейса должна быть привычной, естественной и плавной. При этом важно добиться достаточно высокой частоты кадров; более простой, но быстро реагирующий на действия пользователя интерфейс предпочтительнее, чем очень красивый, но запаздывающий интерфейс. Без сенсорного экрана интерфейс меню с частотой 15 кадров в секунду не менее удобен, чем при частоте 30 кадров в секунду. Но при использовании сенсорного экрана низкая частота кадров делает работу с интерфейсом психологически некомфортной, особенно при прокрутке и движениях, где требуется плавность. Кроме того, на большинстве устройств со снижением частоты кадров снижается и способность записывать касания сенсорного экрана, что приводит к ошибкам ввода и дополнительно раздражает пользователей. Но даже и без этого достаточно одного лишь психологического эффекта, чтобы отвратить пользователей от такого интерфейса; недостаточно плавный интерфейс может не сильно отставать по фактическому удобству использования, но привлекательностьсенсорного интерфейса будет существенно ниже. Это недостаток интуитивного принципа работы с сенсорными экранами: пользователь не только сразу же ожидает определенной реакции интерфейса, но и раздражается, если его ожидания не оправдываются.

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

Основы проектирования

При проектировании интерфейсов следует учитывать не только общие принципы психологии пользователей, но и целый ряд более конкретных вопросов. В частности, в каких именно местах пользователь будет касаться экрана, и каким образом будут использоваться эти точки касания? Сколько пальцев одновременно будет использовать игрок? Использовать более двух касаний одновременно нежелательно, если предполагается, что пользователь в ходе игры будет удерживать устройство в руках. В некоторых играх, когда два пользователя играют с одним и тем же планшетом, может потребоваться обработка множества точек касания одновременно, а многие наиболее мощные устройства поддерживают десять или более точек одновременного касания. Тем не менее, некоторые устройства с мультисенсорным вводом поддерживают касание лишь в двух точках одновременно, что может вызвать трудности, если пользователю нужно быстро переместить одну из двух активных точек касания в новое место: если устройство не обнаружит «отпускание» второго касания до нового касания в другом месте, новое касание может быть не зарегистрировано. Определить, поддерживает ли устройство мультисенсорный ввод, нетрудно. Определить поддержку более чем двух одновременных касаний устройствами Android в данный момент весьма непросто, поскольку нужные данные не раскрываются манифестом android.hardware.touchscreen. Надеюсь, со временем это будет доработано.

Если наша игра предназначена не для одного определенного устройства, а для нескольких устройств, следует уделить большое внимание размеру и соотношению сторон экрана. Интерфейс, вполне удобный на экране с соотношением сторон 4:3, может оказаться неудобным на устройстве с экраном 16:9. Может быть непросто приспособить один и тот же интерфейс к экранам всех размеров, от 4 до 12 дюймов. Разные пользователи могут держать устройства в руках по-разному; большие пальцы могут естественным образом касаться экрана в разных местах. Места сенсорного управления, удобные для планшетов, могут быть неудобными для телефонов (или наоборот). При этом руки пользователя ни в коем случае не должны загораживать основной экран игрового процесса.

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

Отсутствие обратной связи: кнопки без тактильной реакции

До недавнего времени интерфейс всех без исключения видеоигр и компьютерных игр имел одну важную общую черту: когда пользователь нажимал на клавишу, он на ощупь чувствовал нажатие клавиши; это позволяло немедленно узнать, что команда пользователя была дана, даже до получения звуковой и визуальной реакции игры. Одна из серьезнейших проблем создания игр с сенсорным управлением заключается в том, что эта проверенная, удобная, привычная и безотказная механическая связь заменяется гладким стеклом, не обеспечивающим никакой тактильной обратной связи. Рассмотрим один из наиболее очевидных недостатков этого изменения: все клавиши на клавиатурах и кнопки на джойстиках и других игровых контроллерах имеют естественные границы; пользователь без труда наощупь определяет эти границы, что помогает поддерживать контакт с интерфейсом и с безупречной точностью выбирать, какие именно кнопки следует нажимать. Кроме того, обычно между соседними клавишами или кнопками есть некоторый промежуток, что дает возможность пользователям естественным образом нажимать точно в середину клавиш и кнопок и, тем самым, повышает точность. Игрок лишается непосредственного ощущения нажатия кнопки и прекращения ее движения, когда она доходит до упора в нажатом положении; поэтому игрок лишается уверенности и определенности в своих действиях; для получения обратной связи ему остается полагаться лишь на частоту опроса устройства и на реагирование игры. Если опираться только на визуальную и акустическую обратную связь, увеличивается задержка между каждым действием и реакцией на него; возникает запаздывание, значительно затрудняющее управление в некоторых типах игр. Наиболее строгие требования к клавишам и кнопкам джойстиков действуют в играх с рукопашными боями и различными единоборствами, поскольку приходится очень быстро обрабатывать команды нескольких игроков. Впрочем, и в классические шутеры, и в аркады намного удобнее играть, используя кнопки и клавиши с тактильной обратной связью и мгновенной реакцией.

Каким же образом добиться аналогичного удобства от гладкой стеклянной панели? На момент написания этой статьи идеального решения не существовало; шел лишь процесс адаптации. Все потребительские устройства, предназначенные для игр, по-прежнему оснащаются «настоящими» кнопками, но на большинстве устройств с сенсорными экранами таких кнопок нет. Некоторые платформы поддерживают API для применения внешних игровых контроллеров, как проводных, так и подключаемых по интерфейсу Bluetooth. Это вполне разумное решение. Тем не менее, если мы стремимся распространить наши игры в сектор исключительно сенсорных устройств, наши игры должны быть полностью совместимы с сенсорным управлением. Для решения этой задачи можно использовать несколько стратегий.

Во-первых, на некоторых устройствах можно использовать вибрацию в качестве альтернативы тактильной обратной связи. Вибрацию поддерживают почти все телефоны и ряд планшетов. Такая обратная связь удобна при работе с меню и другими элементами интерфейса; она обеспечивает «ощущение» подтверждения того или иного действия без звука (пользователь может играть в тихом общественном месте). Но это решение ни в коем случае нельзя считать панацеей: вибрация поддерживается не всеми устройствами, уровень обратной связи ограничивается слабой вибрацией, да и задержки существенно больше, чем при нажатии обычных кнопок.

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

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

Ряд преимуществ есть и у механики «длительного касания», когда пользователь касается и удерживает нажатой определенную область экрана до какого-либо события. Это может быть, например, контекстное меню или дополнительные параметры. Как правило, длительные касания не очень интуитивны, поэтому лучше оставить их для второстепенных функций игры. Впрочем, они могут быть удобны для опытных игроков; с помощью длительных касаний можно фиксировать дополнительное подтверждение для определенных типов игр. Длительное касание должно сопровождаться правильно подобранным использованием вибрационной, акустической и визуальной обратной связи, чтобы сообщить пользователю об успешности выполненной операции (особенно для таких действий как перетаскивание объектов).

Различное оборудование

На некоторых платформах эта проблема имеет большее значение, на других — меньшее, но эта проблема в любом случае нуждается в решении, если ваша игра предназначается более чем для одного семейства устройств. За последние несколько лет устройства Android стали более схожими, но все равно существуют значительные различия в качестве сенсорных контроллеров, в количестве одновременно обрабатываемых точек касания, в длительности задержек сенсорного управления и звуковой обратной связи, а также в прочих особенностях оборудования. Для гибридных устройств, таких как смартфоны с клавиатурами, следует подумать об обработке событий, отправляемых ОС Android при физическом включении клавиатуры (ее выдвижении и пр.). Это позволит плавно перейти от использования экранной клавиатуры к вводу с аппаратной клавиатуры с более полным использованием игрового экрана.

Разработчики музыкальных игр, где большое значение имеет темп и скорость обработки ввода в строго заданное время, должны учитывать, что внутренние аудиосистемы некоторых платформ и устройств работают с длительными задержками, из-за чего синхронизация музыки и действий будет крайне затруднена для пользователей таких устройств. На некоторых платформах низкоуровневые параметры API (например, «встроенные» действия Android) позволяют ускорить обработку ввода и снизить задержки звуковой обратной связи при использовании определенных типов оборудования или в будущих версиях ОС. Со временем вопросы синхронизации звука, связанные с особенностями платформ и оборудования, будут решены путем расширенного тестирования и доработок со стороны производителей устройств, но пока разработчики игр должны отдавать себе отчет о возможных проблемах.

Итоговые тезисы

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

У пользователя должно все получаться, ему должно быть удобно и нетрудно.

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

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

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

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

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

Перспективы

Несколько мыслей на будущее. Мир мобильных устройств быстро развивается. В ближайшем будущем появятся и новые интерфейсы, и новые сценарии использования. Уже сейчас можно подключить обычный телефон к телевизору по интерфейсу HDMI, используя при этом телевизор в качестве монитора, а телефон в качестве контроллера. Это станет еще удобнее с развитием беспроводных стандартов HDMI. Некоторые телефоны уже оснащаются компактными проекторами. Теоретически можно играть на большом экране, имея телефон, светлую стену в качестве экрана и компактный игровой контроллер с интерфейсом Bluetooth. Существуют и мощные ТВ на базе Android с различными приставками; все это поможет расширить рыночный охват вашей игры.

Кроме того, возможно, что сами «экраны» могут смениться виртуальными интерфейсами, которые могут отображаться с помощью особых очков или даже проецироваться на сетчатку глаза пользователя. Возможные разновидности «надеваемых» компьютеров заслуживают упоминания, поскольку они позволяют использовать «жестовые» интерфейсы наподобие Xbox* Kinect*. Такие интерфейсы будут совместимы с сенсорным управлением, но с еще меньшим объемом физической обратной связи (без вибрации и т. п.).

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

Об авторе:

Джон Бергман (John Bergman) — исполнительный директор компании Guild Software Inc. Джон — опытный разработчик, дизайнер и руководитель онлайн-игр, он основал компанию Guild Software в 1998 году с единственной целью: создавать онлайн-игры нового поколения. Компания Guild Software разработала с нуля полнофункциональный «движок» для MMO-игр, а в 2004 году с успехом выпустила игру «Vendetta Online», которая поступила в продажу во всех крупных розничных сетях.

Позже эта игра прославилась как первая традиционная компьютерная MMO-игра, перенесенная на мобильную платформу; в 2011 году партнеры по реализации этого проекта, корпорации Verizon и Motorola, провели обширную кампанию телевизионной рекламы. Вне работы Джон занимается обучением начинающих разработчиков игр, консультирует перспективные новые проекты и участвует в работе различных связанных с играми консультативных советов в нескольких университетах.

Notices

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark and MobileMark, are measured using specific computer systems, components, software, operations, and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you infully evaluating your contemplated purchases, including the performance of that product when combined with other products.

Any software source code reprinted in this document is furnished under a software license and may only be used or copied in accordance with the terms of that license.

Intel and the Intel logo are trademarks of Intel Corporation in the US and/or other countries.

Copyright © 2012 Intel Corporation. All rights reserved.

*Other names and brands may be claimed as the property of others.

.

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

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

1.1Отладка JTAG

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

Дополнительные сведения о JTAG и его использовании в отладке современного ПО см. в статье Рэнди Джонсона и Стюарта Кристи "JTAG 101; IEEE 1149.x and Software Debug".

С точки зрения производителей устройств, разработчиков приложений и драйверов, понимание взаимодействия между драйверами и программными компонентами в различных подсистемах микросхем и устройств важно для определения стабильности платформы. С точки зрения проверки микросхем низкоуровневый комплект ПО обеспечивает тестовую среду, позволяющую сымитировать факторы нагрузки, которым платформа будет подвергаться при ее реальном использовании. Для работы с современными системами требуется понимать, как работают все их компоненты вместе в реальной обстановке; положительных результатов тестирования отдельных компонентов недостаточно. Именно на этом уровне и используется отладка на базе 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), Last Branch Record (LBR) и Architectural Event Trace (AET) с помощью порта Intel XDP, совместимого с JTAG.

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

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

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

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

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

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

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

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

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

Рис. 1. Преобразование логического адреса в линейный

Для преобразования логического адреса в линейный адрес процессор выполняет следующие действия:

1. С помощью смещения в селекторе сегмента находит дескриптор сегмента в таблице GDT или LDT и считывает его в процессор. (Этот шаг требуется только в случае загрузки нового селектора сегмента в сегментный регистр.)
2. Проверяет дескриптор сегмента, чтобы выяснить наличие прав доступа и диапазон сегмента и убедиться, что сегмент доступен и смещение находится в пределах сегмента.
3. Добавляет базовый адрес сегмента из дескриптора сегмента к смещению для получения линейного адреса.
4. Если страничное преобразование не используется, процессор непосредственно сопоставляет линейный адрес физическому (то есть линейный адрес выводится на шину адреса процессора). Если линейное адресное пространство разбито на страницы, в процесс преобразования линейного адреса в физический добавляется второй уровень.

В защищенном режиме архитектура Intel позволяет либо непосредственно сопоставить линейное адресное пространство большому объему физической памяти (например, в 4 ГБ ОЗУ), либо косвенно (с помощью страничной адресации) сопоставить его меньшему объему физической памяти и дискового пространства. Последний метод сопоставления линейного адресного пространства часто называют виртуальной памятью или виртуальной памятью со страничным преобразованием адресов по требованию.
При использовании страничного преобразования процессор делит линейное адресное пространство на страницы фиксированного размера (обычно 4 Кб), которые сопоставляются физической памяти и/или дисковому пространству. Когда программа (или задача) ссылается на логический адрес в памяти, процессор преобразует этот адрес в линейный адрес, а затем с помощью механизма страничной адресации преобразует линейный адрес в соответствующий физический адрес. Если страница, содержащая линейный адрес, не загружена в настоящий момент в физическую память, процессор генерирует исключение по отсутствию страницы (#PF). В этом случае обработчик исключений обычно дает указание операционной системе или исполняемой программе загрузить эту страницу из дискового хранилища в физическую память (в процессе операции другая страница может быть записана из физической памяти на диск). После загрузки страницы в физическую память значение, возвращенное обработчиком исключений, инициирует повторный запуск инструкции, в результате которой было сгенерировано исключение. При сопоставлении линейных адресов физическому адресному пространству и при генерации исключений по отсутствию страницы (если это необходимо) процессор использует информацию из каталогов страниц и таблиц страниц, сохраненных в памяти.
Страничное преобразование отличается от сегментации тем, что страницы имеют одинаковый размер. Размер сегментов обычно совпадает с размером содержащихся в них фрагментов кода или структур данных, тогда как размер страниц фиксирован. Если для преобразования адресов используется только сегментация, структура данных, загруженная в память, будет находиться в памяти целиком. Если используется страничное преобразование, структура данных может быть частично загружена в память, а частично оставаться на диске.
Чтобы уменьшить число тактов шинного обмена, необходимых для преобразования адреса, последние использованные записи каталога страниц и таблицы страниц загружаются в кэш-память процессора в компоненты, называемые буферами быстрого преобразования адресов (TLB). Буферы TLB обеспечивают выполнение большинства запросов чтения в текущем каталоге страниц и таблицах страниц без расходования тактов шинного обмена. Дополнительные такты шинного обмена требуются только тогда, когда в буферах TLB не содержится запись таблицы страниц; обычно это происходит в том случае, если страница не использовалась долгое время.

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

Еще одно различие между архитектурами заключается в обработке системных прерываний. Например, в ARM существует готовый набор аппаратных прерываний в зарезервированном адресном пространстве с 0x0 по 0x20. Эти расположения содержат инструкции переходов к обработчику прерываний. В архитектуре Intel используется выделенный контроллер аппаратных прерываний. Аппаратные прерывания недоступны напрямую в адресном пространстве памяти процессора, но обрабатываются путем доступа к контроллеру прерываний Intel 8529. Преимущество такого подхода состоит в том, что обработчик прерываний поддерживает прямую обработку прерываний ввода-вывода для подключенных устройств. В архитектурах без выделенного контроллера прерываний для решения этой задачи обычно применяется перегрузка прерывания IRQ более сложным обработчиком.

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

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

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

Рис. 2. Регистры устройства в окне битовых полей

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

Кроме того, если решение для отладки предоставляет доступ к трассировке инструкций на базе Last Branch Storage (LBR), эта возможность в сочетании со всеми обычными функциями управления выполнением в отладчике JTAG позволяет принудительно останавливать выполнение при исключениях и анализировать поток событий исключения в обратной последовательности, что позволяет определять причину неполадок при выполнении.

Записи Last Branch Record можно использовать для трассировки выполнения кода начиная с нужной точки сброса. Поскольку данные о прерывании выполнения кода сохраняются в этих записях MSR, отладчики могут реконструировать выполненный код, считав адреса To и From, получив доступ к памяти между этими двумя адресами и выполнив дизассемблирование кода. Дизассемблированный код обычно отображается в графическом пользовательском интерфейсе трассировки в интерфейсе отладчика. Это может помочь выяснить, какой код выполнялся перед прерыванием SMI (System Management Interrupt) или другим исключением, если в месте прерывания настроена точка останова.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 Технология гиперпоточности Intel®

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

4 Компоненты микросхемы ЦП и взаимодействие между ядрамиMulti-Core

Из-за взаимодействия десятков программных и аппаратных компонентов внутри одной микросхемы существенно усложняется поиск причин неполадок при отладке. Взаимодействие между различными программными компонентами часто зависит от времени. При отладке кода со взаимодействием между компонентами обычно невозможно просто пошагово выполнять один определенный компонент. Традиционная отладка с помощью printf также неэффективна в данном случае, поскольку изменения при отладке могут отрицательно повлиять на временные параметры и привести к еще более серьезным проблемам, действуя наподобие физического принципа неопределенности Гейзенберга (согласно этому принципу, в частности, любые попытки измерения скорости и положения частицы сами по себе вносят возмущения в движение частицы и непредсказуемо меняют ее скорость, т. е. наблюдение характеристик меняет эти характеристики).

4.1.Отладка трассировки событий

Существует множество программных средств статического анализа и основанных на них технологий трассировки событий, которые помогают решить эту задачу. Они имеют общий принцип работы, состоящий в использовании буферной памяти DRAM небольшого размера — в эту память загружаются данные события во время их создания, а затем используется какой-либо механизм протоколирования, записывающий результат трассировки в файл журнала. Мониторинг трассировки данных может выполняться в режиме реального времени при непосредственном взаимодействии с API протоколирования данных трассировки или в автономном режиме с использованием различных средств просмотра трассировки для анализа сложных взаимосвязей между программными компонентами. Наиболее распространены три таких программных средства — LTTng*, Ftrace* и SVEN*.

Далее приведена таблица сравнения этих трех средств, предназначенных в основном для операционных систем типа Linux* и поэтому совместимых с Android*.

Рис. 5. Различные решения для трассировки событий

Дополнительные сведения см. на соответствующих веб-сайтах:

• LTTng* Project: https://lttng.org/
• Ftrace*: http://elinux.org/Ftrace

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

Набор AppMobi XDK предоставляет средства разработки кроссплатформенных приложений, с помощью которых разработчики могут с легкостью создавать приложения HTML5 и JavaScript* для различных мобильных платформ. В этой статье мы рассмотрим создание гибридных приложений для Android, использующих API JavaScript из состава AppMobi XDK.

Жизненный цикл разработки программного обеспечения с помощью AppMobi XDK

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

[Источник: http://appmobi.com/]

Можно создавать приложения в виде веб-приложений на основе HTML5, JavaScript и CSS либо создавать гибридные приложения, чтобы использовать различные возможности оборудования (акселерометр, камеру и пр.). Можно одновременно тестировать приложение с помощью имитаторов различных типов устройств Android и iOS с различной пространственной ориентацией. Также можно протестировать приложение и на настоящем устройстве с помощью Wi-Fi* или облачной службы размещения приложений. Убедившись в работоспособности приложения, можно развернуть его в различных магазинах приложений, таких как Android Marketplace или Apple App Store.

Установка AppMobi XDK

Установить AppMobi XDK можно из магазина Chrome. Для загрузки и установки AppMobi XDK потребуется создать учетную запись AppMobi на сайте appmobi.com. Кроме того, необходимо установить Google Chrome* и Java* 6. Пакет XDK запускается в виде веб-приложения вместе с локальным веб-сервером, который запускается в качестве приложения Java.

После установки XDK можно запустить это приложение, щелкнув значок XDK в браузере Chrome. Обратите внимание, что AppMobi XDK не заменяет уже используемые вами средства веб-разработки. Это единая платформа для сборки, тестирования и развертывания веб-приложений и гибридных приложений, позволяющая при этом по-прежнему использовать привычную интегрированную среду разработки.

Разработка первого кроссплатформенного приложения

Развертывание приложений в среде AppMobi XDK очень просто и удобно, поскольку все средства разработки, тестирования и развертывания собраны в едином месте. При этом можно продолжать использовать привычные средства разработки, например среду Eclipse*, для разработки веб-приложений, поскольку AppMobi XDK не заменяет эти средства. Также предусмотрен редактор на случай, если на компьютере еще нет настроенной среды разработки. В этом разделе мы создадим проект акселерометра, который будет использовать различные API JavaScript AppMobi для доступа к акселерометру на устройстве Android. Можно добавить и другие нужные функции, но в этой статье мы будем использовать простую структуру для демонстрации удобства использования AppMobi XDK и API.

Шаг 1

Для создания первого приложения установите и запустите XDK, выполнив описанные выше действия. После запуска XDK на экране появится интерфейс, показанный ниже. Нажмите кнопку Start Menu в левом верхнем углу, как показано.

Шаг 2

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

Шаг 3

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

Шаг 4

Выберите функцию Accelerometer. При этом в приложение будут добавлены необходимые фрагменты кода для доступа к датчикам движения, которыми оборудованы смартфоны.

Шаг 5

Теперь в проект добавлена поддержка акселерометра. Можно использовать API JavaScript для работы с этим устройством. В этом примере мы асинхронно, с регулярными интервалами проверяем изменения значений датчиков устройства. AppMobi включает объект Accelerometer с методом watchAcceleration, который асинхронно получает значения акселерометра с заданными интервалами по таймеру.

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

В коде видно, что сразу после загрузки страницы и активации appMobi можно начать следить за обработчиком событий onDeviceReadyAccel, который проверяет изменения датчика движения с помощью метода AppMobi.accelerometer.watchAcceleration.

Акселерометр выдает значения для координат x, y и z в диапазоне от -1 до 1. В примере по умолчанию используются значения x = 0, y = -1 и z = 0. Теперь можно протестировать поведение приложения на нескольких платформах, выбрав нужное устройство в разделе Device Emulation справа. Поскольку наша задача — развернуть гибридное приложение на устройстве Android, выберите в списке Droid.

Если нужно, можно смоделировать поведение программы на настоящем устройстве путем изменения пространственной ориентации устройства. Для этого используйте вкладку Accelerometer справа и измените значения координат x, y и z путем изменения наклона устройства. На приведенном ниже рисунке видно, что имитатор моделирует работу конечного пользователя с устройством путем изменения положения устройства в пространстве с отображением соответствующих изменений значений x, y и z.

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

Создание приложения appMobi для Android

Итак, мы разработали первое кроссплатформенное приложение. Теперь необходимо собрать его для нужной платформы. В appMobi эта возможность реализована с помощью облачной службы упаковки appHub. В appHub можно собирать приложения для множества платформ, таких как iOS, Android, nook*, Amazon и пр. Также можно собирать веб-приложения, работающие через веб-магазин, например Chrome. В этом разделе описывается сборка приложений для устройств Android.

Шаг 1

Запустите процесс сборки, нажав кнопку сборки в правом верхнем углу XDK. Обратите внимание, что при первой сборке приложения необходимо сперва отправить его в облачную службу. При последующей сборке можно использовать параметр Build only.

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

В инструкциях видно, что для системы сборки Android требуется настроить Android Push. Подробные инструкции по настройке Google Cloud Messaging приведены по адресу: http://www.appmobi.com/amdocs/lib/appMobi_Walkthrough_v2_GCM_Push.pdf

Введите идентификатор проекта и ключ API из конфигурации GCM в центре управления AppHub Control Center. Теперь приложение готово к сборке. Нажмите кнопку Build App Now, чтобы приступить к сборке. После успешного завершения сборки откроется показанное ниже диалоговое окно, в котором можно загрузить APK-файл, отправить приложение по электронной почте на устройство, отправить приложение в магазин Android Marketplace или переместить приложение на устройство Android с помощью Android SDK.

Заключение

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

Дополнительные материалы:

1: Справочник по API JavaScript AppMobi. Изучите API, обеспечивающие доступ приложения к ряду аппаратных функций: Camera, Geolocation, Multi-touch, Canvas и пр.: http://dev.appmobi.com/documentation/jsAPI/index.html

2: Написание приложений из собственного кода с помощью AppMobi: http://www.appmobi.com/amdocs/lib/Article-DevelopingOutsideXDK.pdf

3: Школа разработки приложений HTML5: http://dev.appmobi.com/?q=node/66

4: Лучшие методики создания приложений с помощью AppMobi: http://www.appmobi.com/documentation/content/Articles/Article_UsingBestPractices/index.html?r=2722

Примечания

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.

Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.

The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.

Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.

Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark and MobileMark, are measured using specific computer systems, components, software, operations, and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products.

Any software source code reprinted in this document is furnished under a software license and may only be used or copied in accordance with the terms of that license.

Intel® и логотип Intel являются товарными знаками корпорации Intel в США и в других странах..

© Intel Corporation, 2012. Все права защищены.

* Другие наименования и торговые марки могут быть собственностью третьих лиц.

Удаленная отладка приложений в ОС Android *

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® AtomTM практически не отличается от отладки другой архитектуры.

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

Настройка ADB*

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

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

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

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

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

В файле AndroidManifest.xmlдобавьте android:debuggable="true"в элемент <application>.

Примечание:Если вручную включить отладку в файле манифеста, не забудьте отключить ее перед сборкой приложения для выпуска (опубликованное приложение, как правило, не должно иметь возможность отладки).

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

На устройстве откройте Settings > Applications > Developmentи установите флаг USB debugging (в версии Android 4.0 он находится в меню Settings > Developer options).

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

o   В Windows нужно установить драйвер USB для ADB. Руководство по установке и ссылки на драйверы OEM-производителей см. в документе OEM USB Drivers.

o   Для Mac OS * X устанавливать дополнительные драйверы не нужно. Пропустите этот шаг.

o   При использовании Ubuntu * Linux нужно добавить файл правил udev, содержащий конфигурацию USB для каждого типа устройств, которые следует использовать при разработке. В файле правил каждый изготовитель устройств обозначается уникальным идентификатором с помощью свойства ATTR{idVendor}. Список идентификаторов изготовителей см. в разделе Список идентификаторов изготовителей USBниже. Настройка обнаружения устройств в Ubuntu Linux:

Войдите в систему с правами root и создайте файл: /etc/udev/rules.d/51-android.rules.

Добавьте в файл каждого изготовителя, используя следующий формат:
SUBSYSTEM=="usb", ATTR{idVendor}=="<vendor id>", MODE="0666", GROUP="plugdev"

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

Теперь выполните команду:
chmod a+r /etc/udev/rules.d/51-android.rules

При подключении через USB можно узнать, подключено ли устройство, выполнив команду ADB 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/ *.

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

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

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

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

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

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

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

TЗатем сервер устанавливает подключения ко всем запущенным эмуляторам и устройствам. Для обнаружения эмуляторов и устройств сервер проверяет все порты с нечетными номерами в диапазоне от 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, поэтому можно управлять любым эмулятором или устройством с любого клиента (или с помощью сценария).

Запуск ADB 

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

$ adb shell

Основные команды 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

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

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

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

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

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

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

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

Отладка нативного кода C/C++ с помощью отладчика GDB* - The GNU Project Debugger 

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

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

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

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

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

PROG_PATH   полный путь к исполняемому файлу в целевой системе (например: /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 (for Linux)

prebuilt/darwin-x86/toolchain-eabi-4.x.x/bin/i686-android-linux-gdb (for 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

absolute-это путь к дереву исходного кода.

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

Подключитесь к устройству с помощью команды GDB:

(gdb) target remote :1234

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

Теперь можно начать отладку встроенного кода C/C++ на платформе Android * с помощью GDB привычным образом.

Дополнительные сведения см. в документации к GDB* - The GNU Project Debugger.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действуют все правила и инструкции, приведенные по адресу http://developer.android.com/guide/developing/debugging/index.html.

Удаленная отладка приложений в ОС Android *

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® AtomTM практически не отличается от отладки другой архитектуры.

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

Настройка ADB*

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

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

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

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

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

В файле AndroidManifest.xmlдобавьте android:debuggable="true"в элемент <application>.

Примечание:Если вручную включить отладку в файле манифеста, не забудьте отключить ее перед сборкой приложения для выпуска (опубликованное приложение, как правило, не должно иметь возможность отладки).

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

На устройстве откройте Settings > Applications > Developmentи установите флаг USB debugging (в версии Android 4.0 он находится в меню Settings > Developer options).

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

o   В Windows нужно установить драйвер USB для ADB. Руководство по установке и ссылки на драйверы OEM-производителей см. в документе OEM USB Drivers.

o   Для Mac OS * X устанавливать дополнительные драйверы не нужно. Пропустите этот шаг.

o   При использовании Ubuntu * Linux нужно добавить файл правил udev, содержащий конфигурацию USB для каждого типа устройств, которые следует использовать при разработке. В файле правил каждый изготовитель устройств обозначается уникальным идентификатором с помощью свойства ATTR{idVendor}. Список идентификаторов изготовителей см. в разделе Список идентификаторов изготовителей USBниже. Настройка обнаружения устройств в Ubuntu Linux:

Войдите в систему с правами root и создайте файл: /etc/udev/rules.d/51-android.rules.

Добавьте в файл каждого изготовителя, используя следующий формат:
SUBSYSTEM=="usb", ATTR{idVendor}=="<vendor id>", MODE="0666", GROUP="plugdev"

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

Теперь выполните команду:
chmod a+r /etc/udev/rules.d/51-android.rules

При подключении через USB можно узнать, подключено ли устройство, выполнив команду ADB 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&gt, а затем отобразить список командой ls -l /dev/bus/usb/ *.

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

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

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

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

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

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

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

TЗатем сервер устанавливает подключения ко всем запущенным эмуляторам и устройствам. Для обнаружения эмуляторов и устройств сервер проверяет все порты с нечетными номерами в диапазоне от 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, поэтому можно управлять любым эмулятором или устройством с любого клиента (или с помощью сценария).

Запуск ADB 

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

$ adb shell

Основные команды 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

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

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

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

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

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

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

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

Отладка нативного кода C/C++ с помощью отладчика GDB* - The GNU Project Debugger 

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

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

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

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

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

PROG_PATH   полный путь к исполняемому файлу в целевой системе (например: /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 (for Linux)

prebuilt/darwin-x86/toolchain-eabi-4.x.x/bin/i686-android-linux-gdb (for 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

absolute-это путь к дереву исходного кода.

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

Подключитесь к устройству с помощью команды GDB:

(gdb) target remote :1234

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

Теперь можно начать отладку встроенного кода C/C++ на платформе Android * с помощью GDB привычным образом.

Дополнительные сведения см. в документации к GDB* - The GNU Project Debugger.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Действуют все правила и инструкции, приведенные по адресу http://developer.android.com/guide/developing/debugging/index.html.

Это техническое руководство по сборке Cocos2D-HTML5 JSBinding для устройств Android с архитектурой x86. Cocos2D-HTML5 — это платформа веб-игр с открытым исходным кодом, распространяемая по лицензии Массачусетского технологического института. Это версия проекта Cocos2d-x на HTML5. Цель разработки Cocos2d-html5 — обеспечить кроссплатформенную совместимость Cocos2d между браузерами и встроенными приложениями. Используя платформу Cocos2d-html5, можно разрабатывать игры на Javascript с помощью API, полностью совместимого с Cocos2d-iPhone. Cocos2d-html5 также поддерживает выполнение игрового кода в привязке Cocos2d к Javascript без изменений или с незначительными изменениями.

Для ознакомления с этим руководством необходим опыт в разработке приложений NDK для устройств Android, особенно с архитектурой X86.

1）Подготовка среды сборки

Необходимо: Eclipse, ADT, CDT, Android SDK и Android NDK. Также следует отметить UDE — удобную среду разработки в CMCC. Эта среда поддерживает кроссплатформенные разработку, отладку и компиляцию, а в ближайшем будущем будет поддерживать разработку игр.

Для компиляции проекта Cocos2D-HTML5 Jsbinding также требуется Cygwin. Это решение предоставляется компанией Redhat.

ADT  ，http://developer.android.com/tools/sdk/eclipse-adt.html
CDT  ，http://www.eclipse.org/cdt/
SDK  ，http://developer.android.com/sdk/index.html
NDK  ，http://developer.android.com/tools/sdk/ndk/index.html
UDE  ，http://dev.10086.cn/app/local/
Cygwin，http://www.cygwin.com/
Распакуйте архив cocos2d-2.1beta3-x-2.1.1.zip в папку D:\Game\SDK\. Это базовая папка для среды сборки JS Binding.

Распакуйте архив android-ndk-r8.zip в папку D:\Game\NDK, а затем добавьте этот путь в системную среду. Также можно добавить этот путь в среду Cygwin.

Добавьте новую системную среду, назовите ее NDK_ROOT, а в качестве ее значения задайте D:\Game\NDK\android-ndk-r8。

Гибридным приложениям требуется интерпретатор для обработки кода JS. JavaScript и SpiderMonkey — популярные интерпретаторы JavaScript для разработчиков.

Поскольку JIT-компиляция может повысить производительность JavaScript, разработчикам игр на HTML5 важно уделить особое внимание вопросам производительности.

Судя по всему, все используют JavaScriptCore, но при этом все, фактически, нарушают условия лицензии LGPL (даже корпорация Apple нарушает условия этой лицензии). Мы попробовали найти другие виртуальные машины JavaScript и решили, что SpiderMonkey нас вполне устраивает. 

https://developer.mozilla.org/en/docs/SpiderMonkey
SpiderMonkey — это обработчик JavaScript корпорации Mozilla, написанный на C/C++.

2）Копирование файла ИЛИ компиляция с помощью Cygwin

Можно использовать любой из вариантов.

Cygwin — очень мощное средство для работы над кодом C++. Для отладки исходного кода можно использовать gdb. Другой способ сборки — с помощью сценария build_native.sh. Это удобнее, чем использовать Android NDK, дополненный компилятором Cygwin. Однако по возможностям этот способ не превосходит Cygwin.

2.A）Копирование файла

Ниже представлен пакетный сценарий. Если требуется использовать этот сценарий для сборки других проектов, нужно лишь изменить значения EngineHome и SamplesApp.

D:\Game\Home\Readme\MoonWar>type MoonWar_Apk.cmd
set EngineHome=D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1
set SamplesApp=MoonWarriors
set AndroidDir=%EngineHome%\samples\Javascript\%SamplesApp%\proj.android
set SamplesDir=%EngineHome%\samples\Javascript\Shared\games\%SamplesApp%
set BindingDir=%EngineHome%\scripting\javascript\bindings\js

echo %EngineHome%
echo %SamplesApp%
echo %AndroidDir%
echo %SamplesDir%
echo %BindingDir%

cd /d %AndroidDir%
if exist assets rmdir /s /q assets
mkdir assets
cd assets
mkdir res
mkdir src

xcopy /s /y %SamplesDir%\res res
xcopy /s /y %SamplesDir%\src src
copy /y %SamplesDir%\*.js .
copy /y %BindingDir%\*.js .

2.B）Компиляция с помощью Cygwin

$ cd "D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1"
$ chmod -R 755 *

$ cd "D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android"
$ ./build_native.sh
please define NDK_ROOT

$ vi ~/.bashrc
export NDK_ROOT='D:\Game\NDK\android-ndk-r8'
:q!

$ . ~/.bashrc
$ env | grep NDK
NDK_ROOT=D:\Game\NDK\android-ndk-r8

$ ./build_native.sh
"Compile++ thumb : moonwarriors_shared <= main.cpp
"Compile++ thumb : moonwarriors_shared <= AppDelegate.cpp
......

ld.exe: ./obj/local/armeabi/js_static.a: No such file: Permission denied
collect2: ld returned 1 exit status

$ ls -la ./obj/local/armeabi
$ chmod -R 755 ./obj/local/armeabi/*.a

$ ./build_native.sh

$ chmod -R 755 assets

3）Создание проекта игры, компиляция связанных библиотек

Шаг 3.A обязателен; затем можно на выбор использовать 3.B или 3.C, поскольку для проекта эти шаги обладают одинаковой функциональностью. 

3.A） Создание проекта

Создайте новый проект в Eclipse. File -> new -> Project -> Android -> Android Project from Exsiting Code、перейдите в папку
D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android

Затем Project -> Clear -> Clear, выберите MoonWarriors. Красным цветом будет выделена ошибка в папке src. Мы отследили проблему：

Can’t import org.cocos2dx.lib  Line26
Cocos2dxActivity can’t be a class Line30
Cocos2dxActivity can’t be a class Line33

3.B） Добавление связанной библиотеки путем компиляции исходного кода.

Щелкните правой кнопкой мыши проект, созданный на шаге 3.A. Выберите Reference -> Android -> Library. Ссылка указывает на проект java. Затем мы собираем библиотеку, на которую будем ссылаться, путем компиляции исходного кода.

Необходимо собрать библиотеку Java cocs2d-x.

Import export library -> File -> New -> Project -> Android -> Android Project from Exsiting Code、Перейдите в папку

D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\cocos2dx\platform\android\java

（Attached Pic MoonWar_01.jpg）
 Примечание. Изображение было записано в китайской версии; для остальных версий Eclipse оно должно быть схожим. 

3.C） Добавление связанной библиотеки путем копирования файла.

Если решение, указанное в шаге 3.B, по какой-либо причине не подходит, также можно добавить библиотеку путем копирования файла. Можно скопировать готовую JAR-библиотеку в папку проекта в качестве зависимой библиотеки. Такой подход заменяет действия, описанные в шаге 3.B.

Откройте папку  D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\cocos2dx\platform\android\java
и перетащите файл в папку src в проекте Eclipse. При этом на экране должен появиться значок «+». Выберите «Copy files and folders» (Копировать файлы и папки), при появлении запроса «Override?» (Заменить?) выберите «Yes for all» (Да, для всех).

Затем выберите Import export library -> File -> New -> Project -> Android -> Android Project from Exsiting Code、Перейдите в папку

D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\cocos2dx\platform\android\java

3.D） Проверка зависимой библиотеки.

Снова проверьте проект MoonWarriors: теперь ошибка должна исчезнуть, а файл java.jar должен отображаться в списке Android Dependencies. 

（attached picture MoonWar_02.jpg）
 

4）Настройка среды сборки

Щелкните проект правой кнопкой мыши, выберите Project -> Reference -> Builder -> New -> Program и введите следующие данные. Убедитесь, что рабочая папка правильно указана. Если компилятор Cygwin уже установлен, а шаг 2.B был успешно выполнен, можно пропустить шаг 4 и перейти к шагу 5.

（prcture MoonWar_03.jpg）
 

Name：NDK Cocos2dxActivity
Place：D:\Game\NDK\android-ndk-r8\ndk-build.cmd
Working directory：${workspace_loc:/MoonWarriors}
Independent variable：

NDK_MODULE_data-path="D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1;D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\cocos2dx\platform\third_party\android\prebuilt"

（Picture MoonWar_04.jpg）
 

Примечание：

Рабочую папку можно найти в разделе Reference -> Resources -> Path. Скопируйте значение в поле рабочей папки.

Затем нужно задать правильный путь к NDK.

Выберите: Window -> Reference -> Android -> NDK -> NDK Location, задайте значение D:\Game\NDK\android-ndk-r8

5）Сборка проекта

Можно выбрать 5.A или 5.B в зависимости от того, какой из этих вариантов представляется более удобным. Для сборки приложений NDK для платформы Intel Atom необходимо добавить строку APP_ABI := x86 в файл Android.mk.

5.A）Сборка с помощью NDK

Выберите Project -> Build Project. Среда Eclipse соберет проект в библиотеке с помощью собственного сборщика.

Этот шаг аналогичен сборке с помощью сценария build_native.sh в Cygwin.

Убедитесь, что все библиотеки успешно собраны. Откройте папку lib в проекте Eclipse: внутри нее должна быть папка x86 с файлом.

При успешной сборке необходимо упаковать проект. Выберите package -> Run -> Run as -> Android для окончательной сборки проекта cocos2d-HTML5 JSBinding. 

"Compile++ thumb : moonwarriors_shared <= main.cpp
"Compile++ thumb : moonwarriors_shared <= AppDelegate.cpp
......

5.B）Сборка с помощью Cygwin

Если при выполнении команды Package -> Run -> Run as -> Android возникнет ошибка с текстом «No rule to make target: CCConfiguration.cpp», это может быть вызвано отклонением разрешения на доступ к файлу или истечением времени ожидания при компиляции. В этом случае необходимо удалить ранее собранную библиотеку и заново ее собрать, повторно выполнив шаги 2.A и 5.A.

$ rm -Rf obj/*
$ rm -Rf libs/*
$ ./build_native.sh

6）Действия при возникновения ошибок

Если при выполнении команды Package -> Run -> Run as -> Android возникнет ошибка с текстом «Could not find *.apk», возможно, это вызвано неверными настройками проекта. В настройках следует указать приложение, а не библиотеку. Для этого выберите:

Project -> Reference -> Android -> Library -> Is Library. Снимите этот флажок, затем выберите:

Run -> Run as -> Android Application. Если снова возникнет ошибка с текстом «Zip add failed», это означает, что было отклонено разрешение на доступ к файлу. Необходимо сбросить разрешения на доступ к файлу.

Если приложение MoonWar работает с низкой скоростью после установки на телефоны с Android, необходимо оптимизировать его SpiderMonkey. 
Unable to add 'D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android\assets\res\arial-14.GlyphProject': Zip add failed
Unable to add 'D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android\assets\res\arial-14.fnt': Zip add failed
org.cocos2dx.moonwarriors.MoonWarriors] ERROR: unable to process assets while packaging 'D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android\bin\resources.ap_'
org.cocos2dx.moonwarriors.MoonWarriors] ERROR: packaging of 'D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android\bin\resources.ap_' failed

$ cd "D:\Game\SDK\cocos2d-2.1beta3-x-2.1.1\samples\Javascript\MoonWarriors\proj.android"
$ ls -la assets
$ chmod -R 755 assets

Справочные материалы:

1.      https://code.google.com/p/mkisofs-md5/downloads

2.      Cocos2D-HTML5 MoonWarriors Android Dev (wwashington Wrote) -- Android compiling user guide

3.      Cocos2D-HTML5 MoonWarriors iPhone6 Dev (wwashington Wrote) -- iOS compiling user guide

4.      Cocos2D-HTML5 Game MoonWarriors Apk (wwashington Build) -- Android compiling user guide

5.      Cocos2D-HTML5 Game MoonWarriors Src (wwashington Repack) – Source code

Original author：Wwashington AT newsmth、cocos2d-x、chinaunix、pcbeta on 2013/02/28

Adapt and interpret by: Dawei Cheng on 2013/03/25

Website：https://code.google.com/p/mkisofs-md5/downloads

Разработка приложений, использующих датчики, для телефонов и планшетных ПК на базе процессоров Intel® Atom™ и под управлением ОС Android*

Это руководство предназначено для разработчиков приложений и в нем содержится обзор инфраструктуры датчиков, поддерживаемых ОС Android, а также обсуждается использование некоторых датчиков, которые, как правило, присутствуют в телефонах и планшетных ПК на базе процессоров Intel® Atom™. Здесь обсуждаются датчики движения, положения и окружающей среды. Хотя компоненты GPS не считаются датчиками в инфраструктуре Android, сервис определения местоположения на основе GPS также обсуждается в этом руководстве. Все присутствующие в данном руководстве темы относятся к ОС Android 4.2 Jelly Bean.

Датчики на телефонах и планшетных ПК на базе процессоров Intel® Atom™

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

Рисунок 1.  Датчики в системе Android на базе процессора Intel® Atom™

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

Таблица 1.  Типы датчиков, поддерживаемые платформой Android
 

Инфраструктура датчиков Android

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

Таблица 2. Инфраструктура датчиков на платформе Android

Получение конфигурации датчиков

Производители устройств индивидуально принимают решения о том, какие датчики будут доступны на устройстве. Вы должны выяснить, какие датчики доступны во время выполнения, вызывая для этого метод getSensorList() инфраструктуры датчиков SensorManager с параметром “Sensor.TYPE_ALL”. В примере кода 1 представлен список доступных датчиков, поставщик, энергопотребление и информация о точности каждого датчика.

package com.intel.deviceinfo;
	
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import android.app.Fragment;
import android.content.Context;
import android.hardware.Sensor;
import android.hardware.SensorManager;
import android.os.Bundle;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.AdapterView;
import android.widget.AdapterView.OnItemClickListener;
import android.widget.ListView;
import android.widget.SimpleAdapter;
	
public class SensorInfoFragment extends Fragment {
	
    private View mContentView;
	
    private ListView mSensorInfoList;	
    SimpleAdapter mSensorInfoListAdapter;
	
    private List<sensor> mSensorList;

    private SensorManager mSensorManager;
	
    @Override
    public void onActivityCreated(Bundle savedInstanceState) {
        super.onActivityCreated(savedInstanceState);
    }
	
    @Override
    public void onPause() 
    { 
        super.onPause();
    }
	
    @Override
    public void onResume() 
    {
        super.onResume();
    }
	
    @Override
    public View onCreateView(LayoutInflater inflater, ViewGroup container,
            Bundle savedInstanceState) {
        mContentView = inflater.inflate(R.layout.content_sensorinfo_main, null);
        mContentView.setDrawingCacheEnabled(false);
	
        mSensorManager = (SensorManager)getActivity().getSystemService(Context.SENSOR_SERVICE);
	
        mSensorInfoList = (ListView)mContentView.findViewById(R.id.listSensorInfo);
		
        mSensorInfoList.setOnItemClickListener( new OnItemClickListener() {
			
            @Override
            public void onItemClick(AdapterView<?> arg0, View view, int index, long arg3) {
				
                // with the index, figure out what sensor was pressed
                Sensor sensor = mSensorList.get(index);
				
                // pass the sensor to the dialog.
                SensorDialog dialog = new SensorDialog(getActivity(), sensor);

                dialog.setContentView(R.layout.sensor_display);
                dialog.setTitle("Sensor Data");
                dialog.show();
            }
        });
		
        return mContentView;
    }
	
    void updateContent(int category, int position) {
        mSensorInfoListAdapter = new SimpleAdapter(getActivity(), 
	    getData() , android.R.layout.simple_list_item_2,
	    new String[] {
	        "NAME",
	        "VALUE"
	    },
	    new int[] { android.R.id.text1, android.R.id.text2 });
	mSensorInfoList.setAdapter(mSensorInfoListAdapter);
    }
	
	
    protected void addItem(List<Map<String, String>> data, String name, String value)   {
        Map<String, String> temp = new HashMap<String, String>();
        temp.put("NAME", name);
        temp.put("VALUE", value);
        data.add(temp);
    }
	
	
    private List<? extends Map<String, ?>> getData() {
        List<Map<String, String>> myData = new ArrayList<Map<String, String>>();
        mSensorList = mSensorManager.getSensorList(Sensor.TYPE_ALL);
		
        for (Sensor sensor : mSensorList ) {
            addItem(myData, sensor.getName(),  "Vendor: " + sensor.getVendor() + ", min. delay: " + sensor.getMinDelay() +", power while in use: " + sensor.getPower() + "mA, maximum range: " + sensor.getMaximumRange() + ", resolution: " + sensor.getResolution());
        }
        return myData;
    }
}

Пример кода 1. Фрагмент, который представляет список датчиков**

Система координат датчика

Инфраструктура датчиков представляет данные датчика, используя стандартную 3-осевую систему координат, где X, Y и Z соответственно представлены значениями values[0], values[1] и values[2] в объекте SensorEvent.

Некоторые датчики, такие как датчики света, температуры, приближения и давления, возвращают только одиночные значения. Для этих датчиков используются только значения объекта SensorEvent – values[0].

Другие датчики представляют данные в стандартной 3-осевой системе координат. Далее приведен список таких датчиков:

• Акселерометр
• Датчик гравитации
• Гироскоп
• Датчик геомагнитного поля

3-осевая система координат датчика выбирается относительно экрана устройства в его обычной (по умолчанию) ориентации. Для телефона ориентация по умолчанию – портретная; для планшетного ПК – альбомная. Когда устройство удерживается в своем обычном положении, ось х направлена по горизонтали и указывает вправо, ось у направлена вертикально вверх, а ось z указывает за пределы экрана (навстречу смотрящему). На рисунке 2 показана система координат датчика для телефона, а на рисунке 3 – для планшетного ПК

Рисунок 2. Система координат датчика для телефона

Рисунок 3.  Система координат датчика для планшетного ПК

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

Мониторинг событий датчиков

Инфраструктура датчиков представляет данные датчика вместе с объектами SensorEvent. Класс может управлять данными конкретного датчика с помощью интерфейса SensorEventListener и регистрации SensorManager для данного датчика. Инфраструктура датчиков информирует класс об изменениях состояния значений датчика с помощью двух следующих методов вызова SensorEventListener, используемых классом:

onAccuracyChanged()

и

onSensorChanged()

В примере кода 2 представлен SensorDialog, используемый в примере SensorInfoFragment, который обсуждался в разделе "Получение конфигурации датчиков".

package com.intel.deviceinfo;

import android.app.Dialog;
import android.content.Context;
import android.hardware.Sensor;
import android.hardware.SensorEvent;
import android.hardware.SensorEventListener;
import android.hardware.SensorManager;
import android.os.Bundle;
import android.widget.TextView;

public class SensorDialog extends Dialog implements SensorEventListener {
    Sensor mSensor;
    TextView mDataTxt;
    private SensorManager mSensorManager;

    public SensorDialog(Context ctx, Sensor sensor) {
        this(ctx);
        mSensor = sensor;
    }
	
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mDataTxt = (TextView) findViewById(R.id.sensorDataTxt);
        mDataTxt.setText("...");
        setTitle(mSensor.getName());
    }
	
    @Override
    protected void onStart() {
        super.onStart();
        mSensorManager.registerListener(this, mSensor,  SensorManager.SENSOR_DELAY_FASTEST);
    }
		
    @Override
    protected void onStop() {
        super.onStop();
        mSensorManager.unregisterListener(this, mSensor);
    }

    @Override
    public void onAccuracyChanged(Sensor sensor, int accuracy) {
    }

    @Override
    public void onSensorChanged(SensorEvent event) {
        if (event.sensor.getType() != mSensor.getType()) {
            return;
        }
        StringBuilder dataStrBuilder = new StringBuilder();
        if ((event.sensor.getType() == Sensor.TYPE_LIGHT)||
            (event.sensor.getType() == Sensor.TYPE_TEMPERATURE)||
            (event.sensor.getType() == Sensor.TYPE_PRESSURE)) {
            dataStrBuilder.append(String.format("Data: %.3fn", event.values[0]));
        }
        else{         
            dataStrBuilder.append( 
                String.format("Data: %.3f, %.3f, %.3fn", 
                event.values[0], event.values[1], event.values[2] ));
        }
        mDataTxt.setText(dataStrBuilder.toString());
    }
}

Пример кода 2.Диалог, в котором представлены значения датчика**

Датчики движения

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

Датчики движения представляют данные, используя систему координат, где три значения в объекте SensorEvent это значения values[0], values[1] b values[2], представляющие данные по соответствующим им осям координат x, y и z.

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

Акселерометр

Акселерометр измеряет ускорение, которое прилагается к устройству. Его свойства приведены в таблице 3.

Таблица 3. Акселерометр

Концепция акселерометра основана на действии второго закона Ньютона:

a = F/m

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

В нашем коде вместо прямого использования приведенного выше уравнения мы рассматриваем результат ускорения в течение периода времени относительно его скорости и местоположения. Следующее уравнение описывает связь скорости объекта v1 с его первоначальной скоростью v0, ускорением aи временем t:

v1 = v0 + at

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

s = v0t + (1/2)at2

Во многих случаях мы начинаем с условием v0, равным 0 (перед тем, как устройство начинает двигаться), что упрощает уравнение до:

s = at2/2

Из-за действующей силы тяжести ускорение свободного падения, представленное символом g, применяется ко всем объектам на Земле. Не завися от массы объекта, gзависит только от широты местоположения объекта со значением в диапазоне от 9,78 до 9,82 (м/с^{2). Мы принимаем традиционное стандартное значение, используемое для g:}

g = 9.80665 (m/s2)

Поскольку акселерометр представляет значения с использованием многомерной системы координат устройства, в нашем коде мы можем рассчитать расстояние по осям x, y и z, используя следующие уравнения:

Sx = AxT2/2

Sy=AyT2/2

Sz=AzT2/2

Где S_x, S_yи S_zявляются смещениями по осям х, у и z соответственно, а A_x, A_yи A_zявляются ускорениями по осям х, у и z, соответственно. T– это время периода измерения

public class SensorDialog extends Dialog implements SensorEventListener {
    …	
    private Sensor mSensor;
    private SensorManager mSensorManager;
	
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mSensor = mSensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER);
    …
}

Пример кода 3. Использование акселерометра**

Иногда мы не используем все три значения данных. В других случаях, возможно, потребуется принять во внимание ориентацию устройства. Например, для приложения Лабиринт мы используем только данные силы тяжести для оси х и оси y при вычислении направлений и расстояний движения шара на основании данных ориентации устройства. Следующий фрагмент кода (пример кода 4) представляет логику.

@Override
public void onSensorChanged(SensorEvent event) {
    if (event.sensor.getType() != Sensor.TYPE_ACCELEROMETER) {
        return;
    } 
float accelX, accelY;
…
//detect the current rotation currentRotation from its “natural orientation”
//using the WindowManager
    switch (currentRotation) {
        case Surface.ROTATION_0:
            accelX = event.values[0];
            accelY = event.values[1];
            break;
        case Surface.ROTATION_90:
            accelX = -event.values[0];
            accelY = event.values[1];
            break;
        case Surface.ROTATION_180:
            accelX = -event.values[0];
            accelY = -event.values[1];
            break;
        case Surface.ROTATION_270:
            accelX = event.values[0];
            accelY = -event.values[1];
            break;
    }
    //calculate the ball’s moving distances along x, and y using accelX, accelY and the time delta
        …
    }
}

Пример кода 4.Определение ориентации устройства с использованием данных акселерометра в игре Лабиринт**

Гироскоп

Гироскоп измеряет скорость вращения устройства вокруг осей x, y и z, как это показано в таблице 4. Значения данных гироскопа могут быть положительными или отрицательными. Исторически принято, что вращение вокруг оси против часовой стрелки считается положительным, а вращение вокруг оси по часовой стрелке – отрицательным. Мы также можем определить направление значения гироскопа, используя "правило правой руки", показанное на рисунке 4.

Рисунок 4.  Использование правила "правой руки"для определения положительного направления вращения

Таблица 4. Гироскоп

В примере кода 5 показано, как конструировать образец гироскопа.

public class SensorDialog extends Dialog implements SensorEventListener {
    …	
    private Sensor mGyro;
    private SensorManager mSensorManager;
	
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mGyro = mSensorManager.getDefaultSensor(Sensor.TYPE_GYROSCOPE);
    …
}

Пример кода 5. Использование гироскопа**

Датчики положения

Многие планшетные ПК Android имеют два датчика положения: магнитометр и датчик приближения. Магнитометр измеряет силу магнитного поля Земли по осям х, у и z, а датчик приближения определяет расстояние от устройства до другого объекта.

Магнитометр

Наиболее важным назначением магнитометра (представлено в таблице 5) в системах Android является реализация функций компаса.

Таблица 5. Магнитометр

В примере кода 6 показано, как конструировать образец магнитометра.

public class SensorDialog extends Dialog implements SensorEventListener {
    …	
    private Sensor mMagnetometer;
    private SensorManager mSensorManager;
	
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mMagnetometer = mSensorManager.getDefaultSensor(Sensor.TYPE_MAGNETIC_FIELD);
    …
}

Пример кода 6.Использование магнитометра**

Приближение

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

В примере кода 7 показано использование датчика приближения.

public class SensorDialog extends Dialog implements SensorEventListener {
    …	
    private Sensor mProximity;
    private SensorManager mSensorManager;
	
    public SensorDialog(Context context) {
        super(context);
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mProximity = mSensorManager.getDefaultSensor(Sensor.TYPE_PROXIMITY);
    …
}

Пример кода 7.Использование датчика приближения**

Датчики окружающей среды

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

Датчик освещенности (ALS)

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

В примере кода 8 показано использование датчика освещенности.

…	
    private Sensor mALS;
    private SensorManager mSensorManager;

    …	
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mALS = mSensorManager.getDefaultSensor(Sensor.TYPE_LIGHT);
    …

Пример кода 8.Использование датчика освещенности**

Барометр

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

В примере кода 9 показано использование барометра

…	
    private Sensor mBarometer;
    private SensorManager mSensorManager;

    …	
        mSensorManager = (SensorManager)context.getSystemService(Context.SENSOR_SERVICE);
        mBarometer = mSensorManager.getDefaultSensor(Sensor.TYPE_PRESSURE);
    …

Пример кода 9.  Использование барометра**

Принципы настройки производительности и оптимизации датчиков

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

• Проверяйте доступность конкретного датчика перед его использованием
  Платформа Android не требует включения или исключения определенного датчика на устройстве. Перед использованием датчика в вашем приложении нужно сначала проверить его действительную доступность.
• Всегда отменяйте регистрацию приемников датчиков
   Если операция, использующая приемник датчика, станет невидимой или диалог будет остановлен, нужно отменить регистрацию приемника датчика. Это может быть сделано с помощью метода операции OnPause() или в методе диалога OnStop(). Иначе датчик будет продолжать сбор данных и, в результате, разряжать батарею.
• Не блокируйте метод onSensorChanged()
   Метод onSensorChanged() часто вызывается системой для представления данных датчика. Для этого метода требуется совсем немного логики. Сложные вычисления с данными датчиков должны быть вынесены за пределы этого метода.
• Всегда тестируйте свои приложения, работающие с датчиками, на реальных устройствах
  Все датчики, описанные в этом разделе, являются аппаратными датчиками. Эмулятор ОС Android может быть не в состоянии имитировать конкретные функции и определить производительность датчика.

GPS и местоположение

GPS (Global Positioning System) является системой, основанной на получении спутниковых данных, которая выдает точную информацию о географическом положении по всему миру. Коммуникации GPS доступны на многих телефонах и планшетных ПК с ОС Android. Во многих случаях устройство GPS работает также как датчик положения. Оно может предоставлять точные данные о местоположении для работающих на устройстве приложений. На платформе Android устройство GPS не управляется непосредственно инфраструктурой датчиков. Вместо этого сервис определения местоположения Android взаимодействует и передает данные GPS в приложения через вызовы приемника местоположения.

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

Сервисы определения местоположения Android

Использование GPS не является единственным способом получения информации о местоположении устройства Android. Система также может использовать Wi-Fi*, сотовые или другие беспроводные сети, чтобы получить данные о текущем местоположении устройства. GPS и беспроводные сети (включая Wi-Fi и сотовые сети) выступают в качестве "поставщиков данных определения местоположения"для сервисов Android. В таблице 9 перечислены основные классы и интерфейсы, используемые для доступа к сервисам определения местоположения в ОС Android.

Получение обновлений данных GPS о местоположении

По аналогии с механизмом использования инфраструктуры датчиков для получения данных датчиков, приложение использует несколько методов вызовов, определенных в интерфейсе LocationListener для сбора обновлений данных GPS о местоположении. LocationManager отправляет в приложение оповещения об обновлениях данных GPS с помощью этих вызовов (правило – "Не звоните нам, мы сами обратимся к вам").

Для получения данных GPS о местоположении в приложении нужно запросить разрешение на получение точной информации о местоположении в вашем файле манифеста Android (пример кода 10).

<manifest …>
…
    <uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />
…  
</manifest>

Пример кода 10.Запрос разрешения на получение точной информации о местоположении в файле манифеста**

В примере кода 11 представлено, как получать обновления данных GPS и отображать координаты широты и долготы в текстовом диалоге.

package com.intel.deviceinfo;

import android.app.Dialog;
import android.content.Context;
import android.location.Location;
import android.location.LocationListener;
import android.location.LocationManager;
import android.os.Bundle;
import android.widget.TextView;

public class GpsDialog extends Dialog implements LocationListener {
    TextView mDataTxt;
    private LocationManager mLocationManager;
	
    public GpsDialog(Context context) {
        super(context);
        mLocationManager = (LocationManager)context.getSystemService(Context.LOCATION_SERVICE);
    }

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
	       mDataTxt = (TextView) findViewById(R.id.sensorDataTxt);
          mDataTxt.setText("...");
		
        setTitle("Gps Data");
    }
	
    @Override
    protected void onStart() {
        super.onStart();
        mLocationManager.requestLocationUpdates(
            LocationManager.GPS_PROVIDER, 0, 0, this);
    }
		
    @Override
    protected void onStop() {
        super.onStop();
        mLocationManager.removeUpdates(this);
    }

    @Override
    public void onStatusChanged(String provider, int status, 
        Bundle extras) {
    }

    @Override
    public void onProviderEnabled(String provider) {
    }

    @Override
    public void onProviderDisabled(String provider) {
    }

    @Override
    public void onLocationChanged(Location location) {
        StringBuilder dataStrBuilder = new StringBuilder();
        dataStrBuilder.append(String.format("Latitude: %.3f,   Logitude%.3fn", location.getLatitude(), location.getLongitude()));
        mDataTxt.setText(dataStrBuilder.toString());
		
    }
}

Пример кода 11.  Диалог, отображающий данные GPS о местоположении**

Принципы настройки и оптимизации производительности сервисов GPS и определения местоположения

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

• Используйте всех доступных поставщиков данных о местоположении
  В дополнение к сервису GPS_PROVIDER есть сервис NETWORK_PROVIDER. Если приложению нужно получить лишь грубые данные о местоположении, вы можете использовать только сервис NETWORK_PROVIDER.
• Используйте кэшированные местоположения
  Требуется время, чтобы сервис GPS мог получить первые данные о местоположении. Когда ваше приложение ожидает данные от сервиса GPS, чтобы получить их точное обновление, для выполнения части работы вы можете сначала использовать местоположения, предоставляемые методом getlastKnownLocation() в классе LocationManager.
• Минимизируйте количество и продолжительность запросов для обновления данных о местоположении
  Вы должны запрашивать обновления данных о местоположении только в случае необходимости и оперативно отменять регистрацию менеджера местоположений, как только данные сервисы более не будут нужны.

Заключение

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

Об авторе

© Корпорация Intel, 2013 г. Все права защищены.
*Другие наименования и товарные знаки являются собственностью своих законных владельцев.

**Этот пример исходного кода опубликован на условиях лицензионного соглашения о примерах исходного кода корпорации Intel

Станислав Павлов

Сама ОС Android не может распознавать речь, поэтому обычное устройство Android не в состоянии сделать это. Или все же есть способ?

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

Наше целевое устройство должно иметь, по крайней мере, одно приложение, которое может обработать намерение для распознавания речи, которое вызывается операцией RecognizerIntent.ACTION_RECOGNIZE_SPEECH.

Одним таким приложением является Google Voice Search. Это один из лучших сервисов распознавания речи для ОС Android, которое поддерживает множество языков. Для его работы требуется подключение к Интернету, так как процесс распознавания речи осуществляется на серверах Google. Данное приложение имеет очень простую операцию, которая информирует пользователей, когда они могут начать говорить. В тот момент, когда пользователь прекращает говорить, диалог закрывается, и наше приложение (вызвавшее намерение) принимает массив строк с обнаруженными элементами речи.

Пример распознавания речи

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

Нашему приложению необходимо сделать следующее:

• Получить запрос для распознавания речи
• Проверить доступность приложения для распознавания речи
• Если приложение распознавания речи доступно, затем вызвать для него намерение и получить результаты
• Если приложение распознавания речи недоступно, тогда нужно отобразить диалог для установки сервиса Google Voice Search и направления пользователя в магазин Play Google, если он решит выполнить установку

Во-первых, мы создадим класс, который реализует логику распознавания речи. Назовем этот класс SpeechRecognitionHelper, где мы объявим функцию run() (static, public), которая будет получать запрос на запуск распознавания:

/**
 * A helper class for speech recognition
 */
public class SpeechRecognitionHelper {

/**
     * Running the recognition process. Checks availability of recognition Activity,
     * If Activity is absent, send user to Google Play to install Google Voice Search.
    * If Activity is available, send Intent for running.
     *
     * @param callingActivity = Activity, that initializing recognition process
     */
    public static void run(Activity callingActivity) {
        // check if there is recognition Activity
        if (isSpeechRecognitionActivityPresented(callingActivity) == true) {
            // if yes – running recognition
            startRecognition(callingActivity);
        } else {
            // if no, then showing notification to install Voice Search
            Toast.makeText(callingActivity, "In order to activate speech recognition you must install \"Google Voice Search\"", Toast.LENGTH_LONG).show();
            // start installing process
            installGoogleVoiceSearch(callingActivity);
        }
    }
}

Как видите, кроме функции run()мы используем еще три функции:

• isSpeechRecognitionActivityPresented – проверяет, если в системе приложение распознавания речи
• installGoogleVoiceSearch – начинает процесс установки сервиса Google Voice Search
• startRecognition – готовит соответствующее намерение и запускает процесс распознавания

Для проверки того, что на устройстве установлено приложение распознавания речи, мы можем использовать метод queryIntentActivitiesв классе PackageManager. Этот метод представляет список операций, которые могут обрабатывать указанное намерение. Чтобы получить экземпляр класса PackageManager, мы можем использовать getPackageManager.

Далее представлен наш код:

isSpeechRecognitionActivityPresented

/**
     * Checks availability of speech recognizing Activity
     *
     * @param callerActivity – Activity that called the checking
     * @return true – if Activity there available, false – if Activity is absent
     */
    private static boolean isSpeechRecognitionActivityPresented(Activity callerActivity) {
        try {
            // getting an instance of package manager
            PackageManager pm = callerActivity.getPackageManager();
            // a list of activities, which can process speech recognition Intent
            List activities = pm.queryIntentActivities(new Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH), 0);

            if (activities.size() != 0) {    // if list not empty
                return true;                // then we can recognize the speech
            }
        } catch (Exception e) {

        }

        return false; // we have no activities to recognize the speech
    }

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

Исходный код:

   /**
     * Send an Intent with request on speech 
     * @param callerActivity  - Activity, that initiated a request
     */
    private static void startRecognitionActivity(Activity callerActivity) {

        // creating an Intent with “RecognizerIntent.ACTION_RECOGNIZE_SPEECH” action
        Intent intent = new Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH);

        // giving additional parameters:
        intent.putExtra(RecognizerIntent.EXTRA_PROMPT, "Select an application");    // user hint
        intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE_MODEL, RecognizerIntent.LANGUAGE_MODEL_WEB_SEARCH);    // setting recognition model, optimized for short phrases – search queries
        intent.putExtra(RecognizerIntent.EXTRA_MAX_RESULTS, 1);    // quantity of results we want to receive
//choosing only 1st -  the most relevant 

        // start Activity ant waiting the result
        ownerActivity.startActivityForResult(intent, SystemData.VOICE_RECOGNITION_REQUEST_CODE);
    }

И, наконец, мы используем функцию installGoogleVoiceSearch. Эта функция отобразит диалог с вопросом для пользователя, если он хочет установить сервис Google Voice Search, и направить его для этого в магазин Google Play.

/**
     * Asking the permission for installing Google Voice Search. 
     * If permission granted – sent user to Google Play
     * @param callerActivity – Activity, that initialized installing
     */
    private static void installGoogleVoiceSearch(final Activity ownerActivity) {

        // creating a dialog asking user if he want
        // to install the Voice Search
        Dialog dialog = new AlertDialog.Builder(ownerActivity)
            .setMessage("For recognition it’s necessary to install \"Google Voice Search\"")    // dialog message
            .setTitle("Install Voice Search from Google Play?")    // dialog header
            .setPositiveButton("Install", new DialogInterface.OnClickListener() {    // confirm button

                // Install Button click handler
                @Override
                public void onClick(DialogInterface dialog, int which) {
                    try {
                        // creating an Intent for opening applications page in Google Play
                        // Voice Search package name: com.google.android.voicesearch
                        Intent intent = new Intent(Intent.ACTION_VIEW, Uri.parse("market://details?id=com.google.android.voicesearch"));
                        // setting flags to avoid going in application history (Activity call stack)
                        intent.setFlags(Intent.FLAG_ACTIVITY_NO_HISTORY | Intent.FLAG_ACTIVITY_CLEAR_WHEN_TASK_RESET);
                        // sending an Intent
                        ownerActivity.startActivity(intent);
                     } catch (Exception ex) {
                         // if something going wrong
                         // doing nothing
                     }
                }})

            .setNegativeButton("Cancel", null)    // cancel button
            .create();

        dialog.show();    // showing dialog
    }

Вот и все. Теперь мы запускаем операцию для распознавания речи. Затем запрашиваем разрешение пользователя для установки Voice Search и направляем его в магазин Google Play. Еще одно, что нужно сделать – это получить результаты процесса распознавания речи.

Мы отправляем запрос с помощью функции startActivityForResultдля сбора результатов запущенной операции. Нам также необходимо повторно использовать метод OnActivityResultв нашей операции намерения. Это можно сделать следующим образом:

// Activity Results handler
    @Override
    public void onActivityResult(int requestCode, int resultCode, Intent data) {

        // if it’s speech recognition results
        // and process finished ok
        if (requestCode == SystemData.VOICE_RECOGNITION_REQUEST_CODE && resultCode == RESULT_OK) {

            // receiving a result in string array
            // there can be some strings because sometimes speech recognizing inaccurate
            // more relevant results in the beginning of the list
            ArrayList matches = data.getStringArrayListExtra(RecognizerIntent.EXTRA_RESULTS);

            // in “matches” array we holding a results... let’s show the most relevant
            if (matches.size() > 0) Toast.makeText(this, matches.get(0), Toast.LENGTH_LONG).show();
        }

        super.onActivityResult(requestCode, resultCode, data);
    }

Теперь все готово

Созданный класс SpeechRecognitionHelperпозволяет нам выполнять запрос распознавания речи посредством вызова только одной функции run().

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

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

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

Об авторах

Станислав работает в группе программ и услуг (Software & Service Group) корпорации Intel. Он имеет 10-летний опыт разработки программного обеспечения. Главным приоритетом в его работе является оптимизация производительности, энергопотребление и параллельное программирование. В настоящее время Станислав исполняет роль инженера по программным приложениям и оказывает техническую поддержку для устройств на базе платформ Intel, а также постоянно сотрудничает разработчиками ПО и архитекторами SoC, помогая им добиваться максимально возможной производительности платформ Intel. Станислав имеет степень магистра в области математической экономики национального исследовательского университета высшей школы экономики.

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

Intel и логотип Intel являются товарными знаками корпорации Intel в США и/или других странах.
© Корпорация Intel, 2013 г. Все права защищены.
*Другие наименования и товарные знаки являются собственностью своих законных владельцев.

Комплект NDK (Native Development Kit) для Android является дополнением к Android SDK и позволяет вам создавать приложения с использованием обычных языков программирования, таких как C и C++.

Вы можете скачать инструментарий NDK на сайте: http://developer.android.com/tools/sdk/ndk/index.html

Комплект NDK для архитектуры, использующей набор команд X86

Android является операционной системой с открытым исходным кодом, которая была разработана Google. В настоящее время ОС Android может работать с тремя семействами наборов команд архитектур ARM, x86 и MIPS. X86 означает семейство наборов команд архитектур, созданных на базе процессора Intel 8086, появившегося в 1978 году. Давайте установим различия между X86 (также называется архитектурой Intel®) и другими наборами микросхем, на которых работает ОС Android с точки зрения приложений.

Приложения для ОС Android можно разделить на два типа:

• Приложения Dalvik, которые включают в себя код Java* и используют только необходимые файлы ресурсов официального прикладного программного интерфейса Android SDK, например, .xml и .png, скомпилированные в файл APK.
• Приложения, созданные с помощью комплекта Android NDK, содержащие код Java, файлы ресурсов, исходный код C/C++, а иногда и код ассемблера. Весь оригинальный код компилируется в связанную динамическую библиотеку (файл .so), а затем вызывается с помощью Java в основной программе, используя механизм JNI.

Игровой движок Android

Игровой движок – это ключевой модуль для игровых приложений. Существует несколько движков, работающих в среде Android, в число которых входят движки 2D и 3D на основе открытого исходного кода, а также коммерческие модули. Зачастую существует трудность переноса и разработки игр для платформы Android на платформу Intel. Cocos2d-х и Unity 3D являются самыми популярными игровыми движками для платформ Android.

Движок Cocos2d-х основан на Cocos2d-iPhone, состоит из развивающихся поддерживаемых платформ и использует несколько языков программирования, которые применяют эту же структуру прикладного программного интерфейса. С момента своего появления в июле 2010 года движок cocos2d-х был скачан более 500 миллионов раз. Гиганты индустрии мобильных игр, такие как Zynga, Glu, GREE, DeNA, Konami, TinyCo, Gamevil, HandyGames, Renren Games, 4399, HappyElements, SDO и Kingsoft, используют cocos2d-х.

Unity 3D, разработанный компанией Unity Technologies, представляет собой кроссплатформенный игровой движок с встроенной технологией IDE. Он применяется для разработки видеоигр для веб-плагинов, платформ настольных ПК, консолей и мобильных устройств, и используется более чем миллионом разработчиков. Он был создан в 2005 году из средства разработки игровых приложений, поддерживаемых OS X, и теперь это многоплатформенный движок игровых приложений. Последнее обновление движка Unity 4.1 было выпущено в марте 2013 года. В настоящее время он поддерживает разработки для платформ iOS, Android, Windows, Blackberry 10, OS X, Linux, веб-браузеров, Flash*, PlayStation 3, Xbox 360, Windows Phone и Wii.

Разработка игр с помощью комплекта Android NDK для платформ Intel

Прежде чем мы будем говорить о разработке игр, необходимо представить платформу Android в целом. Как вы знаете, игры создаются в самых разных стилях. Различные стили игр требуют разных принципов разработки. В начале проекта, вы обычно выбираете жанр своей игры. Если вы не сможете придумать что-то совершенно новое и доселе неизвестное, высок шанс того, что ваша игра идея будет соответствовать одному из широко распространенных сейчас жанров. Большинство жанров устанавливают стандарты игровой механики (например, схемы управления, конкретные цели и т.д.). Отклонение от этих стандартов может сделать игру хитом, так как игрокам всегда нравится что-то новое. Вот некоторые из общеизвестных жанров:

• Аркадные и экшн
• Развивающие мышление и головоломки
• Карточные игры и казино
• Казуальные игры
• Интерактивные обои
• Гонки
• Спортивные игры
• Виджеты
• и т.д.

Процесс разработки обычных игр для Android подобен разработке любого другого приложения. Во-первых, нужно загрузить комплекты Android SDK и NDK с сайта Google и корректно установить их.

Я предполагаю, что вы уже выполнили всю установку и подготовительные действия. Используя игровой движок Cocos2d-х в качестве примера, давайте рассмотрим, как создать игру для архитектуры Intel.

Загрузка Cocos2d-х

Загрузите последнюю стабильную версию Cocos2d-х с веб-сайта: http://www.cocos2d-x.org/projects/cocos2d-x/wiki/Download

Запуск командного файла

Запустите командный файл из Проводника Windows. После запроса о местоположении проекта, установите его как com.yourproject.something, выберите имя проекта и целевой ИД. Это действие создаст папку с именем проекта в каталоге установки cocos2dx. Вы должны увидеть выполнение сценария без каких-либо ошибок, что-то подобное следующему:

Установка переменных среды для NDK_ROOT

Добавьте следующую переменную среды в конце файла home\<ваше_имя>\.bash_profile (в данном случае: c:\cygwin\home\user\.bash_profile):

NDK_ROOT=/cygdrive/<ваше_имя>/

export NDK_ROOT
 

Перезапустите cygwin,input cd $NDK_ROOT, и вы должны увидеть следующий экран:

Запуск файла build_native.sh

В конфигурации по умолчанию выбрана платформа ARM, и мы должны изменить ее для компиляции для платформы x86. Откройте файл \helloworld\proj.android \build_native.sh, найдите команду ndk-build и добавьте в ее конец параметр APP_ABI=x86. Запустите его в Cygwin, и вы увидите следующее:

Импорт проекта в Eclipse

Теперь перейдите в Eclipse, создайте новый проект (project -> Import) из существующего проекта

Сборка и запуск

На данном этапе в Eclipse возникнут некоторые ошибки:

The import org.cocos2dx.lib cannot be resolved HelloWorld.java

/HelloWorld/src/com/young40/test line 26 Java Problem Cocos2dxActivity cannot be resolved to a type HelloWorld.java

/HelloWorld/src/com/young40/test line 30 Java Problem Cocos2dxActivity cannot be resolved to a type HelloWorld.java

/HelloWorld/src/com/young40/test line 33 Java Problem

Вы должны импортировать в Eclipse следующую библиотеку в качестве проекта:

cocos2d-2.1beta3-x-2.1.1/cocos2dx/platform/android/java

Перейдите "Project -> Build"и выполните "Run As -> Android Application":

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

Оптимизация игр, созданных на основе комплекта NDK на платформе Intel

Intel® System Studio представляет собой набор инструментальных средств для профилирования и оптимизации приложений на платформе Android. Конечно, он также может использоваться для оптимизации игр. Intel System Studioвключает

• Компилятор Intel® C++
• Intel® Graphics Performance Analyzers
• Intel® VTune™ Amplifier
• (Intel® JTAG Debugger)

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

Во-первых, давайте возьмем приложение с названием Bounding Ball, которое мы будем запускать в системе на базе процессора Intel® Atom™ Z2460 (кодовое название Medfield). В игре насчитывается более 800 шариков, которые движутся с различной скоростью и хаотично сталкиваются друг с другом. После замеров FPS вы видите, что производительность игры недостаточна, и ее значение без оптимизации лишь равно 6.

Мы можем использовать Intel® Graphics Performance Analyzers (Intel® GPA), чтобы определить модуль, являющийся "узким"местом, и выяснить, если проблема относится к ЦП или его связям.

На следующем снимке экрана анализатора производительности графики Intel показана диаграмма, которая описывает данные этого приложения посредством анализа производительности на платформе Android. Изучив эти данные, вы можете заметить, что ЦП загружен на 52,5%. Это довольно высокий показатель для одного приложения. Между тем, процессы ISP Load, TA Load, TSP Load и USSE Total Load работают внутри GPU и используют процессор менее чем на 10%, а это означает, что GPU загружен нормально. Таким образом, можно сделать вывод, что узким местом является модуль центрального процессора. Для дальнейшего анализа проблемы загрузки ЦП, мы должны выполнить профилирование кода с использованием анализатора VTune™.

Здесь мы не будем описывать, как использовать анализатор VTune – мы просто поясним результаты, полученные после его запуска. Основными активными участками являются функции sin и cos внутри libm.so. Таким образом, вопрос заключается в следующем: почему приложение тратит столько времени и циклов процессора для обработки этих двух функций?

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

После оптимизации кода производительность повысилась на 80%, и показатель FPS равен 14. Более того, мы можем скомпилировать приложение с помощью компилятора Intel C/C++ для получения более высокой производительности на платформах архитектуры Intel. Компилятор Intel C/C++ имеет множество флагов для оптимизации производительности на платформах архитектуры Intel. Мы хотим представить некоторые из них.

• SSSE3_ATOM
  Команды Supplemental Streaming SIMD Extensions 3 (SSSE3 или SSE3S) являются набором команд SIMD, который был создан Intel и представляет четвертую редакцию технологии SSE.
• IPO
  Межпроцедурный флаг оптимизации, позволяющий уменьшить число вызовов функций, найти неиспользуемый код и изменить порядок распространения констант и процедур.
• PGO
  Флаг профильной оптимизации, который анализирует оставшиеся без ответа вопросы оптимизатора, например:
  • Как часто х > у
  • Каков размер счетчика
  • Какой код используется и как часто

Кроме того, компилятор Intel C/C++ также может повысить производительность приложений, выполнив следующее:

• Более точное прогнозирование ветвлений
• Перемещение общих компонентов для совершенствования кэша команд
• Поиск лучшего решения при выстраивании порядка функций (помощь IPO)
• Лучшая оптимизация упорядочивания функций
• Оптимизация команд-переключателей
• Лучшие решения векторизации

С использованием различных компиляторов и различных параметров компиляции приложение может иметь различную производительность. Далее приводится сравнение производительности двух компиляторов – GCC и ICC. Одно и то же приложение Bounding Ball работает на телефоне Android на базе платформы Intel Medfield. Синяя часть – это производительность GCC, красная – ICC. В основе лежит компиляция без каких-либо параметров. Вторая часть диаграммы представляет компиляцию с использованием параметра arch=atom. Третья часть – это повторная компиляция со всеми упомянутыми выше параметрами. Наконец, вы можете оценить, что производительность приложения, скомпилированного с помощью ICC, на 60% выше, чем с использованием GCC.

Заключение

В этой статье было представлено введение в разработку игровых приложений для ОС Android и оптимизация приложений на платформах с архитектурой Intel. Движки игровых приложений являются основными компонентами разработки любых игр. Если они хорошо работают на платформах с архитектурой Intel, то и игры также будут хорошо работать на этих платформах. Мы рассмотрели популярный игровой движок cocos2dx в качестве примера для демонстрации разработки на платформах с архитектурой Intel. Корпорация Intel также предлагает разработчикам множество инструментальных средств для оптимизации игровых приложений на платформах Android. Используя средство Intel System Studio, мы продемонстрировали, как оптимизировать демонстрационное приложение.

Об авторе

Тао Пэн (Tao Peng) инженер по приложениям в подразделении программного обеспечения и услуг корпорации Intel, где его работа сосредоточена на внедрении мобильных приложений, включая разработку программ для платформ Android и их оптимизацию для устройств x86, а также веб-разработки приложений HTML5.

Одна из наиболее известных библиотек C++ для многопоточной обработки конструктивного компонента Intel® Threading Building Blocks была недавно обновлена на новую версию – 4.2. Обновленная версия по сравнению с предыдущей версией 4.1 содержит несколько новых важных функций. Некоторые из них уже были добавлены в обновления библиотеки конструктивного компонента Intel Threading Building Blocks 4.1.

Новая функция примитивов синхронизации speculative_spin_mutexобеспечивает поддержку для спекулятивной блокировки. Это стало возможно благодаря использованию аппаратной функции Transactional Synchronization Extensions (Intel® TSX), доступной в процессорах Intel® Core™ четвертого поколения. В процессорах, поддерживающих память для аппаратных транзакций (таких как Intel® Transactional Synchronization Extensions), спекулятивные мьютексы работают, позволяя нескольким потокам использовать одну блокировку, пока не появятся "конфликты", которые могут привести к результатам, отличным от неспекулятивной блокировки. Таким образом, последовательная обработка исключается в случаях, когда не возникает конфликтов. Это может значительно повысить производительность и масштабируемость для "кратких"и важных секций данных. Если нет аппаратной поддержки для синхронизации транзакций, спекулятивные мьютексы работают подобно своим неспекулятивным аналогам, но, вероятно, с худшей производительности.

Библиотека конструктивного компонента Intel Threading Building Blocks теперь поддерживает функцию распространения точных исключений (на основе C++11 exception_ptr). Используя exception_ptr, объекты исключений могут безопасно копироваться между потоками. Это обеспечивает гибкость в обработке исключений в многопоточной среде. Сейчас распространение точных исключений доступно в предварительных сборках двоичных программ для всех платформ: OS X*, Windows* и Linux*. В системе OS X есть два набора двоичных файлов: первый связан со стандартной библиотекой gcc, которая используется по умолчанию и не поддерживает распространение точных исключений. Для использования этой функции вы должны применять второй набор двоичных файлов, связанных со стандартной библиотекой libc++, C++ в Clang. Для их использования нужно настроить среду конструктивного компонента Intel Threading Building Blocks и выполнить сборку приложения следующим образом:

     # tbbvars.sh libc++

     # clang++ -stdlib=libc++ -std=c++11 concurrent_code.cpp -ltbb

В дополнение к контейнерам concurrent_unordered_setи concurrent_unordered_mapтеперь существуют контейнеры concurrent_unordered_multisetи concurrent_unordered_multimap, работа которых основана на прототипе Microsoft* PPL. Контейнер concurrent_unordered_multisetимеет возможность вставки элементов более чем один раз, что невозможно в контейнере concurrent_unordered_set. Аналогично, concurrent_unordered_multimapпозволяет вставлять более одной пары <ключ,значение>с одним значением ключа. Для обоих мультиконтейнеров функция поиска вернет первый элемент (или пару <ключ,значение>) в таблице с соответствующим ключом поиска.

Контейнеры конструктивного компонента Intel Threading Building Blocks теперь можно удобно инициализировать со списками значений, как это делается в C++ 11 (списки инициализации):

tbb::concurrent_vector<int> v ({1,2,3,4,5} );

В настоящее время списки инициализации поддерживаются следующими контейнерами:

concurrent_vector
concurrent_hash_map
concurrent_unordered_set
concurrent_unordered_multiset
concurrent_unordered_map
concurrent_unordered_multimap
concurrent_priority_queue

Распределитель масштабируемой памяти имеет кэш для выделенной памяти в каждом потоке. Это делается ради производительности, но часто за счет расширенного использования памяти. Хотя распределитель памяти пытается избежать ее чрезмерного использования, в сложных ситуациях библиотека конструктивного компонента Intel Threading Building Blocks 4.2 предлагает программистам наиболее полный контроль: теперь можно уменьшить использование памяти посредством очистки кэш-блоков потоков с помощью функции scalable_allocation_command(). Также было выполнено несколько других улучшений для повышения общей производительности распределителя.

Библиотека конструктивного компонента Intel Threading Building Blocks широко используется на различных платформах. Сейчас разработчики мобильных систем могут найти готовые двоичные модули для ОС Android в пакете ОС Linux. В пакет ОС Windows также были добавлены двоичные модули для приложений, размещаемых в магазине Windows Store.

Элементарные переменные tbb::atomic<T>теперь имеют конструкторы, когда используется C++11. Это позволяет разработчикам выполнять проверку их инициализации во время объявления с корректно поддерживаемыми постоянными выражениями. В настоящее время это работает с компиляторами gcc и Clang:

tbb::atomic<int> v=5;

Новая функция предварительного просмотра в сообществе позволяет ожидать, пока не будут прекращены все рабочие потоки. Это может потребоваться, если приложений разделяет процессы или, если динамическая библиотека конструктивного компонента Intel Threading Building Blocks может быть выгружена во время выполнения (например, если библиотека является частью плагина). Для начала ожидания модулями нужно следующим способом инициализировать объект task_scheduler_init:

#define TBB_PREVIEW_WAITING_FOR_WORKERS 1
tbb::task_scheduler_init scheduler_obj (threads, 0, /*wait_workers=*/true);

Новую библиотеку конструктивного компонента Intel Threading Building Blocks 4.2 можно найти как на коммерческихсайтах, так и на сайтах с открытым исходным кодом. Загружайте и пользуйтесь новыми функциональными возможностями!

Библиотеки Intel® Integrated Performance Primitives содержат высоко оптимизированные функции компонентов для обработки изображений, сигналов, данных векторной математики и небольших матричных вычислений. Несколько доменов библиотек Intel Integrated Performance Primitives содержат оптимизированные вручную функции для процессоров Intel® Atom™ и используют при этом команды Intel® Streaming SIMD Extensions. Статическая беспотоковая библиотека Intel Integrated Performance Primitives теперь поддерживает ОС Android* и может использоваться с приложениями для этой платформы.

В этой статье представлен обзор добавления функций библиотек Intel Integrated Performance Primitives в приложения, создаваемые на основе комплекта Android NDK. Библиотеки Intel Integrated Performance Primitives могут использоваться для оптимизации работы конкретных процессоров, и только они могут быть привязаны к оригинальному коду C/C++ ОС Android. Для использования библиотек Intel Integrated Performance Primitives с вашим приложением необходимо включить их функции в исходный код, а также в командную строку во время сборки.

Использование библиотек Intel Integrated Performance Primitives

1. Добавление функций Intel Integrated Performance Primitives в исходный код

• Включите файлы заголовков Intel Integrated Performance Primitives (ipp.h) в файлы исходного кода.
• Перед использованием любых других функций библиотек Intel Integrated Performance Primitives вызовите функцию ippInit(). Intel Integrated Performance Primitives обнаружит функции процессора и выберет вариант оптимизации кода для целевых процессоров. Перед вызовом любых других функций Intel Integrated Performance Primitives также вызовите ippInit()для инициализации операций координации работы процессора.
• Вызовите функции Intel Integrated Performance Primitives в своем исходном коде C/C++.

2. Включение библиотек Intel Integrated Performance Primitives в файлы сборки комплекта Android NDK

• Скопируйте библиотеки Intel Integrated Performance Primitives и заголовки в папку проекта.
• Выберите библиотеки Intel, необходимые для приложения: библиотеки Intel Integrated Performance Primitives подразделяются на различные домены. Каждый домен имеет собственную библиотеку, и некоторые библиотеки домена зависит от других библиотек. Домен должен содержать в строке связей все библиотеки и их зависимости. См. статью “Intel IPP Library Dependencies” (Зависимости библиотек Intel Integrated Performance Primitives), чтобы узнать, какие библиотеки необходимы.
• Добавьте библиотеки Intel Integrated Performance Primitives в файл сценария сборки Android, “jni/Android.mk”:
  Объявите каждую библиотеку Intel Integrated Performance Primitives как предварительно подготовленный двоичный модуль. Например, если приложение использует две библиотеки Intel Integrated Performance Primitives, "libipps.a"и "libippcore.a", добавьте следующее в файл:

               include $(CLEAR_VARS)
               LOCAL_MODULE := ipps
               LOCAL_SRC_FILES := ../ipp/lib/ia32/libipps.a
               include $(PREBUILT_STATIC_LIBRARY)

               include $(CLEAR_VARS)
               LOCAL_MODULE := ippcore
               LOCAL_SRC_FILES := ../ipp/lib/ia32/libippcore.a
               include $(PREBUILT_STATIC_LIBRARY) 

Добавьте путь заголовка и библиотеки Intel Integrated Performance Primitives в модули, вызывающие функции Intel Integrated Performance Primitives:

               include $(CLEAR_VARS)
               LOCAL_MODULE := IppAdd
               LOCAL_SRC_FILES := IppAdd.c
               LOCAL_STATIC_LIBRARIES := ipps ippcore
               LOCAL_C_INCLUDES := ./ipp/include
               include $(BUILT_SHARED_LIBRARY)

Сборка одного примера кода

В следующем простом примере представлено использование Intel Integrated Performance Primitives в оригинальном коде Android. Код использует функцию Intel Integrated Performance Primitives ippsAdd_32f()для добавления данных в два массива.

Для проверки использования Intel Integrated Performance Primitives в коде:

1. Загрузите пример кодаи распакуйте его в папку проекта (<каталог_проекта>).
2. Рассмотрите использование Intel Integrated Performance Primitives в исходных файлах: в файле "jni/IppAdd.c"представлена реализация одной оригинальной функции NativeIppAdd(). Эта функция вызывает функцию Intel Integrated Performance Primitives ippsAdd_32f(). Файл "src/com/example/testippadd/ArrayAddActivity.java""вызывает оригинальную функцию "NativeIppAdd()"с помощью JNI.
3. Проверьте файл "jni/Android.mk". Этот файл добавляет необходимые библиотеки Intel Integrated Performance Primitives в сценарий сборки. В примере используется функция ippsAdd_32f(), которая принадлежит к домену обработки сигналов Intel Integrated Performance Primitives. Эта функция зависима от библиотек "libipps.a"и "libippcore.a". Файл "Android.mk"создает для них две подготовленные библиотеки.

Вы можете выполнить сборку примера кода из командной строки комплектов SDK и NDK или с помощью Eclipse* IDE.

Сборка примера из командной строки

>cd <projectdir> 
         ><ndkdir>/ndk-build 

>cd <projectdir>
         >android update project -p . -s
         >ant debug
         >adb install bin/ArrayAddActivity-debug.apk 

1. Скопируйте заголовки Intel Integrated Performance Primitives и библиотеки в папку вашего проекта (например, <каталог_проекта>/ipp).
2. Запустите сценарий "ndk-build"из каталога проекта для сборки оригинального кода.
3. Создайте пакет Android и установите приложение.

Сборка примера с помощью Eclipse* IDE

>cd <projectdir>
         ><ndkdir>/ndk-build 

1. Скопируйте заголовки Intel Integrated Performance Primitives и библиотеки в папку вашего проекта (например, <каталог_проекта>/ipp).
2. В системе Eclipse щелкните File>> New>> Project...>> Android>> Android Project from Existing Code. В "корневом каталоге"выберите папку, где находится пример кода и нажмите Finish.
3. Запустите сценарий "ndk-build"в каталоге проекта для сборки оригинального кода:
4. Выполните сборку приложения в Eclipse IDE и установите файл .apk.

Заключение
В этой статье представлен краткий обзор использования библиотек Intel Integrated Performance Primitives с оригинальными приложениями Android. Для получения дополнительной информации о функциях Intel Integrated Performance Primitives см. руководство по Intel Integrated Performance Primitives.

Егор Чураев

Файлы для загрузки

Инструментальные средства Intel® HTML5 для разработки мобильных приложений [PDF 821,98 КБ]
Исходный код iOS [файл .ZIP, 168 КБ]
Результирующий исходный код средств разработки HTML5 [файл .ZIP, 86 КБ]

HTML5 – это новый стандарт HTML. Не так давно корпорация Intel объявила о выпуске комплекта инструментальных средств HTML5 для разработки мобильных приложений. В этой статье представлено использование этих средств для процесса переноса приложения акселерометра Apple iOS* в среду HTML5. Имейте в виду, что код, создаваемый автоматически с помощью комплекта XDK Intel®, может содержать лицензионный код, разработанный на условиях одной или нескольких лицензий, представленных в приложении A к настоящему документу. Пожалуйста, изучите выходные данные комплекта Intel XDK для получения информации о том, какие библиотеки используются для создания вашего приложения.

Средство переноса приложений Intel® HTML5 App Porter

Первое, что мы сделаем, это возьмем приложение акселерометра для iOS и преобразуем его исходный код Objective-C* в формат HTML5. Мы сделаем это с помощью средства переноса приложений Intel® HTML5 App Porter и исходного кода, который можно найти в файле: [iOS_source.zip] (Примечание. Пример кода IOS_source предоставляется на условиях лицензии на примеры кода ПО Intel, которая подробно описывается в приложении B).Вы можете скачать средство Intel HTML5 App Porter на вкладке Tool сайта: http://software.intel.com/ru-ru/html5. После заполнения и отправки формы с вашим адресом электронной почты вы получите ссылки для загрузки этого средства. Инструкции по его использованию можно найти на следующем сайте: http://software.intel.com/ru-ru/html5/articles/tutorial-creating-an-html5-app-from-a-native-ios-project-with-intel-html5-app-porter-tool

Когда вы закончите все действия, вы получите исходный код HTML5.

Intel XDK

Вы можете открыть код HTML5 в любом средстве IDE. Корпорация Intel предлагает для вас удобное средство для разработки приложений HTML5: Intel XDK - комплект разработчика кроссплатформенных приложений (http://software.intel.com/ru-ru/html5/tools). Используя комплект Intel XDK, разработчики могут создавать единый исходный код для установки на многих устройствах. Что особенно удобно, так это отсутствие необходимости установки средства на вашем компьютере. Вы можете установить его в качестве расширения браузера Google Chrome*. Если вы используете другой браузер, вы должны загрузить и запустить файл JavaScript*. Иногда может потребоваться обновить среду Java*.

После установки комплекта Intel XDK вы увидите главное окно:

Если вам нужно выполнить перенос существующего кода, нажмите большую кнопку "Start new".

Если вы создаете новый проект, введите имя проекта и установите флажок "Create your own from scratch", как это показано на следующем снимке экрана.

Установите флажок "Use a blank project". Через некоторое время отобразится сообщение "Application Created Successfully!"

Нажмите "Open project folder".

Удалите все файлы из этой папки и скопируйте перенесенные файлы. На этом перенос приложения акселерометра не закончен. Мы все еще должны написать для него интерфейс. Можно удалить методы, созданные средством Intel HTML5 App Porter. Удалите следующие файлы:

• todo_api_application__uiaccelerometerdelegate.js
• todo_api_application_uiacceleration.js
• todo_api_application_uiaccelerometer.js
• todo_api_js_c_global.js

Для обновления проекта в Intel XDK перейдите в окно редактора в эмуляторе Windows.

Откройте файл index.htmlи удалите строки слева от включенных файлов.

Откройте файл todo_api_application_appdelegate.jsи примените неназначенное свойство представителя "window".

application.AppDelegate.prototype.setWindow = function(arg1) {
    // ================================================================
    // REFERENCES TO THIS FUNCTION:
    // line(17): C:WorkBloggingechuraevAccelerometerAccelerometerAppDelegate.m
    //    In scope: AppDelegate.application_didFinishLaunchingWithOptions
    //    Actual arguments types: [*js.APT.View]
    //    Expected return type: [unknown type]
    //
    //if (APT.Global.THROW_IF_NOT_IMPLEMENTED)
    //{
        // TODO remove exception handling when implementing this method
       // throw "Not implemented function: application.AppDelegate.setWindow";
    //}
this._window = arg1;
};

application.AppDelegate.prototype.window = function() {
    // ================================================================
    // REFERENCES TO THIS FUNCTION:
    // line(20): C:WorkBloggingechuraevAccelerometerAccelerometerAppDelegate.m
    //    In scope: AppDelegate.application_didFinishLaunchingWithOptions
    //    Actual arguments types: none
    //    Expected return type: [unknown type]
    //
    // line(21): C:WorkBloggingechuraevAccelerometerAccelerometerAppDelegate.m
    //    In scope: AppDelegate.application_didFinishLaunchingWithOptions
    //    Actual arguments types: none
    //    Expected return type: [unknown type]
    //
    //if (APT.Global.THROW_IF_NOT_IMPLEMENTED)
    //{
        // TODO remove exception handling when implementing this method
       // throw "Not implemented function: application.AppDelegate.window";
    //}
return this._window;
};

Откройте файл viewcontroller.js. Удалите все функции, используемые для работы с акселерометром в старом приложении iOS. По завершении мы получим следующий файл:

APT.createNamespace("application");

document.addEventListener("appMobi.device.ready",onDeviceReady,false);

APT.ViewController = Class.$define("APT.ViewController");

application.ViewController = Class.$define("application.ViewController", APT.ViewController, {
    __init__: function() {
        this.$super();
    };>});

В файле ViewController_View_774585933.cssнужно изменить стили цвета элементов с черного на белый для возможности прочтения на черном фоне: color: rgba(0,0,0,1);на color: rgba(256,256,256,1);. В результате мы получим:

div#Label_590244915
{
	left: 20px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 320px;
	top: 0px;
	opacity: 1;
}
div#Label_781338720
{
	left: 20px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 42px;
	top: 29px;
	opacity: 1;
}
div#Label_463949782
{
	left: 20px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 42px;
	top: 51px;
	opacity: 1;
}
div#Label_817497855
{
	left: 20px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 42px;
	top: 74px;
	opacity: 1;
}
div#Label_705687206
{
	left: 70px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 42px;
	top: 29px;
	opacity: 1;
}
div#Label_782673145
{
	left: 70px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 42px;
	top: 51px;
	opacity: 1;
}
div#Label_1067317462
{
	left: 70px;
	color: rgba(256,256,256,1);
	height: 21px;
	position: absolute;
	text-align: left;
	width: 42px;
	top: 74px;
	opacity: 1;
}
div#View_774585933
{
	left: 0px;
	height: 548px;
	position: absolute;
	width: 320px;
	top: 20px;
	opacity: 1;
}

После обновления окна эмулятора вы должны увидеть:

 

Для написания кода функций акселерометра мы должны использовать библиотеку appMobi JavaScript. Документация для этой библиотеки находится здесь. Она устанавливается во время загрузки комплекта Intel XDK.

Откройте файл index.htmlи добавьте следующую строку в список сценариев:

<script type="text/javascript" charset="utf-8" src="http://localhost:58888/_appMobi/appmobi.js"></script>

Откройте файл ViewController_View_774585933.html. Мы должны переименовать поля так, чтобы они имели логически приемлемые имена:

<div data-apt-class="Label" id="Label_705687206">0</div>
<div data-apt-class="Label" id="Label_782673145">0</div>
<div data-apt-class="Label" id="Label_1067317462">0</div>

на:

<div data-apt-class="Label" id="accel_x">0</div>
<div data-apt-class="Label" id="accel_y">0</div>
<div data-apt-class="Label" id="accel_z">0</div>

То же самое должно быть сделано в файле ViewController_View_774585933.css, где мы должны переименовать имена стилей.

Откройте файл viewcontroller.jsи напишите несколько функций для использования акселерометра.

function suc(a) {
    document.getElementById('accel_x').innerHTML = a.x;
    document.getElementById('accel_y').innerHTML = a.y;
    document.getElementById('accel_z').innerHTML = a.z;
}

var watchAccel = function () {
    var opt = {};
    opt.frequency = 5;
    timer = AppMobi.accelerometer.watchAcceleration(suc, opt);
}

function onDeviceReady() {
    watchAccel();
}
document.addEventListener("appMobi.device.ready",onDeviceReady,false);

Обновите проект, и он будет отображен в окне эмулятора:

Работу акселерометра в среде Intel XDK можно увидеть, используя панель "ACCELEROMETER":

Приложение должно выглядеть следующим образом:

Полный исходный код приложения можно найти здесь.
Приложение A: Лицензионные соглашения для кода комплекта Intel® XDK

Приложение B: Лицензионное соглашение на примеры кода ПО Intel

Intel и логотип Intel являются товарными знаками корпорации Intel в США и/или в других странах.
© Корпорация Intel, 2013 г. Все права защищены.
*Другие наименования и товарные знаки являются собственностью своих законных владельцев.

With the dramatic acceptance rate of smartphones and tablets has come an enormous shift in the way spontaneous experiences are delivered on these touch devices. Native application developers have incorporated touch events to improve the user experience and change the way users interface with their content. Mobile devices such as smartphones and tablets generally have a capacitive touch-sensitive screen to capture interactions made with the user's fingers. As the mobile web evolves to enable increasingly sophisticated applications, web developers need a way to handle these events. For instance, almost any fast game requires players to press several buttons at once, which, in the perspective of a touchscreen, infers multi-touch.

Using the Canvas element in HTML5

In this article we will dive into the touch events API furnished on Android* devices using HTML5. Further, we investigate what kind of applications can be developed and present some best techniques and strategies that make it easier to develop touch-empowered applications. Only recently have mobile applications been able to handle touch events using the HTML5 cross-platform technology. This opens up an entirely new path for making mobile applications more "native-like.” Assuming that we combine this touch event handling with HTML5's new canvas component, we can capture the user's movements and allow them to draw on the canvas component. HTML5 defines the <canvas> component as "a resolution-dependent bitmap canvas which can be used for rendering graphs, game graphics or other visual images on the fly." Per the web definition “Canvas consists of a drawable region defined in HTML code with height and width attributes. JavaScript* code may access the area through a full set of drawing functions.”

Using HTML5 touch events, applications can give users the same great experience that they find with native applications. By offering touch and different gesture-based controls, app developers can help users swiftly traverse through apps or build fun and interactive games.

Developer Guidelines

Let’s plunge in and see how we can use the HTML5 canvas component to capture user touch events.

As stated by W3C, “This specification defines the 5th major version, first minor revision of the core language of the World Wide Web: the Hypertext Markup Language (HTML).”

There are four types of touch events:

• touchstart
• touchmove
• touchend
• touchcancel

Each is described further below.

touchstart

This event is triggered when the user places a touch focus on the touch surface; the focus of this event must be a component.

touchmove

This event is triggered when the user moves a touch point along the touch surface.

The focus of this event must be the same element that established the touchstart event when this touch focus was put on the surface, regardless of the fact that the touch focus has since moved outside the intelligent range of the target component.

Note that the rate we can send touchmove events depends on the speed of the app’s execution, which depends on the hardware it’s running on.

touchend

This event is triggered when the user removes a touch point from the touch surface, in addition to cases where the touch point actually leaves the touch surface, such as being dragged off the screen.

The goal of this event must be the similar element that received the touchstart event when this touch point was placed on the surface, regardless of the possibility that the touch focus has since moved outside the region of the target component.

touchcancel

This event is triggered when a touch focus has been disturbed in an implementation particular way. For example, a synchronous event or movement starts from the UI, cancelling the touch, or the touch focus leaves the archive window into a non-report region that is capable of handling user interactions. We might likewise dispatch this event type when the client places more touch focuses on the touch surface than the device or execution is designed to store. In this case the earlier touch object in the touchlist should be evacuated.

To capture touch events and interpret them onto the canvas component, we should first find out how to use the canvas component. There are a couple of things that are top priority when using standard HTML inputs with canvas.

• Text info fields raise the console (keypad) on mobile devices, blanketing 50% of the screen. To avoid this, we need to ensure that the significant parts of the canvas are not hidden by the console, or pick an alternate sort of input.
• Buttons with default settings have a tendency to be very small on mobile devices. To make buttons easier to press with a finger, set a smaller viewport or a bigger introductory scale utilizing the <meta> tag, or make the button font bigger with the CSS font style.

Let’s examine the implicit canvas API. We begin by describing the following methods from the canvas API:

• Context getContext(String contextId);
• addEventListener()

The getcontext() method is used to acquire the rendering context and its drawing functions. addeventlistener() registers the designated listener on the EventTarget it is called on. The event target may be an element in an archive, the document itself, a window, or any viable item that strengthens events.

Syntax

target.addEvenListener(type,listener,Boolean)

type

A string representing the event type to listen for (touchstart, touchmove, touchend, touchcancel).

listener

Receives a warning when an event of a specified sort happens. This must be an object executing the eventlistener interface, or a JavaScript function.

boolean

Assuming that the value is true, this value shows that the user wants to start capturing the touch event. When a capture is initiated, all the specified events will be dispatched to the enlisted listeners before being dispatched to any EventTarget underneath the events in the DOM tree.

Let’s look at some code.

<canvas id= ”touch” width=”150” height=”150”>

Sorry, your browser doesn't support the HTML5 element canvas.

</canvas>

This looks very similar to the <img> component; the main difference is that it doesn't have the <src> and <alt> qualities. The <canvas> component has just two aspects, width and height. If your renderings appear incorrect, try designating your width and height properties explicitly in the canvas characteristics, instead of with CSS. The width and height default to 300 and 150, respectively. The id will be adjusted to initialize the canvas using JavaScript, and the content inside will be used when the browser does not support it.

var cans= document.getElementById(“touch);
var canctx = canvas.getContect(‘2d’);

The variable cans acquires the canvas for drawing the graphics objects on, and canctx holds the rendering context. In this case it is a 2d graphics object.

This context encompasses the elementary methods for drawing on the canvas such as arc(), lineto(), and fill().

document.addEventListener("touchstart", startTouchDrawing, true);
document.addEventListener("touchmove", startMoveDrawing, false);
document.addEventListener("touchend", endDrawing, false);
document.addEventListener("touchcancel", cancelDrawing, false);

When users touch/move their fingers on the phone screen, individual events will be created. We have to handle the events and draw the line accordingly. For example, the next piece shows the startMoveDrawing (x, y) function:

function startMoveDrawing (event)
{ event.preventDefault();//To prevent default behavior
var eventTouch, x, y;
eventTouch = event.changedTouches[0];// Array to store previous touch cords,0 is the initial one.
x = eventTouch.pageX;//The first touch for x co-ordinate
 y = eventTouch.pageY;// The first touch for y co-ordinate

OnTouchMoveDraw(x, y);
}
function OnTouchMoveDraw (x, y)
{
	
	if (x || y)
	{
		if ((start_x === -1) || start_y === -1)
		{
			start_x = x;
			starty_y = y;
		}
		drawLine(x, y);

Here, the first contention, that is, "starttouch," is the framework event that calls the user-defined function startTouchDrawing. In the code above preventDefault method anticipates the program’s default behavior and initiates the drawing. start_x and start_y are the previous touch positions. The drawLine(x, y) method draws the line.

function drawLine(x, y) {
	ctx.beginPath();
	ctx.moveTo(start_x, start_y);
	ctx.lineTo(x, y);
	ctx.stroke();
}

The beginpath() method ensures that we are starting a new path. This begins another path wiping out the present path (if any). If you discover in animation you're getting an interfacing line from the end of your path to the start, it may be you haven't utilized the beginpath() capacity from the start. To generate a path with HTML5 Canvas, we can associate different subpaths. The completion purpose of every new subpath turns into the new setting focus. We can use the lineto(), arcto(), quadraticcurveto(), and beziercurveto() to develop every subpath that makes up our drawing. We can additionally utilize the beginpath() every time we need to start drawing another path (circle, line, rectangle, and so on).

The line is drawn from x, y coordinates passed in the moveTo function to the x, y coordinates passed in the line function.

To conclude, the touch screen has revolutionized the world of computing, and by using the canvas element in HTML5, touch events can be handled with great ease, making developers’ jobs much easier.

HTML5 is a future trend in the world of app development, Intel believes it is important to help experienced developers transition to this cross-platform approach and aid new developers to quickly get up to speed with this exciting new approach so that they can deploy their apps & games on nearly all modern computing platforms. Visit Intel HTML5  and Intel Android page to get more resources for your projects.

Other Related Articles and Resources 

Adding sound to your HTML5 games for Intel® Architecture-based Android* devices
Drawing App using HTML5 Canvas
Building Cross-Platform Apps with HTML5
HTML5 Home Page 

To learn more about Intel tools for the Android developer, visit Intel® Developer Zone for Android.

Intel and the Intel logo are trademarks of Intel Corporation in the U.S. and/or other countries.
Copyright © 2013 Intel Corporation. All rights reserved.
*Other names and brands may be claimed as the property of others.

The x86 Android* 4.4 (KitKat) emulator system image enables you to run an emulation of Android on your development machine. In combination with the Android SDK, you can test your Android applications on a virtual Android device based on Intel Architecture.

In order to install the emulator image add-on, you can use the Android SDK Manager (Recommended Method):

• Install Guide - Recommended Method.

Alternately, you can download the binary zip file and unzip and copy the included directory into the add-ons directory of your Android SDK installation. (Note that this method does not allow for automatic updates of the add-on):

• Install Guide - Alternate Method.

Introduction

This document will guide you through installing the Intel® Atom™ x86 image for Android* KitKat, which can be used for development on Intel’s x86 architecture.

Prerequisites

The Android x86 Emulator Image requires the Android SDK to be installed. For instructions on installing and configuring the Android SDK, refer to the Android developer website (http://developer.android.com/sdk/).

Optional: The x86 Emulator Image for Android can be accelerated using Intel Hardware Accelerated Execution Manager (HAXM). For more information, refer to the "Optimization" section of this document.

Installation

Downloading through Android SDK Manager

1. Start the Android SDK Manager.
2. Under “Android 4.4 (API 19)”, select "Intel x86 Atom System Image":
   
3. Once selected, click the Install Package button.
4. Review the Intel Corporation license agreement. If you accept the terms, select Accept and click Install.
5. The SDK Manager will download and extract the system image to the appropriate location within the Android SDK directory.

Using the System Image

1. Start the Android AVD Manager and create a new AVD, setting "Target" to "Android 4.4 – API Level 19", and "CPU/ABI" to "Intel Atom (x86)".
   The Intel Atom x86 Image for Android KitKat can make use of hardware GPU features to increase the performance of games, graphics-intensive programs, and user interface elements. For the best performance make sure to check the "Use Host GPU" Box when creating the image.
   Note:The functionality and performance of GPU acceleration is highly dependent on your computer’s graphics card and graphics drivers. GPU acceleration must be enabled on a per AVD basis.
   
   
   Note: if the "Intel Atom (x86)" CPU/ABI option is not available, make sure that the system image is installed correctly.
2. Click the "Create AVD" button.
3. The AVD has been successfully created and is now ready to use:

Optimization

CPU Acceleration

The performance of the Intel Atom x86 Image for Android KitKat can be improved with hardware-based virtualization using Intel VT-x technology.

If your computer has an Intel processor with VT-x support, it is recommended that Intel Hardware Acceleration Execution Manager (HAXM) be used in conjunction with this system image. For more information about Intel HAXM, visit http://www.intel.com/software/android.

Note:Intel HAXM is for Windows and OS X operating systems only. For Linux hosts, Kernel-based Virtual Machine (KVM) can be used to accelerate emulation performance. For information on installing and configuring KVM on Ubuntu, refer to this guide:https://help.ubuntu.com/community/KVM/Installation

Other Related Articles and Resources 
Intel® Atom™ x86 Image for Android* Ice Cream Sandwich Installation Instructions - Manually
Android* 4.4 (KitKat) x86 Emulator System Image
Intel® Atom™ x86 Image for Android* 4.4 KitKat Installation Instructions - Manually
Intel for Android* Developers Learning Series #5: Installing the Android* SDK for Intel® Architecture
Accelerating compilation: Part 1: ccache

To learn more about Intel tools for the Android developer, visit Intel® Developer Zone for Android.

Introduction

This document will guide you through installing the Intel® Atom™ x86 image for Android* KitKat, which can be used for development on Intel’s x86 architecture.

Prerequisites

The Android x86 Emulator Image requires the Android SDK to be installed. For instructions on installing and configuring the Android SDK, refer to the Android developer website (http://developer.android.com/sdk/).

Optional: The x86 Emulator Image for Android can be accelerated using Intel Hardware Accelerated Execution Manager (HAXM). For more information, refer to the "Optimization" section of this document.

Installation

Downloading Manually (Instructions for both Windows and Mac OSX)

1. Close any open SDK or AVD windows.
2. Go to http://www.intel.com/software/android.
3. Click Tools & Downloads
4. Download the Intel x86 Atom System Image

(Android* 4.4 KitKat x86 Emulator System Image).

Windows

1. Navigate to the directory where the Android SDK is located. If you installed using an executable for the installation, you can find the Android SDK in the following locations.
   1. If you installed for “everyone” on 64bit: "c:\Program Files (x86)\android" 32bit: "c:\Program Files\android"
   2. If installed “just for me”: "c:\users\<username>\AppData\local\android"
2. The following instructions and screenshots are for a windows install "just for me" but the files need to be extracted to the same relative path to your Android install
   
3. The system-images directory contains Android system images, separated by architecture: If a “system-images” directory or an "android-19" directory does not exist then you will need to create it.
   
4. Expand android-19 (this directory contains API Level 19 system images):
   
5. Extract the x86 directory contained in the downloaded system image archive directly into the android-19 directory. The directory “./Android-SDK/system-images/android-19/x86/” should have the following files:
   
6. The system image is now installed and ready to be used.

Mac OSX

1. Navigate to the directory where you extracted the SDK
   
2. The system-images directory contains Android system images, separated by architecture: If a “system-images” directory or an "android-19" directory does not exist then you will need to create it / them.
   
3. Expand android-19(this directory contains API Level 19 system images):
   
4. Extract the x86 directory contained in the downloaded system image archive directly into the android-19 directory. The directory “./android-sdk-macosx/system-images/android-19/x86/” should have the following files:
   
5. The system image is now installed and ready to be used.

Using the System Image

1. Start the Android AVD Manager and create a new AVD, setting "Target" to "Android 4.4 – API Level 19", and "CPU/ABI" to "Intel Atom (x86)".
   The Intel Atom x86 Image for Android KitKat can make use of hardware GPU features to increase the performance of games, graphics-intensive programs, and user interface elements. For the best performance make sure to check the "Use Host GPU" Box when creating the image.
   Note:The functionality and performance of GPU acceleration is highly dependent on your computer’s graphics card and graphics drivers. GPU acceleration must be enabled on a per AVD basis.
   
   
   Note: if the "Intel Atom (x86)" CPU/ABI option is not available, make sure that the system image is installed correctly. You can confirm the system image installation by opening the Android SDK manger and looking at the status of the “Intel x86 Atom System Image” under “Android 4.4 (API 19)”
2. Click the "Create AVD" button.
3. The AVD has been successfully created and is now ready to use:
   

Optimization

CPU Acceleration

The performance of the Intel Atom x86 Image for Android KitKat can be improved with hardware-based virtualization using Intel VT-x technology.

If your computer has an Intel processor with VT-x support, it is recommended that Intel Hardware Acceleration Execution Manager (HAXM) be used in conjunction with this system image. For more information about Intel HAXM, visit http://www.intel.com/software/android.

Note: Intel HAXM is for Windows and OS X operating systems only. For Linux hosts, Kernel-based Virtual Machine (KVM) can be used to accelerate emulation performance. For information on installing and configuring KVM on Ubuntu, refer to this guide:https://help.ubuntu.com/community/KVM/Installation