Главная » Программирование игр под Android » ОПРЕДЕЛЕНИЕ ПРИЛОЖЕНИЯ ANDROID: ФАЙЛ МАНИФЕСТА

0

Приложение Android может состоять из большого количества различных компонентов.

Активности – компоненты представления пользовательского интерфейса и взаимодействия с ним.

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

Поставщики содержимого – делают части вашего приложения доступными для других приложений.

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

Приемники вещания – реагируют на особые намерения и могут выполнять действия: запустить определенную активность или сгенерировать другое намерение для операционной системы.

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

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

ПРИМЕЧАНИЕ

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

Файл манифеста выполняет намного больше задач, чем просто определение компонентов приложения. Следующий список показывает соответствующие части файла манифеста в контексте разработки игр: версия приложения, отображаемая и используемая на Android Market; О версии Android, на которых наше приложение может работать; О профили оборудования, требуемые приложением (например, наличие мультитач, определенные разрешения дисплея, поддержка OpenGL ES 2.0); разрешения на использование определенных компонентов (запись на SD-карту, доступ к сети и т. д.).

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

Элемент <manifest>

Тег <mani f est> является корневым элементом файла Androi dMani f est. xml. Вот простой пример:

Если ранее вы уже имели дело с XML-файлами, то вам должно быть все понятно про первую строчку. Тег <manifest> определяет пространство имен android, используемое во всем файле манифеста. Атрибут package задает корневой пакет нашего приложения. Позже мы соотнесем определенные классы нашего приложения с этим именем пакета.

Атрибуты versionCode и versionName определяют версию нашего приложения в двух формах, versi onCode – целое число, которое необходимо увеличивать каждый раз, когда мы публикуем новую версию приложения. Оно используется в Android Market для отслеживания нашей версии приложения. versionName показывается пользователям Android Market при посещении страницы приложения. Здесь мы можем применять любое строковое значение.

Атрибут install Location доступен нам, только если мы в Eclipse опеределили в качестве цели нашего приложения версию Android 2.2 и выше. Он определяет, где должно быть установлено приложение. Строка preferExternal сообщает системе, что приложение должно устанавливаться на карту памяти. Такое возможно только с версии Android 2.2, для более старых прошивок параметр будет игнорироваться. Начиная с Android 2.2 приложение всегда будет устанавливаться во внутреннее хранилище, если существует такая возможность.

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

Внутри элемента <manifest> мы определяем компоненты приложения, разрешения, профили оборудования и поддерживаемые версии Android.

Элемент <application>

Как и в случае с элементом <mani fest>, обсудим элемент <applicati оп> на примере:

Кое-что тут выглядит странно. Что означают строки @drawable/icon и @string/ appname? При разработке стандартного приложения Android мы обычно создаем много XML-файлов, каждый из которых определяет некоторую часть нашего приложения. Чтобы иметь возможность точно идентифицировать эти части, нам нужна возможность обращаться к ресурсам, не определенным в файлах XML (например, к изображениям или интернационализированным строкам). Эти ресурсы располагаются в подпапках каталога / res.

Для обращения к этим ресурсам мы используем указанную выше нотацию. Знак @ указывает, что нам необходим внешний по отношению к манифесту ресурс. Строка после @ определяет тип ресурса, с которым мы связываемся, что напрямую связывает его с одним из каталогов или файлов в папке /res. Последняя часть определяет имя ресурса – в примере выше это изображение с названием i con и строка appjiame. В случае с изображением имя ресурса – это название файла, расположенного в каталоге res/drawable/. Обратите внимание – имя файла указано без расширения (PNG или JPG). Android добавит его автоматически, просканировав папку res/drawabl в/. Строка appjiame определена в файле res/val ues/stri ngs. xml, содержащем строки, используемые приложением. Имя строки определено в этом файле.

ПРИМЕЧАНИЕ

Обработка ресурсов в Android очень гибка, но одновременно сложна. В данной е я решил почти полностью пропустить эту тему по двум причинам: отсутствие необходимости в этом для написания игр и желание иметь полный контроль над нашими ресурсами. У Android есть привычка изменять ресурсы, размещенные в каталоге res/ (особенно изображения в drawables). Как разработчикам игр нам это совсем не нужно. Единственная вещь, которую я бы предложил, – использовать систему управления ресурсами Android для интернационализированных строк. В нашей е это не понадобится; вместо этого мы будем применять более подходящий для игровых приложений инструмент – дружественную папку assets/, в которой наши ресурсы никто не будет трогать и которая позволит нам создавать внутри собственную иерархию.

