28 ноября 2014 г.

LinearLayout

Разметка LinearLayout выравнивает все дочерние объекты представлений в одном направлении — вертикально или горизонтально, в зависимости от того, как определен атрибут ориентации android:orientation:

android:orientation="horizontal" или android:orientation="vertical"

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

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
 android:layout_width="fill_parent"
 android:layout_height="fill_parent"
 android:orientation="horizontal">
 
 <Button
  android:id="@+id/button1"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:text="Button1"/>
 <Button
  android:id="@+id/button2"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:text="Button2"/>
 <Button
  android:id="@+id/button3"
  android:layout_height="wrap_content"
  android:layout_width="fill_parent"
  android:text="Button3"/>

</LinearLayout>

Обратите внимание, что у первых двух кнопок атрибуту android: layout_width присвоено значение wrap_content, а у третьей кнопки — fill_parent, т. е. последняя кнопка заполнит оставшееся свободное пространство в разметке.

В результате получится линейное горизонтальное размещение дочерних элементов.

L0004

Если изменить в корневом элементе значение атрибута android: layout_height:

android:orientation="vertical "

элементы в контейнере расположатся вертикально. Так же обратите внимание на кнопку Button3.

L0005

Разметка LinearLayout также поддерживает атрибут android:layout_weight, который назначает индивидуальный вес для дочернего элемента. Этот атрибут определяет "важность" представления и позволяет этому элементу расширяться, чтобы заполнить любое оставшееся пространство в родительском представлении. Заданный по умолчанию вес является нулевым.

Например, если есть три текстовых поля, и двум из них объявлен вес со значением 1, в то время как другому не дается никакого веса (0), третье текстовое поле без веса не будет расширяться и займет область, определяемую размером текста, отображаемого этим полем. Другие два расширятся одинаково, чтобы заполнить остаток пространства, не занятого третьим полем. Если третьему полю присвоить вес 2 (вместо 0), это поле будет объявлено как "более важное", чем два других, так что третье поле получит 50% общего пространства, в то время как первые два получат по 25% общего пространства.

Еще примерчик на тему веса:
<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="horizontal"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
 <Button
  android:id="@+id/button1"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:text="B1"
  android:layout_weight="0"/>
 <Button
  android:id="@+id/button2"
  android:layout_width="wrap_content"
  android:layout_height="wrap_content"
  android:text="B2"
  android:layout_weight="1"/>
 <Button
  android:id="@+id/button3"
  android:layout_height="wrap_content"
  android:layout_width="wrap_content"
  android:text="B3"
  android:layout_weight="2"/>
</LinearLayout>

Обратите внимание, как различные атрибуты XML определяют поведение представления. Попробуйте поэкспериментировать с различными значениями layout_weight для дочерних элементов, чтобы увидеть, как будет распределяться доступное пространство для элементов.

L0006

Элементы разметки могут быть и вложенными. Приведем примерчик

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:orientation="vertical"
    android:layout_width="fill_parent"
    android:layout_height="fill_parent">
    
    <Button android:text="Button1" 
        android:id="@+id/button1" 
        android:layout_width="fill_parent" 
        android:layout_height="wrap_content"/>
        
    <LinearLayout 
        android:orientation="horizontal"
        android:layout_height="wrap_content" 
        android:layout_width="match_parent">
        <Button 
            android:text="Button2" 
            android:id="@+id/button2" 
            android:layout_width="wrap_content" 
            android:layout_weight="1"
            android:layout_height="wrap_content"/>
        <Button android:text="Button3" 
            android:id="@+id/button3" 
            android:layout_weight="1"
            android:layout_width="wrap_content" 
            android:layout_height="wrap_content"/>
    </LinearLayout>
    
    <LinearLayout 
        android:orientation="horizontal"
        android:layout_height="wrap_content" 
        android:layout_width="match_parent">
        <Button 
            android:text="Button4" 
            android:id="@+id/button4" 
            android:layout_weight="1"
            android:layout_width="wrap_content" 
            android:layout_height="wrap_content"/>
        <Button 
            android:text="Button5" 
            android:id="@+id/button5" 
            android:layout_weight="1"
            android:layout_height="wrap_content" 
            android:layout_width="wrap_content"/>
        <Button 
            android:text="Button6" 
            android:id="@+id/button6" 
            android:layout_weight="1"
            android:layout_height="wrap_content" 
            android:layout_width="wrap_content"/>
    </LinearLayout>
    
</LinearLayout>

И вот как это выглядит в редакторе

L0007

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

L0008

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

FrameLayout

FrameLayout является самым простым типом разметки. Это в основном пустое пространство на экране, которое можно позже заполнить дочерним объектом View или ViewGroup. Все дочерние элементы FrameLayout прикрепляются к верхнему левому углу экрана.

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

Разметка FrameLayout применяется достаточно редко, так как не позволяет создавать сложные окна со множеством элементов. Эту компоновку обычно используют для оверлеев. Например если в приложении выводится изображение занимающее весь экран (это может быть карта Google или картинка с видео камеры), можно сверху на изображении расположить элементы управления, скажем кнопки управления камерой или выводить индикацию времени съемки.

