Основы применения

Приложения для Android можно писать с использованием Kotlin, языка программирования Java и языков C++. Инструменты Android SDK компилируют ваш код вместе с любыми файлами данных и ресурсов в APK или пакет приложений Android.

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

Пакет Android App Bundle, который представляет собой архивный файл с суффиксом .aab , содержит содержимое проекта приложения Android, включая некоторые дополнительные метаданные, которые не требуются во время выполнения. AAB – это формат публикации, который нельзя установить на устройствах Android. Это откладывает создание APK и подписание на более поздний этап.

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

Каждое приложение Android находится в собственной изолированной программной среде, защищенной следующими функциями безопасности Android:

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

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

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

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

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

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

Компоненты приложения

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

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

• Деятельность
• Услуги
• Вещательные приемники
• Поставщики контента

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

Деятельность

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

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

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

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

Вы реализуете действие как подкласс класса Activity . Дополнительные сведения о классе Activity см. в разделе Знакомство с действиями .

Услуги

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

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

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

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

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

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

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

Служба реализована как подкласс Service . Дополнительную информацию о классе Service см. в обзоре услуг .

Примечание. Если ваше приложение предназначено для Android 5.0 (уровень API 21) или более поздней версии, используйте класс JobScheduler для планирования действий. Преимущество JobScheduler заключается в экономии заряда батареи за счет оптимального планирования заданий для снижения энергопотребления и работы с Doze API. Дополнительные сведения об использовании этого класса см. в справочной документации JobScheduler .

Вещательные приемники

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

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

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

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

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

Приёмник широковещательной рассылки реализован как подкласс BroadcastReceiver , и каждая широковещательная рассылка доставляется как объект Intent . Дополнительные сведения см. в классе BroadcastReceiver .

Поставщики контента

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

Например, система Android предоставляет поставщика контента, который управляет контактной информацией пользователя. Любое приложение с соответствующими разрешениями может запросить поставщика контента, например, с помощью ContactsContract.Data , чтобы прочитать и записать информацию о конкретном человеке.

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

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

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

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

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

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

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

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

Активировать компоненты

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

Намерение создается с помощью объекта Intent , который определяет сообщение для активации либо определенного компонента ( явное намерение), либо компонента определенного типа ( неявное намерение).

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

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

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

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

Существуют отдельные методы активации каждого типа компонента:

• Вы можете запустить действие или дать ему что-то новое, передав Intent в startActivity() или, если вы хотите, чтобы действие вернуло результат, startActivityForResult() .
• В Android 5.0 (уровень API 21) и более поздних версиях вы можете использовать класс JobScheduler для планирования действий. В более ранних версиях Android вы можете запустить службу или дать новые инструкции текущей службе, передав Intent в startService() . Вы можете привязаться к службе, передав Intent в bindService() .
• Вы можете инициировать широковещательную рассылку, передав Intent таким методам, как sendBroadcast() или sendOrderedBroadcast() .
• Вы можете выполнить запрос к поставщику контента, вызвав query() для ContentResolver .

Дополнительные сведения об использовании намерений см. в документе «Намерения и фильтры намерений» . Следующие документы предоставляют дополнительную информацию об активации конкретных компонентов: «Введение в действия» , «Обзор служб» , BroadcastReceiver и «Поставщики контента» .

Файл манифеста

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

Помимо объявления компонентов приложения манифест выполняет ряд функций, например следующее:

• Определяет любые разрешения пользователя, необходимые приложению, например доступ к Интернету или доступ для чтения контактов пользователя.
• Объявляет минимальный уровень API , необходимый приложению, в зависимости от того, какие API использует приложение.
• Объявляет аппаратные и программные функции, используемые или необходимые приложению, такие как камера, службы Bluetooth или мультисенсорный экран.
• Объявляет библиотеки API, с которыми необходимо связать приложение (кроме API платформы Android), например библиотеку Google Maps .

Объявить компоненты

Основная задача манифеста — информировать систему о компонентах приложения. Например, файл манифеста может объявить действие следующим образом:

<?xml version="1.0" encoding="utf-8"?>
<manifest ... >
    <application android:icon="@drawable/app_icon.png" ... >
        <activity android:name="com.example.project.ExampleActivity"
                  android:label="@string/example_label" ... >
        </activity>
        ...
    </application>
</manifest>

В элементе <application> атрибут android:icon указывает на ресурсы для значка, идентифицирующего приложение.