Теперь значение атрибутов элемента должно стать более понятным. Атрибут icon определяет изображение из папки res/drawable/, используемое в качестве значка нашего приложения. Этот значок будет показываться на Android Market, а также на устройстве. Кроме того, этот значок применяется по умолчанию для всех активностей, определенных внутри элемента <appl i cati on>.

Атрибут 1abel задает строку, которая будет показываться для нашего приложения в программе для запуска приложений. В примере это строка в файле res/ val ues/stri ng. xml, соответствующая тому, что мы определили при создании проекта в Eclipse. Мы можем установить ему любое значение, например My Super Awesome Game. Эта метка также является меткой по умолчанию для всех активностей, определенных внутри элемента <appl ication>, она будет показываться в строке заголовка нашего приложения.

Атрибут debuggabl е определяет, может ли наше приложение подвергаться отладке. В процессе разработки лучше установить ему значение true (иначе отладка в Eclipse будет невозможна), но при размещении готовой программы на Android Market желательно задать значение false.

Мы обсудили очень маленькую часть атрибутов, которые вы может установить для элемента <арр1 i cati оп>. Однако для наших целей этого вполне достаточно. Если вы хотите узнать побольше, то сможете найти полную документацию на сайте Android Developers.

Элемент <application> содержит определения всех компонентов приложения, включая активности и сервисы, а также любые используемые дополнительные библиотеки.

Элемент <activity>

Чем дальше, тем интереснее. Вот гипотетический пример для нашей игры Мистер Ном:

Для начала взглянем на атрибуты тега <acti vity>.

name – определяет имя класса активности, которое связано с атрибутом package, установленным нами в элементе <mani fest>. Вы также можете ввести здесь полное имя класса.

label – такой же атрибут мы уже определили ранее в теге <application>. Эта строка отражается в строке заголовка активности (если она присутствует). Кроме того, данная метка используется в качестве текста, показываемого в программе для запуска приложений, если данная активность является точкой хвхождения для приложения. Если не определить данный атрибут, будет использоваться соответствующий атрибут элемента <appli cati оп>. Заметьте, что в данном случае я применил саму строку, а не ссылку на нее в файле stri ngs. xml.

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

configChanges – переориентация устройства или сдвиг клавиатурного блока рассматриваются как изменение конфигурации. В случае подобных изменений Android уничтожает и перезагружает наше приложение для применения изменений. В случае с играми это не лучший вариант поведения. Атрибут conf i gChanges элемента <acti/Vity> помогает справиться с этой проблемой. Он дает возможность определить, какие изменения конфигурации мы хотим обрабатывать сами, без пересоздания активности. Множественные изменения конфигурации могут быть заданы с использованием символа  для склеивания нескольких вариантов. В примере выше мы сами обрабатываем клавиатуру, keyboardHi dden и изменение ориентации.

Как и в случае с элементом <appl i cati оп>, на самом деле атрибутов для элемента <activity>, конечно, намного больше. Но для разработки игр мы ограничимся описанными выше.

Вы, должно быть, заметили, что элемент <acti vi ty> не пуст – он содержит в себе другой элемент, а тот, в свою очередь, содержит два. Для чего они нужны?

Как я указывал ранее, не существует единой точки входа в приложение Android. Вместо этого у нас есть несколько таких точек в виде активностей и сервисов, запускающихся при получении намерений от системы или сторонних приложений. Нам каким-то образом необходимо сообщить Android, какие активности и сервисы (и как именно) будут реагировать на определенные намерения. Именно для этого нужен атрибут <i ntent-fi1ter>.

В рассматриваемом примере мы определили два типа фильтров намерений: <action> h<category>. Элемент <action> сообщает системе, что наша активность является главной точкой входа в программу. Элемент <category> указывает, что мы хотим, чтобы активность была добавлена в программу для запуска приложений. Оба элемента вместе позволяют Android сделать вывод, что при нажатии значка приложения в программе для запуска приложений должна запускаться именно эта активность. Значение элементов <acti оп> и <category> – имя, определяющее намерение, на которое следует реагировать.android.intent.action.MAIN – специальное намерение, которое система Android использует для запуска главной активности приложения. Намерение android, intent .category. LAUNCHER используется для оповещения операционной системы о том, должна ли данная активность иметь возможность запуска через программу для запуска приложений (application launcher).