А теперь посмотрим это вживую. Взял пример из книги Голощапова и чуток его модифицировал. Код разметки:

<?xml version="1.0" encoding="utf-8"?>
<FrameLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:id="@+id/FrameLayout01"
android:layout_width="fill_parent"
android:layout_height="fill_parent">

<Button
android:text="Button1"
android:id="@+id/Button1"
android:layout_width="fill_parent"
android:layout_height="fill_parent"/>

<Button
android:id="@+id/Button2"
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="Button2"
android:textColor="#000000" />

<TextView
android:id="@+id/textView1"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:text="TextView"
android:textColor="#000000"
android:textSize="15sp" />

</FrameLayout>

Я добавил еще элемент textView, чтобы было видно более четко что все дочерние элементы в этой разметке прибиваются к левому верхнему углу.


L0003

Layouts (компоновки). Теория

Переходим к изучению Layouts. Или как часто переводят разметка, компоновка или представление элементов пользовательского интерфейса.

Все элементы пользовательского интерфейса в приложениях Андроид создаются с использованием объектов View и ViewGroup.

Класс View является базовым классом для ViewGroup и состоит из коллекции объектов View. Есть множество типов представлений и групп представлений, каждый из которых является потомком класса View.

Иерархия классов View и ViewGropu
L0001

Объекты View— основные модули отображения интерфейса пользователя на платформе Android. Класс View служит ядром для подклассов, называемых виджетами, которые предлагают полностью реализованные объекты пользовательского интерфейса подобно текстовым полям, кнопкам и т. д. Объект View— структура данных, свойства которой сохраняют параметры разметки и содержание для определенной прямоугольной области экрана.

Класс ViewGroup служит ядром для подклассов, называемых разметками (layouts), которые формируют расположение элементов пользовательского интерфейса на форме, используя различные виды архитектуры разметки — фреймовый, линейный, табличный и относительный.

На платформе Android необходимо определить пользовательский интерфейс для каждой Активности, используя иерархии узлов View и viewGroup. Это дерево иерархии может быть и простым, и сложным — в зависимости от требований к графическому интерфейсу приложения.

Пример дерева Layouts (представлений, разметок или компоновки)
L0002

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

При запуске Активности система должна получить ссылку на корневой узел дерева разметки, который будет использоваться для прорисовки графического интерфейса на экране мобильного устройства. Для этого в методе onCreate() необходимо вызвать метод setСontentView(), передав ему в качестве параметра ссылку на ресурс разметки в следующем виде:

R.layout.layout_file_name

Например, если ваша XMLразметка сохранена как main.xml, вы загружаете разметку для Activity примерно так:

@Override
public void onCreate(Bundle savedlnstanceState){
 super.onCreate(savedlnstanceState);
 setContentView(R.layout.main);
}

Прорисовка начинается с корневого узла дерева разметки. Затем последовательно прорисовываются дочерние представления дерева разметки. Это означает, что родители будут прорисовываться раньше, чем их дочерние представления, — т. е. по окончании процесса прорисовки родители будут находиться на заднем плане по отношению к дочерним узлам.

Разметка, как было сказано, — это архитектура расположения элементов интерфейса пользователя для конкретного окна, представляющего Активность. Она определяет структуру расположения элементов в окне и содержит все элементы, которые предоставляются пользователю программы. Разметку можно объявлять двумя способами:
  • объявить элементы пользовательского интерфейса в XML. Android обеспечивает прямой XMLсловарь, который соответствует классам View и ViewGroup;
  • создать разметку для окна в коде программы во время выполнения — инициализировать объекты Layout и дочерние объекты View, ViewGroup и управлять их свойствами программно.

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

ADT-плагин для Eclipse предлагает удобный инструментарий — визуальный редактор разметки Layout Editor, который применяется для создания и предварительного просмотра создаваемых файлов разметки, которые находятся в каталоге res/layout/ проекта.

Самый общий способ определять разметку и создавать иерархию представления— в XML файле разметки. XML предлагает удобную структуру для разметки, похожую на HTML разметку WEB страницы.

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

Например, вы можете создавать XML разметки для различных ориентаций экрана мобильного устройства (portrait, landscape), размеров экрана и языков интерфейса. Дополнительно, объявление разметки в XML файле облегчает возможность по визуализации структуры вашего пользовательского интерфейса, что упрощает отладку приложения.

Каждый элемент в XML является объектом View или ViewGroup (или его потомком). Объекты view— листья в дереве, объекты ViewGroup— ветви. Вы можете также создавать объекты View и viewGroups в Java-коде, используя метод addview (View), чтобы динамически вставлять новые объекты view и ViewGroup в существующую разметку.

