Будь-який додаток, що створюється в Android, містить файл маніфесту, AndroidManifest.xml, який зберігається в кореневому каталозі проекту. Маніфест дозволяє описувати структуру і метадані вашого додатка, його компоненти та вимоги.
Маніфест містить у собі вузли (теги) для кожного компонента (Актив ностей, Сервісів, Джерел даних і широкомовні приймачів), з яких складається ваше додаток, і за допомогою фільтрів намірів (Intent Filters) і повноважень визначає, яким чином вони взаємодіють один з другом і зі сторонніми програмами.
У маніфесті передбачені атрибути для вказівки метаданих (знач- ков і візуальних стилів). Треба відзначити, що додаткові вузли верх- нього рівня можна використовувати для опису налаштувань безпеки, модульних тестів (юніт-тестів), апаратних і системних вимог.
Маніфест містить кореневої тег
Задіюйте атрибут versionCode для завдання поточної версії при- розкладання у вигляді цілого числа. Це внутрішнє значення використовується для порівняння версій програми. Застосуйте атрибут versionName для указу- ня публічної версії, яка виводиться для користувачів.
типовий тег
android: versionCode = "1" android: versionName = "0.9 Beta">
[... вкладені вузли маніфесту ...]
тег
• uses-sdk. Дозволяє задати мінімальну, максимальну і цільову версії SDK, які повинні бути доступні на пристрої, щоб ваше додаток змогло правильно функціонувати. Грунтуючись на версії SDK, яка підтримується платформою, і використовуючи поєднання атрибутів minSDKVersion, maxSDKVersion і targetSDKVersion, ви можете обмежити коло пристроїв, здатного запускати додаток.
Атрибут minSDKVersion вказує на мінімальну версію SDK, що містить API, яка використовується у вашій програмі. Якщо не поставите мінімальну версію, таким чином, застосовується значення по умол- чанію, а ваше додаток не зможе коректно працювати, якщо по- намагається отримати доступ до API, які недоступні на поточному пристрої.
Атрибут maxSDKVersion дозволяє визначити саму пізню версію, яку ви готові підтримувати. Ваша програма буде невидимим в Android Market для пристроїв, керованих систе- мій з більш свіжою версією. Встановлювати значення для цього атрибута рекомендується тільки в тому випадку, якщо ви абсолютно уве- рени, що програма не працює на платформі з версією, вище заданої.
targetSDKVersion дозволяє вказати платформу, для якої ви розробляли і тестували додаток. Встановлюючи значення для цього атрибута, ви повідомляєте системі, що для підтримки цієї конкретної версії не потрібно ніяких змін, пов'язаних з прямою або зворотною сумісністю:
• uses-configuration. Використовуйте теги uses-configuration, щоб вказати всі механізми введення даних, підтримувані вашим додатком. Ви можете задати будь-яку комбінацію, яка містить наступні пристрої:
§ reqHardKeyboard - якщо вашому додатку потрібна апаратна клавіатура, вкажіть значення true;
§ reqKeyboardType - дозволяє задати тип клавіатури - nokeys, qwerty, twelvekey або undefined;
§ reqNavigation - якщо потрібно пристрій для навігації, ука- житі одне з наступних значень - nonav, dpad, trackball, wheel або undefined;
§ reqTouchScreen - якщо вашому додатку знадобиться сен- бур'янистої екран, виберіть одне з наступних значень - notouch, stylus, finger або undefined.
Ви можете задати кілька підтримуваних конфігурацій, напри-мер пристрій з сенсорним екраном, трекболом і ап паратной клавіатурою (або qwerty, або twelvekey), як показано нижче:
Визначаючи необхідні конфігурації, пам'ятайте, що програма не буде встановлюватися на пристроях, які не відповідають ні однієї із заданих комбінацій. У прикладі, наведеному вище, пристрій з qwerty-клавіатурою і маніпулятором D-pad (але без сенсорного екрану або трекбола) підтримуватися не буде. В ідеалі ви повинні разраба- ють додатки таким чином, щоб вони працювали з будь-яким соче- танием пристроїв введення, в цьому випадку тег uses-configuration вказувати необов'язково.
• uses-feature. Одна з переваг Android - широкий діапазон апаратних платформ, на яких він може працювати. Іспользуй- ті прості теги uses-feature, щоб задати всі необхідні додатком апаратні можливості. Це запобіжить установку вашої програми на пристрої, які не відповідають аппа- ратним вимогам. Можете запитати підтримку будь-якого необя- ково для сумісних пристроїв обладнання. На сегод- няшная день апаратні можливості пропонують наступні варіанти:
§ android.hardware.camera (якщо для роботи додатка потрібна ап паратная камера);
§ android.hardware.camera.autofocus (якщо потрібно камера з автома- тичної фокусуванням).
Ви також можете використовувати тег uses-feature, щоб задати мінімальну версію OpenGL, яка потрібна для роботи вашого додатка. За допомогою атрибута glEsVersion вкажіть версію OpenGL ES у вигляді цілого числа. Перші 16 біт відповідають ма- жорна версії, а останні - мінорній:
Точні цифри будуть змінюватись в залежності від апаратного забезпечення, але в цілому відповідність розмірів і дозволів екранів визначається наступним чином:
§ smallScreens - екрани з роздільною здатністю меншим, ніж звичайне HVGA, як правило, мова йде про QVGA;
§ anyDensity - встановіть значення true, якщо ваше додаток здатне масштабироваться для відображення на екрані з будь-яким дозволом.
У версії SDK 1.6 (API level 4) значення за замовчуванням для кожного атрибута - true. Використовуйте цей тег для вказівки розмірів екранів, які ви не підтримуєте:
По можливості потрібно оптимізувати додатки для екранів з раз- ними розмірами і щільністю пікселів, використовуючи каталоги з ресур- самі, як показано далі в розділі. Якщо ви вкажете тег supports-screen, виключаючи певні екранні розміри, додаток не зможе встановлюватися на пристрої з непідтримуваними екранами.
• аpplication. У маніфесті може бути присутнім тільки один екземпляр даного тега. У ньому використовуються атрибути, які містять метадані для вашого застосування (включаючи його назву, значок і візуальний стиль). Під час розробки ви повинні встановлювати атрибуту debuggable значення true, щоб активізувати режим від- ладком, хоча для кінцевих версій, швидше за все, його потрібно відключити.
тег
[... вкладені теги ...]
• аctivity. тег
За допомогою цих тегів, додайте головну Активність, яка буде запу- скотився першої, а також інші екрани і діалогові вікна, які можуть показуватися. Спроба запустити Активності без соответству- ющего опису в маніфесті призведе до викиду винятку. кожен тег
§ service. Як і в попередньому випадку, кожен клас Сервісу повинен мати тег service (Сервіси детально розглядаються в розділі 9). Теги service підтримують вкладені вузли
§ provider. За допомогою цього тега вказуються всі Джерела даних в додатку. Джерела даних, описані в главі 7, використовуються для управління доступом до баз даних і для обміну інформа- цією в рамках однієї або декількох програм.
§ receiver. Додаючи в маніфест тег receiver, можна зарегистри- ровать Широкомовний приймач, що не запускаючи при цьому додатка ються. Як переконайтеся в розділі 5, Широкомовні приймачі від- злежуватися події на глобальному рівні: пройшовши реєстрацію, вони почнуть спрацьовувати при трансляції системою або додатком відповідного Наміри. Реєструючи їх в маніфесті, може- ті зробити цей процес повністю анонімним. При трансляції відповідного Наміри ваше додаток стартує автома- тично, запускаючи зареєстрований Приймач. • permission. Сторонні додатки також можуть вказувати повно- мочія, перш ніж надавати доступ до загальних програмним компонентам. Щоб обмежити доступ до компоненту додатка, ви повинні описати відповідні повноваження в маніфесті. Для цього необхідно використовувати тег permission. Компоненти поточної програми можуть вимагати повноваження за допомогою атрибутів android: permission. Інші програми повинні містити в своєму маніфесті теги uses-permission, щоб використовувати ці захищені компоненти. Усередині тега permission ви можете вказати рівень доступу, який забезпечується даними повноваженням (normal, dangerous, signature, signatureOrSystem), мітку і зовнішній ресурс, що містить опис і пояснення ризиків, якими супроводжується видача цього повно- мочія. • instrumentation. Класи, похідні від Instrumentation, нада- ють фреймворк для тестування програмних компонентів під час їх виконання. Вони містять методи-перехоплювачі, з допомогою на гою яких відслідковуються робота програми і її взаємодії з системними ресурсами. Майстер створення проектів в складі ADT (New Project Wizard) автома- тично додає файл з маніфестом для кожного нового проекту. Ви ще повернетеся до маніфесту, як тільки познайомитеся з усіма ком- компонентами, з яких складається програма. Кожна з таких вкладок містить візуальний інтерфейс для управління настройками додатку, безпеки і тестування, а по- останньої (використовує ім'я файлу з маніфестом) відкриває доступ до ви- Ходнев XML-коду.
Особливий інтерес представляє вкладка Application, показана на рис. 3.2. Використовуйте її для управління вузлом application і деревом компонен- тов додатки.
На панелі Application Attributes вкажіть властивості додатка - значок, мітку і візуальний стиль. Нижче знаходиться дерево Application Nodes, з допомогою на гою якого можна управляти програмними компонентами, в тому числі їх атрибутами і будь-якими вкладеними Фільтрами намірів, пов'язаними з ними.
Життєвий цикл додатки в Android
На відміну від більшості традиційних платформ в Android додатка вання мають обмежений контроль над життєвим циклом. Программ- ні компоненти повинні відстежувати зміни в стані додатки і реагувати на них відповідним чином, приділяючи особливу увагу підготовці до передчасного завершення роботи.
За замовчуванням кожен додаток в Android працює у власному процесі - окремому примірнику віртуальної машини Dalvik. Управле- ня пам'яттю і процесами - виключно прерогатива системи.
Хоч це і велика рідкість, але все ж можна зробити так, щоб про- програмних компоненти однієї програми працювали в різних процесах або щоб кілька додатків використовували один і той же процес. Для це потрібно встановити атрибут android: process для тега, який описує відповідний компонент всередині маніфесту.
Android активно управляє своїми ресурсами, роблячи все можливе, щоб пристрій залишалося чуйним. Тобто робота процесів (вме- сте з додатками, які вони в собі виконують) в деяких випадках може бути завершена без попередження. Це стосується ситуацій, коли необхідно виділити ресурси для додатків з більш високим пріоритетом, які, як правило, повинні в цей момент взаємодіяти з користувачем. Призначення пріоритетів для процесів розглядається в наступному розділі.