В нашем примере есть только одна активность с двумя этими фильтрами. Однако стандартное приложение Android почти всегда имеет несколько активностей, и все они также должны быть определены в файле mani fest. xml. Вот пример определения подобной субактивности:

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

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

ПРИМЕЧАНИЕ

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

Элемент <uses-permission>

Теперь оставим элемент <appl1catiоп> и вернемся к элементам, определенным нами в качестве дочерних для элемента <mani fest>. Один из них – <uses-permission>.

Android обладает тщательно проработанной моделью обеспечения безопасности. Каждое приложение работает в рамках собственного процесса и виртуальной машины, под собственным пользователем Linux и группой и не может влиять на другие приложения. Кроме того, система ограничивает применение своих ресурсов (сетевой доступ, карта памяти, диктофон и т. д.). Если нашему приложению необходимо их использовать, мы должны запросить на это разрешение с помощью элемента <uses-permission>.

Разрешение всегда запрашивается в следующей форме (строка определяет название необходимого нам разрешения):

Вот несколько названий разрешений, которые нам могут понадобиться: О androi d. permi ssi on. REC0RD AUDI0 – получение доступа к оборудованию для записи звука; android, permi ssi on. INTERNET – получение доступа ко всем сетевым API, что позволяет, например, получить изображение из Интернета или загрузить лучшие результаты; androi d. permi ssi on. WRITE EXTERNAL STORAGE – дает возможность читать и записывать файлы на внешний носитель (обычно на SD-карту); androi d. permi ssi on. WAKEJ.0CK – позволяет осуществлять так называемую защиту от блокировки. С ее помощью мы можем препятствовать переходу устройства в спящий режим при отсутствии нажатий экрана в течение некоторого времени. Такое может произойти, например, при управлении игрой с помощью акселерометра.

Для получения доступа к сетевым API мы определяем следующий элемент в качестве дочернего для <mai nfest>:

Для всех дополнительных разрешений мы просто добавляем еще элементы <uses-permission>.

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

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

Еще одна вещь, о которой необходимо сказать, – когда пользователь инсталлирует приложение, его первым делом попросят просмотреть все разрешения, требуемые программой. Многие просто пропускают этот текст и доверяют автору. Однако некоторые более ответственно относятся к своим решениям и внимательно изучают разрешения. Если вы просите что-то подозрительное (например, возможность отсылать платные CMC или получать координаты пользователя), то можете получить неодобрительную реакцию от них в разделе Комментарии на Android Market. Если вам необходимо одно из таких проблемных разрешений, сообщите пользователю, зачем именно оно вам нужно, в описании программы. Но лучше всего вообще избегать подобных разрешений.

Элемент <uses-feature>

Если вы сами – пользователь Android и владеете устройством со старой версией ОС (например, 1.5), то, видимо, заметили, что некоторые отличные приложения не показываются вам на Android Market. Причина этого – использование элемента <uses-feature> в файле манифеста приложения.

Android Market фильтрует все доступные приложения, исходя из вашего профиля оборудования. С помощью элемента <uses-feature> приложение может определить, какие аппаратные возможности ему необходимы (например, мультитач или поддержка OpenGL ES 2.0). Любое устройство, не обладающее указанными возможностями, не будет видеть приложение.

Элемент <uses-feature> обладает следующими атрибутами:

Атрибут name определяет саму возможность (функцию). Атрибут requi red сообщает фильтру, необходима ли нам эта возможность для работы программы или просто было бы хорошо ее иметь. Последний атрибут опционален и используется только в случае, если для работы обязательно требуется определенная версия OpenGL ES.

Для разработчиков игр наиболее важными являются следующие требования: android. hardware. touchscreen. multi touch – требует от устройства наличия мультитач-экрана, поддерживающего некоторые распространенные возможности. Такие типы дисплеев могут иметь проблемы с отслеживанием независимых касаний, поэтому вам нужно подумать, достаточно ли этих возможностей для вашей игры; android.hardware.touchscreen.multitouch.distinct – старший брат предыдущей возможности. Он запрашивает полный набор мультитач-способностей, позволяющих реализовать все доступные функции.