Используя различные виды групп представлений, можно структурировать дочерние представления и группы представлений многими способами в зависимости от требований к графическому интерфейсу приложения. Некоторые стандартные группы представлений, предлагаемые Android (называющиеся разметками), включают LinearLayout, RelativeLayout, TableLayout и др. (будут подробно описаны позднее). Каждый из этих типов разметки предлагает уникальный набор параметров, которые используются, чтобы определить позиции дочерних представлений и структуру разметки на экране.
Объявление в XML

Используя XML словарь Android, можно быстро проектировать пользовательский интерфейс разметки и экранные элементы, которые он содержит, тем же самым способом, которым вы создаете web страницы в HTML — с рядом вложенных элементов.

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

Самый простой способ объяснять эту концепцию состоит в том, чтобы показать образец.

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical" >

    <TextView
        android:id="@+id/TextViewOl"
        android:layout_width="fill_parent"
        android:layout_he=""
        ight="wrap_content"
        android:text="@string/hello" >
    </TextView>

</LinearLayout>

Общая структура XML файла разметки проста: это — дерево XML элементов, где каждый узел представляет имя класса View (в нашем примере только один элемент View— TextView). Вы можете использовать имя любого класса, производного от класса View, как элемент в XML разметках, включая ваши собственные классы. Эта структура позволяет быстро создавать пользовательский интерфейс, используя более простую структуру и синтаксис, чем при создании разметки в программном коде.

В вышеупомянутом XML примере есть корневой элемент <LinearLayout> и только один дочерний элемент View. TextView (текстовое поле), который имеет атрибуты. Описание некоторых из этих атрибутов приведем ниже:
  • xmlns:android – декларация пространства имен XML, которая сообщает среде Android, что вы ссылаетесь на общие атрибуты, определенные в пространстве имен Android. В каждом файле разметки у корневого элемента должен быть этот атрибут со значением "http://schemas.android.com/apk/res/android"
  • android:layout_width – этот атрибут определяет, сколько из доступной ширины на экране должен использовать этот объект View (или View Group). В нашем случае он — единственный объект, таким образом, можно растянуть его на весь экран, которому в данном случае соответствует значение mutch_parent
  • android:layout_height – аналогично android:layout_width, за исключением того, что он ссылается на доступную высоту экрана
  • android:text – устанавливает текст, который должен отобразить Textview. В этом примере используется строковый ресурс вместо жестко закодированного строкового значения. Строка hello определена в файле res/values/strings.xml. Это рекомендуемая практика для использования строковых ресурсов в ваших приложениях, потому что она делает локализацию приложения на другие языки более простой, без потребности кодировать напрямую изменения в файле разметки
Каждый объект View и ViewGroup поддерживает свое собственное разнообразие XML атрибутов. Некоторые атрибуты являются определенными только в объекте View (например, Textview поддерживает атрибут textSize), но эти атрибуты могут также наследоваться любыми объектами View, которые расширяют этот класс. Некоторые атрибуты являются общими ко всем объектам View, потому что они унаследованы от корневого класса View (подобно атрибутам id, layout_width, layout_height).

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

Соответствие XML атрибутов и методов в классах представлений

Имя атрибута XML
Соответствующий метод в классе Java

android:gravity

setGravity(int)

android: height

setHeight(int)

android:text

setText(CharSequence)

android:textColor

setTextColor(ColorStateList)

android:textSize

setrextSize (float)

android:width

setWidth(int)

android:textColorHighlight

setHighlightColor(int)


Любой объект View в коде программы можно связать с объектом из файла разметки, однозначно определив элемент пользовательского интерфейса в пределах дерева. Когда приложение откомпилировано, на этот идентификатор ссылаются как на целое число, но идентификатор представления обычно обозначается в XML файле разметки как строка в атрибуте id. Синтаксис для идентификатора элемента в XMLтеге следующий:

Символ @ в начале строки указывает, что синтаксический анализатор XML должен проанализировать и развернуть остальную часть строки идентификатора и определить это выражение как ресурс идентификатора. Символ + означает, что это — новое имя ресурса, которое должно быть создано и добавлено к нашим ресурсам в файл R.java, который среда Android автоматически генерирует для проекта, как показано в листинге.

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

android:id="@+id/TextViewOl"

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

Существуют следующие стандартные типы разметок, которые вы можете использовать в создаваемых приложениях:
  • FrameLayout;
  • LinearLayout;
  • TableLayout;
  • RelativeLayout;
  • GridLayout.
Подобно всем разметкам, все они являются подклассами viewGroup и наследуют свойства, определенные в классе View.

Что самое интересное весь этот материал взят от сюда, ну кроме второго абзаца с верху который я сам перевел с альма-матер. Кто у кого стянул текст не понятно. То ли Голощапов, то ли этот сайт. Но на сайте инфы больше.

Вообще абзац Улыбка

Сохранил это себе в блог дабы не исчезло Улыбка

27 ноября 2014 г.

Отладка приложений Android в Eclipse

Посмотрел главу про отладку приложений в книге Голощапова. Восемь страниц просто ни о чем. Стал гуглить и как всегда выручил проект startandroid.ru

Очень хорошие видео про отладку приложений Android в Eclipse