В элементе <activity> атрибут android:name указывает полное имя класса подкласса Activity , а атрибут android:label указывает строку, которая будет использоваться в качестве видимой пользователем метки для действия.

Вы должны объявить все компоненты приложения, используя следующие элементы:

• Элементы <activity> для действий
• Элементы <service> для сервисов
• Элементы <receiver> для приемников вещания
• Элементы <provider> для поставщиков контента

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

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

Объявить возможности компонента

Как обсуждалось в разделе «Активация компонентов» , вы можете использовать Intent для запуска действий, служб и приемников вещания. Вы делаете это, явно называя целевой компонент, используя имя класса компонента, в намерении. Вы также можете использовать неявное намерение, которое описывает тип действия, которое необходимо выполнить, и, при необходимости, данные, над которыми вы хотите выполнить это действие. Неявное намерение позволяет системе найти на устройстве компонент, который может выполнить действие, и запустить его. Если существует несколько компонентов, которые могут выполнять действие, описанное намерением, пользователь выбирает, какой из них использовать.

Внимание: если вы используете намерение для запуска Service , убедитесь, что ваше приложение безопасно, используя явное намерение. Использование неявного намерения запустить службу представляет собой угрозу безопасности, поскольку вы не можете быть уверены, какая служба реагирует на это намерение, а пользователь не может видеть, какая служба запускается. Начиная с Android 5.0 (уровень API 21), система выдает исключение, если вы вызываете bindService() с неявным намерением. Не объявляйте фильтры намерений для своих сервисов.

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

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

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

<manifest ... >
    ...
    <application ... >
        <activity android:name="com.example.project.ComposeEmailActivity">
            <intent-filter>
                <action android:name="android.intent.action.SEND" />
                <data android:type="*/*" />
                <category android:name="android.intent.category.DEFAULT" />
            </intent-filter>
        </activity>
    </application>
</manifest>

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

Дополнительные сведения о создании фильтров намерений см. в документе «Намерения и фильтры намерений» .

Объявите требования к приложению

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

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

Например, предположим, что вашему приложению требуется камера и используются API, представленные в Android 8.0 (уровень API 26). Вы должны заявить об этих требованиях. Значения minSdkVersion и targetSdkVersion устанавливаются в файле build.gradle вашего модуля приложения:

android {
  ...
  defaultConfig {
    ...
    minSdkVersion 26
    targetSdkVersion 29
  }
}

Примечание. Не устанавливайте minSdkVersion и targetSdkVersion непосредственно в файле манифеста, поскольку они перезаписываются Gradle во время процесса сборки. Дополнительную информацию см. в разделе «Указание требований к уровню API» .

Вы объявляете функцию камеры в файле манифеста вашего приложения:

<manifest ... >
    <uses-feature android:name="android.hardware.camera.any"
                  android:required="true" />
    ...
</manifest>

Благодаря объявлениям, показанным в этих примерах, устройства без камеры или с версией Android ниже 8.0 не смогут установить ваше приложение из Google Play. Однако вы также можете заявить, что ваше приложение использует камеру, но не требует ее. Для этого вы устанавливаете для required атрибута значение false , во время выполнения проверяете, есть ли в устройстве камера, и при необходимости отключаете любые функции камеры.

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

Ресурсы приложения

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

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

Для каждого ресурса, который вы включаете в свой проект Android, инструменты сборки SDK определяют уникальный целочисленный идентификатор, который вы можете использовать для ссылки на ресурс из кода вашего приложения или из других ресурсов, определенных в XML. Например, если ваше приложение содержит файл изображения с именем logo.png (сохраненный в каталоге res/drawable/ ), инструменты SDK генерируют идентификатор ресурса с именем R.drawable.logo . Этот идентификатор сопоставляется с целым числом, специфичным для приложения, которое вы можете использовать для ссылки на изображение и вставки его в свой пользовательский интерфейс.

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

Например, определив строки пользовательского интерфейса в XML, вы можете перевести их на другие языки и сохранить эти строки в отдельных файлах. Затем Android применяет соответствующие языковые строки к вашему пользовательскому интерфейсу на основе квалификатора языка, который вы добавляете к имени каталога ресурсов, например res/values-fr/ для строковых значений на французском языке, и языковых настроек пользователя.

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

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

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

Дополнительные ресурсы

Чтобы изучить разработку Android с помощью видеороликов и учебных пособий по коду, см. курс «Разработка приложений для Android с помощью Kotlin Udacity».