Более подробно мы рассмотрим мультитач позже в этой е. На данный момент нам необходимо помнить, что, если наша игра требует дисплей с мультитач, мы можем отфильтровать все устройства, не поддерживающие эту возможность, указав элемент <uses-feature> с одной из нескольких возможностей, например, так:

Другая полезная вещь для разработчиков игр – определение необходимой версии OpenGL ES. В нашей е мы имеем дело с OpenGL ESI.OhI.I.B этом случае нам нет необходимости задавать соответствующий элемент <uses-feature>, поскольку две вышеупомянутые версии не слишком друг от друга отличаются. Однако любое устройство, обладающее поддержкой OpenGL ES 2.0, намного опережает по своим графическим возможностям предшественников. Если наша игра визуально сложна и требует много вычислительной мощности, мы можем затребовать версию OpenGL ES 2.0, чтобы приложение было видно только аппаратам, поддерживающим эту библиотеку. Заметьте, что мы не используем OpenGL ES 2.0, а просто фильтруем устройства таким образом, чтобы наш код на OpenGL ES 1.x получил достаточно вычислительной мощности. Сделать это можно так:

Теперь наша игра будет видна только устройствам с поддержкой OpenGL ES 2.0, что гарантирует нам использование мощного графического процессора.

ПРИМЕЧАНИЕ

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

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

Элемент <uses-sdk>

Последний элемент, который мы поместим в наш файл манифеста, – <uses-sdk>, дочерний для <mani f est>. Мы неявно уже задавали его при создании проекта Hel1о World когда определяли минимальную версию SDK в диалоговом окне New Android Project (Новый проект Android). Итак, для чего нужен этот элемент? Рассмотрим пример:

Как обсуждалось, каждая версия Android имеет некий целочисленный параметр, также известный как версия SDK. Элемент <uses-sdk> определяет минимальную версию SDK, которую будет поддерживать наше приложение, то есть его целевую версию.

Этот элемент позволяет развертывать приложение, использующее API из более новых версий, на устройствах с более старой версией SDK. Показательный пример – API для мультитач, поддерживаемые начиная с 5-й версии SDK (Android 2.0). При создании проекта в Eclipse мы используем цель сборки, поддерживающую этот API, например SDK 5 или новее (я обычно задействую новейшую версию, 9 на момент написания). Если мы хотим, чтобы наша игра запускалась также на устройствах с версией SDK 3, необходимо определить значение атрибута mi nSdkVersi on в файле манифеста. Конечно, нам нужно будет позаботиться о том, чтобы не использовать API, недоступные в более старых версиях SDK (по крайней мере на устройствах с версией 1.5). На аппаратах с более новой версией новые функции из новых API останутся доступными.

Описанная выше конфигурация обычно вполне подходит для большинства игр (только если вы не хотите разделить ветки программного кода для разных версий API – в этом случае будет правильным установить значение атрибута mi nSdkVersi on равным минимальной версии SDK, которую вы поддерживаете).

Настройка проекта игры на Android за 10 простых шагов

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

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

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

Он должен быть доступен для отладки.

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

Активность должна быть зафиксирована в портретном или ландшафтном режиме.

Проект должен иметь доступ к SD-карте.

Он должен быть способен реализовывать защиту от блокировки.

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

1. Создайте новый проект Android в Eclipse, открыв диалог New Android Project (Новый проект Android).

2. В диалоговом окне New Android Project (Новый проект Android) определите название проекта и установите цель сборки равной последней версии SDK.

3. В том же окне введите название вашей игры, пакета (в котором будут храниться все ваши классы), а также название главной активности. Далее установите минимальную версию SDK равной 3. Нажмите Finish (Готово) для создания проекта.

4. Откройте файл AndroidMani fest. xml.

5. Чтобы устанавливать игру на карту памяти всегда, когда это возможно, добавьте атрибут  nstal  Locati on в элемент <mani fest> и установите его значение равным preferExternal.

6. Чтобы сделать доступной отладку игры, добавьте атрибут debuggabl е в элемент <applicatiоп> и установите его значение равным true.