Часть 1

 

Часть 2

 

А так же хорошая статья по этой же теме от автора этих видео

http://habrahabr.ru/post/222199/

Ну и еще не плохое видео про отладку приложений Java в Eclipse. Хотя автор вещает все достаточно монотонно, что можно уснуть, но инфа полезная и узнаете много полезного, если не уснете.

Отладка Java приложений в Eclipse

И немножко про использование Hierarchy Viewer для оптимизации Android приложения

http://habrahabr.ru/post/173109/

25 ноября 2014 г.

Структура AndroidManifest.xml

Теперь кратко рассмотрим этот важный файл любого приложения Андроид. Кратко, потому как переводить весь объем с альма-матер это очень утомительно. В любом случае более подробно, при необходимости, каждый может почитать там.

Есть основная статья в альма-матер. Так же есть еще одна не плохая статейка на сайте http://devcolibri.com и еще одна тут.

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

Файл AndroidManifest.xml задает конфигурацию приложения:
  • объявляет имя Java-пакета приложения, который служит уникальным идентификатором
  • объявляет минимальный и максимальный уровни API, необходимые для работы приложения
  • описывает компоненты приложения (Activiy, Service, Broadcast Receiver и Content Provider)
  • перечисляет любые библиотеки связанные с приложением (помимо библиотек Андроид, связанных по умолчанию)
  • объявляет разрешения, которые требуются для работы приложения (например, доступ в сеть, разрешение на отправку SMS и т.д.)
На рисунке ниже можно увидеть общую структуру файла манифеста и его элементов. Рисунок взят из книги Голощапова и не содержит некоторых элементов. Перевод описания недостающих элементов я сделал сам. Но их в принципе не так много.
AM0001
Полное описание есть в альма-матер, но я его приведу здесь тоже для пущей наглядности
<?xml version="1.0" encoding="utf-8"?>

<manifest>

    <uses-permission />
    <permission />
    <permission-tree />
    <permission-group />
    <instrumentation />
    <uses-sdk />
    <uses-configuration />  
    <uses-feature />  
    <supports-screens />  
    <compatible-screens />  
    <supports-gl-texture />  

    <application>

        <activity>
            <intent-filter>
                <action />
                <category />
                <data />
            </intent-filter>
            <meta-data />
        </activity>

        <activity-alias>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </activity-alias>

        <service>
            <intent-filter> . . . </intent-filter>
            <meta-data/>
        </service>

        <receiver>
            <intent-filter> . . . </intent-filter>
            <meta-data />
        </receiver>

        <provider>
            <grant-uri-permission />
            <meta-data />
            <path-permission />
        </provider>

        <uses-library />

    </application>

</manifest>

Порядок расположения элементов, находящихся на одном уровне, произвольный. Все значения устанавливаются через атрибуты элементов. Элемент <application> является основным элементом манифеста и содержит множество дочерних элементов, определяющих структуру и работу приложения. Элементы <manifest>, <applicaton> и <uses-sdk> являются обязательными. Другие элементы не обязательны и используются в манифесте при необходимости.

<manifest>

Элемент <manifest> является корневым элементом файла AndroidManifest.xml. По умолчанию мастер создания проекта Андроид в Eclipse создает этот элемент с четырьмя атрибутами:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
      package="com.samples.intro.firstapp"
      android:versionCode="1"
      android:versionName="1.0">


Эти атрибуты обязательны для любого приложения Андроид и имеют следующее назначение:

xmins:android — определяет пространство имен Android. Это значение всегда неизменно для всех приложений.

package — определяет уникальное имя пакета приложения, которое вы задали при создании проекта.

Для чего нужно указывать package? Если вы захотите загрузить ваше приложение на Google Play, то он проверяет уникальность при приеме приложения, поэтому рекомендуется использовать свое имя для избежания конфликтов с другими разработчиками.

android:versionCode — по сути это версия вашего приложения. Выпуская новую версию вы указываете её в этом поле, оно должно быть целым числом.

Выше мы говори про уникальность пакета, так вот если вы ранее загрузили на Google Play ваше приложение, то когда вы решите загрузить обновленную версию приложения, то вам нужно придерживаться нескольких правил. Имя пакета должно совпадать с тем, что уже загружено Google Play и указать версию android:versionCode на порядок выше. Но это при условии что вы выпускаете новую версию приложения, в случае если вы хотите добавить немного исправленную версию, то это читайте ниже.

Изменив данный параметр и загрузив приложение на Google Play все пользователям вашего приложения будет предложено обновится до новой версии приложения.

android:versionName - указывает номер пользовательской версии. Если вы нашли несколько недоработок в вашем приложении и исправили их, то в этом случае можно указать для этого поля новую версию, что будет говорить Google Play, что это не новая версия приложения, а улучшенная. Для именования версии можно использовать строку или строковый ресурс.

Изменив данный параметр и загрузив приложение на Google Play все пользователям вашего приложения будет предложено обновится до модифицированной версии приложения.

<uses-permission>

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

Разрешения предоставляются во время установки приложения, а не во время его работы. <uses-permission> имеет единственный атрибут с именем разрешения android:name. Это может быть разрешение, определенное в элементе <permission> данного приложения, разрешение определенное в другом приложении, или одно из стандартных системных разрешений, например:

android:name=’android.permission.CAMERA’ – доступ к камере устройства
android:name=’android.permission.READ_CONTACTS’ – доступ к базе данных контактов

<permission>

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

Приложение может также защитить свои собственные  компоненты (Activity, Service, Broadcast Receiver и Content Provider) разрешениями. Оно может использовать любое из системных разрешений, определенных Андроид (перечисленных в android.Manifest.permission) или объявленных другими приложениями, а так же может определить свои собственные разрешения. Новое разрешение должно быть объявлено в атрибуте android:name элемента <permission> следующим образом:

permisson android:name=”com.samples.custom_permission”

Кроме того используются дополнительные атрибуты:

android:label — имя разрешения, отображаемое пользователю
android:description — описание разрешения
android:icon — значок разрешения
android:permissionGroup — определяет принадлежность к группе разрешений
android:protectionLevel — уровень защиты
<permission-tree>

Элемент <permission-tree> объявляет базовое имя для дерева разрешений. Этот элемент объявляет не само разрешение, а только пространство имен, в которое могут быть помещены дальнейшие разрешения.

<permission-group>

Элемент <permission-group> определяет имя для набора логически связанных разрешений. Это могут быть как объявленные в этом же манифесте с элементом <permission> разрешения, так и объявленные в другом месте. Этот элемент не объявляет разрешение непосредственно, только категорию, в которую могут быть помещены разрешения. Разрешение можно поместить в группу, назначив имя группы в атрибуте permissionGroup элемента <permission>.

<instrumentation>

Элемент <instrumentation> объявляет объект Instrumentation, который дает возможность контролировать взаимодействие приложения с системой. Обычно используется при отладке и тестировании приложения и удаляется из release-версии приложения.

<uses-sdk>

Элемент <uses-sdk> позволяет объявлять совместимость приложения с указанной версией (или более новыми версиями API) платформы Android. Уровень API, объявленный приложением, сравнивается с уровнем API системы мобильного устройства, на который инсталлируется данное приложение.

Основной используемый в элементе атрибут – android:minSdkVersion, определяет минимальный уровень API, требуемый для работы приложения. Система Android будет препятствовать тому, чтобы пользователь установил приложение, если уровень API системы будет ниже, чем значение, определенное в этом атрибуте. Желательно всегда объявлять этот атрибут, например:

<uses-sdk android:minSdkVersion=”10″/>

Атрибут android:targetSdkVersion представлен начиная с API Level 4. Это целое число, обозначающее API Level, для которого приложение предназначено (target, что означает цель). Если этот атрибут не установлен, то его значение по умолчанию равно minSdkVersion.

Этот атрибут информирует систему, что Вы тестировали приложение с этим API Level, и система не должна позволять любое поведение совместимости (compatibility behaviors, т. е. эмуляцию вызовов API, обеспечивающих специальную дополнительную программную обработку некоторых вызовов API), чтобы поддержать прямую совместимость приложения с целевой версией системы. Приложение все еще может работать на более старых версиях (до версий, не меньших minSdkVersion).

Поскольку Android развивается с каждой новой версией, то некоторые поведения и даже внешний вид приложения может измениться. Однако, если API level платформы выше, чем версия, указанная в targetSdkVersion приложения, система может включить обработки совместимости (compatibility behaviors), чтобы обеспечить работоспособность Вашего приложения так, как Вы этого ожидали. Вы можете запретить такие обработки совместимости, если укажете targetSdkVersion равным API level платформы Android, на которой приложение работает. Например, установка этого значения в "11" или более высокое значение позволит системе установить новую тему оформления по умолчанию (Holo) для Вашего приложения при работе на Android 3.0 или более новой, и также запретит режим совместимости экрана, когда программа будет работать на больших экранах (потому что поддержка API level 11 неявно подразумевает поддержку больших экранов).

Имеется много разновидностей обеспечения совместимости (compatibility behaviors), которые система может разрешить, базируясь на значении этого атрибута. Некоторые из этих обработок (поведений, behaviors) описаны в соответствующей документации версии платформы, см. Build.VERSION_CODES.

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

Атрибут android:maxSdkVersion представлен начиная с API Level 4. Это целое число, обозначающее максимальный API Level, на котором приложение может работать.

На версиях Android 1.5, 1.6, 2.0 и 2.0.1 система проверяет значение этого атрибута, когда инсталлируется приложение, и когда приложение проверяется на совместимость после обновления системы. В любом случае, если атрибут приложения maxSdkVersion меньше API Level системы, то установка приложения будет запрещена. При проверке приложения на совместимость после обновления системы такой случай соответствует полному удалению приложения с устройства. Для иллюстрации того, как этот атрибут может повлиять на приложение после обновления системы, рассмотрим пример.