7. Для фиксации ориентации активности добавьте атрибут screenOrientation в элемент <activity> и определите его значение (portrait или landscape).

8. Чтобы сообщить Android о том, что мы хотим обрабатывать изменения конфигурации, вызванные событиями клавиатуры, keyboardHidden и изменением ориентации дисплея, установите атрибуту conf i gChanges элемента <acti vi ty> значение keyboardkeyboa rdHi ddenori entati on.

9. Добавьте два элемента <uses-permi ssi оп> в элемент <manifest> и определите атрибуты name androi d.permi ssion.WRITE EXTERNALSTORAGE и androi d. permi ssion.WAKE  LOCK.

10. Добавьте атрибут targetSdkVersion в элемент <uses-sdk> и определите вашу целевую версию SDK. Она должна быть той же, что вы задали для целевой сборки в шаге 2.

Вот и все. Десять простых шагов – и в результате мы имеем приложение, устанавливаемое на SD-карту (в случае с Android 2.2 и выше), способное к отладке, обладающее фиксированной ориентацией экрана и не перезагружаемое при изменении конфигурации. Оно имеет доступ к карте памяти, препятствует автоматической блокировке и работает на всех версиях Android начиная с 1.5. Вот итоговый файл Androi dMani fest. xml, получившийся после осуществления всех шагов:

Как видите, я избавился от @stnng/app name в атрибутах метки элементов <application> и <activity>. Это необязательно, но мне нравится, когда все определения приложения собраны в одном месте. Теперь пришло время кода. Или…

Назначение значка для вашей игры

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

Еще раз взглянем на элемент <applcatiоп>. Здесь мы определили атрибут icon, связанный с изображением, расположенным в каталоге res/drawable и имеющим название icon. Теперь наши действия должны стать очевидными – нам необходимо заменить файл icon в каталоге drawable нашим собственным.

Если вы изучите каталог res/, то увидите не одну, а несколько папок, начинающихся с drawable (рис. 4.1).

Итак, у нас снова классическая проблема курицы и яйца.

Это произошло из-за того, что мы определили в качестве цели сборки версию SDK 3, которая поддерживает только один размер экрана. Начиная с версии 1.6 (SDK версии 4) положение изменилось.

Оказывается, существует продуманный механизм, позволяющий вам определять ваши графические ресурсы для набора так называемых плотностей. Плотность экрана – это комбинация физического размера экрана и количества пикселов на нем. Мы изучим данный вопрос подробнее позже, пока же достаточно знать, что Android определяет три плотности: 1dpi для экранов с низкой плотностью, mdpi для стандартной плотности и hdpi для дисплеев высокой плотности. Для экранов с малой плотностью мы обычно используем изображения меньшего размера, для более плотных – ресурсы высокого разрешения.

Рис. 4.1. Что случилось с каталогом res/ folder?

Итак, в случае с нашим значком нам необходимо предложить три его версии, по одной для каждой плотности. Но каков должен быть размер этих версий? К счастью, у нас уже есть значки по умолчанию в каждой папке res/drawabl е, из которых мы можем определить необходимые размеры для наших собственных значков. Файл icon в res/drawable-ldpi имеет размер 36 х 36 пикселов аналогичный файл в res/drawabl e-mdpi – 48×48 пикселов и, наконец, icon в res/drawabl е – hdpi – 72 х 72 пиксела. Все, что нам нужно, – создать версии нашего значка с соответствующими размерами и заменить файлы icon.png в каждом каталоге на наши собственные с тем же именем. Обратите внимание – ссылки на файлы в манифесте чувствительны к регистру. Чтобы избежать потенциальных проблем, всегда используйте нижний регистр.

Чтобы добиться настоящей совместимости с Android 1.5, нам необходимо добавить в проект каталог res/drawablе/ и скопировать в него файл icon.png из res/ drawabl e-mdpi/. Android 1.5 ничего не знает о других каталогах drawable, поэтому может не найти нужный нам файл.

И вот теперь уже точно мы можем заняться написанием кода под Android.

Источник: Mario Zechner / Марио Цехнер, «Программирование игр под Android», пер. Егор Сидорович, Евгений Зазноба, Издательство «Питер»

По теме:

  • Комментарии