Приложение декларировало maxSdkVersion="5" в своем манифесте, и было опубликовано на Google Play. Пользователь устройства Android 1.6 (API Level 4) загрузил и установил это приложение. После нескольких недель пользователь принял сообщение от системы over-the-air с предложением обновить систему до уровня Android 2.0 (API Level 5). После установки этого обновления система проверила атрибут приложения maxSdkVersion, и разрешила дальнейшее использование этого приложения. Приложение после этого работало нормально. Однако через некоторое время устройство приняло другое обновление системы Android 2.0.1 (API Level 6). После обновления система не разрешает работу приложения, так как API Level системы (6) теперь выше, чем максимальный уровень, который может поддержать приложение (5). Система делает приложение невидимым для пользователя, и удаляет его из устройства.

Предупреждение: использование этого атрибута не рекомендуется. Во-первых, нет никакой потребности установить этот атрибут как средство блокирования развертывания Вашего приложения на новые версии платформы Android по мере их появления. Для Android декларируется полная обратная совместимость старых приложений для новых версий Android. Ваше приложение должно работать должным образом на всех новых версиях, если оно использует только стандартное API и следует лучшим правилам и практикам разработки. Во-вторых нужно помнить, что применение этого атрибута приведет к автоматическому удалению Вашего приложения с устройств пользователя, которые обновят свою систему на более высокий API Level, чем указано в атрибуте. Большинство устройств, на которых вероятно будет установлено Ваше приложение, получают периодические обновления системы на лету, по воздуху (over the air), так что Вы должны учитывать этот эффект перед тем, как установить этот атрибут для своего приложения.

Будущие версии Android (вне Android 2.0.1) больше не будут проверять maxSdkVersion и принудительно применять его значение при установке или проверке совместимости приложения. Однако Google Play продолжит использовать этот атрибут как фильтр при предоставлении приложений, доступных для закачки пользователям.

<uses-configuration>

Элемент <uses-configuration> указывает требуемую для приложения аппаратную и программную конфигурацию мобильного устройства. Например, приложение приложению для работы нужно наличие физической клавиатуры или трекбола. Спецификация используется, чтобы избежать установки приложения на устройствах, которые не поддерживают требуемую конфигурацию.

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

Вы можете задать любую комбинацию, содержаoe. следующие устройства

reqFiveWayNav - используйте значение true, если приложению требуется устройство ввода, поддерживающее навигацию вверх, вниз, влево, вправо, а также нажатие выделенного элемента. К таким устройствам относятся трекболы и D-pad. В принципе устарело
reqHardKeyboard - используйте значение true, если приложению нужна аппаратная клавиатура.
reqKeyboardType - позволяет задать тип клавиатуры: nokeys, qwerty, twelvekey, undefined
reqNavigation - укажите одно из значений: nonav, dpad, trackball, wheel или undefined, если требуется устройство для навигации
reqTouchScreen - если требуется сенсорный экран, то используйте нужное значение из возможных вариантов: notouch, stylus, finger, undefined. Сейчас практически все устройства содержат сенсорный экран, поэтому тоже устарело

Приложение не будет устанавливаться на устройстве, которое не соответствует заданной вами конфигурации. В идеале, вы должны разработать такое приложение, которое будет работать с любым сочетанием устройств ввода. В этом случае <uses-configuration> не нужен.

<uses-feature>

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

android.hardware.camera.front — требуется аппаратная камера

android.hardware.camera.autofocus — требуется камера с автоматической фокусировкой

Все параметры можно посмотреть в альма-матер тут.

<supports-screens>

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

Для пущей наглядности приведу синтакс
    <supports-screens android:resizeable=["true"| "false"]
                      android:smallScreens=["true" | "false"]
                      android:normalScreens=["true" | "false"]
                      android:largeScreens=["true" | "false"]
                      android:xlargeScreens=["true" | "false"]
                      android:anyDensity=["true" | "false"]
                      android:requiresSmallestWidthDp="integer"
                      android:compatibleWidthLimitDp="integer"
                      android:largestWidthLimitDp="integer"/>

<compatible-screens>

Определяет размеры и плотности экранов совместимые с вашим приложением. Только один элемент <compatible-screens> может присутствовать в файле манифеста, но он может содержать множество элементов <screen>. Например:
<manifest ... >
    ...
    <compatible-screens>
        <!-- all small size screens -->
        <screen android:screenSize="small" android:screenDensity="ldpi" />
        <screen android:screenSize="small" android:screenDensity="mdpi" />
        <screen android:screenSize="small" android:screenDensity="hdpi" />
        <screen android:screenSize="small" android:screenDensity="xhdpi" />
        <!-- all normal size screens -->
        <screen android:screenSize="normal" android:screenDensity="ldpi" />
        <screen android:screenSize="normal" android:screenDensity="mdpi" />
        <screen android:screenSize="normal" android:screenDensity="hdpi" />
        <screen android:screenSize="normal" android:screenDensity="xhdpi" />
    </compatible-screens>
    <application ... >
        ...
    <application>
</manifest>

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

Как правило, вы не должны использовать этот элемент.

<supports-gl-texture>

Этот элемент объявляет формат сжатия одной GL текстуры поддерживаемой вашим приложением. Если ваше приложение поддерживает несколько форматов сжатия текстур, то вам необходимо использовать несколько этих элементов. Например:
<supports-gl-texture android:name="GL_OES_compressed_ETC1_RGB8_texture" />
<supports-gl-texture android:name="GL_OES_compressed_paletted_texture" />

Все значения можно посмотреть по этой ссылке. На русском языке по этому параметру можно немного почитать тут.

<application>

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

AM0002

Элемент <application> один из основных элементов манифеста, содержащий описание компонентов приложения, доступных в пакете: стили, значок и др. Содержит дочерние элементы, которые объявляют каждый из компонентов, входящих в состав приложения. В манифесте может быть только один элемент <application>.

<activity>

Дочерний элемент <activity> объявляет компонент Activity. Если приложение содержит несколько Активностей, они должны быть объявлены в манифесте, создавая для каждой из них свой элемент <activity>. Если Активность не объявлена в манифесте, она не будет видна системе и не будет запущена при выполнении приложения или будет выводиться сообщение об ошибке. Пример объявления Активности:
<activity android:name="com.samples.HelloWorld.MainActivity"
   android:label="@string/app_name">

Эти атрибуты элемента <activity> являются обязательными и определяют следующее:

android:name — имя класса. Имя должно включать полное обозначение пакета, но если имя пакета уже определено в корневом элементе <manifest>, имя класса, реализующего Активность, можно записывать в сокращенном виде, опуская имя пакета.

android:label — текстовая метка, отображаемая пользователю в заголовке Активности.

Элемент <activity> содержит множество других атрибутов, определяющих разрешения, ориентацию экрана и т. д. Изменение конфигурации во время выполнения программы

При изменении языка, региона или аппаратной конфигурации Android прерывает работу всех приложений и затем запускает их повторно, перезагружая значения из ресурсов. Подобное поведение не всегда уместно и желательно. Например, некоторые изменения конфигурации (ориентация экрана в пространстве, доступность клавиатуры) могут произойти только лишь из-за того, что пользователь повернул устройство или выдвинул клавиатуру. Вы можете настраивать, каким образом ваше приложение будет реагировать на подобные изменения, обнаруживая их и выполняя собственные действия. Чтобы заставить Активность отслеживать изменения конфигурации при выполнении программы, добавьте в ее узел в манифесте атрибут android:configChanges, указав, какие именно события хотите обрабатывать.

Перечислим некоторые значения, с помощью которых можно описать изменения конфигурации:

оrientation — положение экрана изменено с портретного на альбомное (или наоборот);
keyboardHidden — клавиатура выдвинута или спрятана;
fontScale — пользователь изменил предпочтительный размер шрифта;
locale — пользователь выбрал новые языковые настройки;
keyboard — изменился тип клавиатуры; например, телефон может иметь 12-клавишную панель, при повороте которой появляется полноценная клавиатура;
touchscreen или navigation — изменился тип клавиатуры или способ навигации. Как правило, такие события не встречаются.

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

Наличие атрибута android:configChanges отменяет перезапуск приложения при заданных изменениях конфигурации. Вместо этого внутри Активности срабатывает метод onConfigurationChanged(). Переопределите его, чтобы появилась возможность обрабатывать изменения в конфигурации. Используйте переданный объект Configuration, чтобы получить новые значения. Не забудьте вызвать одноименный метод из родительского класса и перезагрузить измененные значения со всех ресурсов, которые используются внутри Активности.

@Override
public void onConfigurationChanged(Configuration _newConfig) {
  super.onConfigurationChanged(_newConfig);
  [ ... Обновите пользовательский интерфейс, используя данные из ресурсов ... ]
  if (_newConfig.orientation == Configuration.ORIENTATION_LANDSCAPE) {
    [ ... Реакция на измененную ориентацию экрана ... ]
  }
  if (_newConfig.keyboardHidden == Configuration.KEYBOARDHIDDEN_NO) {
    [ ... Реакция на выдвигание/задвигание клавиатуры ... ]
  }
}

Любые изменения конфигурации, которые не были явно помечены для обработки внутри вашего приложения, приведут к перезапуску Активности, минуя вызов метода onConfigurationChanged.

<intent-filter>

Элемент <activity> поддерживает вложенные узлы <intent-filter>. Элемент <intent-filter> определяет типы намерений (Intent), на которые могут ответить Activity, Service или Broadcast Receidver. Фильтр намерений (intent-filter) предоставляет для компонентов-клиентов возможность получения намерений (Intent) объявляемого типа, отфильтровывая те, которые не значимы для компонента, и содержит дочерние элементы <action>, <category>, <data>.


<action>

Элемент <action> добавляет действие к фильтру намерений. Элемент <intent-filter> должен содержать один или более элементов <action>. Если в элементе <intent-fiiter> не будет этих элементов, то объекты намерений не пройдут через фильтр. Пример объявления действия:

<action android:name="android.intent.action.MAIN">

это означает, что эта Активность приложения является главной и когда система пришлет Intent для запуска приложения, эта Активность откроется по умолчанию.


<category>

Элемент <category> определяет категорию компонента, которую должно обработать намерение. Это строковые константы, определенные в классе intent, например:

<category android:name="android.intent.category.LAUNCHER">

этот атрибут определяет, что это приложение будет добавлено в директорию приложений на Android-устройстве. И будет отображаться в окне запуска приложений Application Launcher мобильного устройства.


<data>

Элемент <data> добавляет спецификацию данных к фильтру намерений. Спецификация может быть только типом данных (атрибут mimeType), URI или типом данных вместе с URI. Значение URI определяется отдельными атрибутами для каждой из его частей, т.е. URI делится на части: android:scheme, android:host, android:port, android:path или android:pathPrefix, android:pathPattern.


<meta-data>

Элемент <meta-data> определяет пару "имя-значение" для элемента дополнительных произвольных данных, которыми можно снабдить родительский компонент. Составляющий элемент может содержать любое число элементов <meta-data>.


<activity-alias>

Элемент <activity-alias> — это псевдоним для Activity, определенной в атрибуте targetActivity. Целевая Активность должна быть в том же самом приложении, что и псевдоним, и должна быть объявлена перед псевдонимом деятельности в манифесте. Псевдоним представляет целевую деятельность как независимый объект. У псевдонима может быть свой собственный набор фильтров намерений, определяющий, какие намерения могут активизировать целевую Активность и как система будет обрабатывать эту Активность. Например, фильтры намерений на псевдониме Активности могут определить флаги android:name="android.intent.action.MAIN" и android:name="android.intent.category.LAUNCHER", заставляя целевую Активность загружаться при запуске приложения даже в том случае, когда в фильтрах намерений на целевой деятельности эти флаги не установлены.

Элементы <service>, <receiver> и <provider> объявляют соответственно компоненты Service, Broadcast Receiver и Content Provider. Не забывайте, что компоненты которые не были объявлены не будут обнаружены системой и ни когда не будут запущены. Эти элементы имеют много атрибутов, определяющих имя, доступность, разрешения, процесс и т.д.


<service>

Элемент <service> объявляет службу как один из компонентов приложения. Все службы должны быть представлены элементом <service> в файле манифеста. Службы, которые не были объявлены, не будут обнаружены системой и никогда не будут запущены. Этот элемент имеет много атрибутов, определяющих имя, доступность, разрешения, процесс и т. д. Поддерживает вложенные узлы <intent-fiiter>


<receiver>

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


<provider>

Элемент <provider> объявляет контент-провайдера (источник данных) для управления доступом к базам данных. Все контент-провайдеры, которые являются частью приложения, должны быть представлены в элементах <provider> в файле манифеста. Если они не объявлены, они не будут работать, т. к. система их не сможет увидеть. Элемент <provider> содержит свой набор дочерних элементов для установления разрешений доступа к данным:
  • <grant-uri-permission>;
  • <path-permission>;
  • <meta-data>
Этот элемент имеет много атрибутов, определяющих имя, доступность, разрешения, процесс и т. д.


<grant-uri-permission>

Элемент <grant-uri-permission> является дочерним элементом для <provider>. Он определяет, для кого можно предоставить разрешения на подмножества данных контент-провайдера. Предоставление разрешения является способом допустить к подмножеству данных, предоставляемым контент-провайдером, клиента, у которого нет разрешения для доступа к полным данным. Если атрибут granturiPermissions контент-провайдера имеет значение true, то разрешение предоставляется для любых данных, поставляемых контент-провайдером. Однако, если атрибут поставлен в false, разрешение можно предоставить только подмножествам данных, которые определены этим элементом. Контент-провайдер может содержать любое число элементов <grant-uri-permission>.


<path-permission>

Элемент <path-permission> — дочерний элемент для <provider>. Определяет путь и требуемые разрешения для определенного подмножества данных в пределах поставщика оперативной информации. Этот элемент может быть определен многократно, чтобы поставлять множественные пути.


<uses-library>

Элемент <uses-library> определяет общедоступную библиотеку, с которой должно быть скомпоновано приложение. Этот элемент указывает системе на необходимость включения кода библиотеки в загрузчик классов для пакета приложения. Каждый проект связан по умолчанию с библиотеками Android, в которые включены основные пакеты для сборки приложений (с классами общего назначения типа Activity, Service, Intent, View, Button, Application, ContentProvider и т. д.). Однако некоторые пакеты (например, maps и awt) находятся в отдельных библиотеках, которые автоматически не компонуются с приложением. Если же приложение использует пакеты из этих библиотек или других, от сторонних разработчиков, необходимо сделать явное связывание с этими библиотеками и манифест обязательно должен содержать отдельный элемент <uses-library>.

Тут все было описано очень кратко. Более подробно читаем в альма-матер.