Android 17 представляет множество новых функций и API для разработчиков. В следующих разделах приведено краткое описание этих функций, которое поможет вам начать работу с соответствующими API.
Подробный список новых, измененных и удаленных API см. в отчете об изменениях API . Подробную информацию о новых API см. в справочнике Android API — новые API выделены для большей наглядности.
Также следует проанализировать области, где изменения платформы могут повлиять на ваши приложения. Для получения дополнительной информации см. следующие страницы:
- Изменения в поведении, влияющие на приложения при использовании Android 17.
- Изменения в поведении, затрагивающие все приложения независимо от
targetSdkVersion.
Основная функциональность
В Android 17 добавлены следующие новые функции, относящиеся к основным возможностям Android.
Новые триггеры ProfilingManager
Android 17 adds several new system triggers to ProfilingManager to
help you collect in-depth data to debug performance issues.
The new triggers are:
TRIGGER_TYPE_COLD_START: Trigger occurs during app cold start. It provides both a call stack sample and a system trace in the response.TRIGGER_TYPE_OOM: Trigger occurs when an app throws anOutOfMemoryErrorand provides a Java Heap Dump in response.TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE: Trigger occurs when an app is killed due to abnormal and excessive CPU usage and provides a call stack sample in response.
To understand how to set up the system trigger, see the documentation on trigger-based profiling and how to retrieve and analyze profiling data documentation.
API JobDebugInfo
Android 17 introduces new JobDebugInfo APIs to help developers debug
their JobScheduler jobs--why they aren't running, how long they ran for, and
other aggregated information.
The first method of the expanded JobDebugInfo APIs is
getPendingJobReasonStats(), which returns a map of reasons why the job was in
a pending execution state and their respective cumulative pending
durations. This method joins the getPendingJobReasonsHistory() and
getPendingJobReasons() methods to give you insight into why a scheduled
job is not running as expected, but simplifies information retrieval by making
both duration and job reason available in a single method.
For example, for a specified jobId, the method might return
PENDING_JOB_REASON_CONSTRAINT_CHARGING and a duration of 60000 ms, indicating
the job was pending for 60000ms due to the charging constraint not being
satisfied.
Уменьшите количество блокировок пробуждения благодаря поддержке слушателей для будильников, разрешающих работу в режиме ожидания.
В Android 17 представлен новый вариант AlarmManager.setExactAndAllowWhileIdle , который принимает OnAlarmListener вместо PendingIntent . Этот новый механизм на основе обратных вызовов идеально подходит для приложений, которые в настоящее время полагаются на непрерывную блокировку пробуждения для выполнения периодических задач, например, для мессенджеров, поддерживающих сокетные соединения.
Конфиденциальность
В Android 17 добавлены следующие новые функции для повышения конфиденциальности пользователей.
Поддержка платформы Encrypted Client Hello (ECH).
В Android 17 появилась поддержка технологии Encrypted Client Hello (ECH), которая значительно повышает конфиденциальность сетевых коммуникаций. ECH — это расширение TLS 1.3, которое шифрует Server Name Indication (SNI) во время первоначального установления TLS-соединения. Это шифрование помогает защитить конфиденциальность пользователей, затрудняя сетевым посредникам идентификацию конкретного домена, к которому подключается приложение.
Теперь платформа включает необходимые API для сетевых библиотек, позволяющие реализовать ECH. Это включает новые возможности в DnsResolver для запроса записей HTTPS DNS, содержащих конфигурации ECH, а также новые методы в SSLEngines и SSLSockets Conscrypt для включения ECH путем передачи этих конфигураций при подключении к домену. Разработчики могут настраивать параметры ECH, например, включать его по мере необходимости или предписывать его использование, с помощью нового элемента <domainEncryption> в файле конфигурации сетевой безопасности, применимого глобально или для каждого домена отдельно.
Ожидается, что популярные сетевые библиотеки, такие как HttpEngine, WebView и OkHttp, интегрируют эти API платформы в будущих обновлениях, что упростит внедрение ECH в приложения и повысит конфиденциальность пользователей.
Для получения более подробной информации см. документацию по протоколу Encrypted Client Hello .
средство выбора контактов для Android
Интерфейс выбора контактов Android Contact Picker — это стандартизированный, удобный для просмотра интерфейс, позволяющий пользователям делиться контактами с вашим приложением. Доступный на устройствах под управлением Android 17 (уровень API 37) или выше, этот интерфейс предлагает альтернативу широкому разрешению READ_CONTACTS , обеспечивающую конфиденциальность. Вместо запроса доступа ко всей адресной книге пользователя, ваше приложение указывает необходимые поля данных, такие как номера телефонов или адреса электронной почты, а пользователь выбирает конкретные контакты для обмена. Это предоставляет вашему приложению доступ на чтение только к выбранным данным, обеспечивая детальный контроль и предоставляя единообразный пользовательский опыт со встроенным поиском, переключением профилей и возможностью множественного выбора без необходимости разработки или поддержки пользовательского интерфейса.
Для получения более подробной информации см. документацию по средству выбора контактов .
Безопасность
В Android 17 добавлены следующие новые функции для повышения безопасности устройств и приложений.
Расширенный режим защиты Android (AAPM)
Расширенный режим защиты Android (AAPM) предлагает пользователям Android мощный новый набор функций безопасности, что является значительным шагом в защите пользователей — особенно тех, кто подвержен повышенному риску — от сложных атак. Разработанный как функция с возможностью выбора, AAPM активируется с помощью одной настройки конфигурации, которую пользователи могут включить в любое время, чтобы применить определенный набор мер защиты.
Эти основные настройки включают блокировку установки приложений из неизвестных источников (боковая загрузка), ограничение передачи данных по USB и обязательное сканирование с помощью Google Play Protect, что значительно уменьшает площадь поверхности атаки устройства. Разработчики могут интегрировать эту функцию с помощью API AdvancedProtectionManager для определения статуса режима, что позволяет приложениям автоматически переходить в режим повышенной безопасности или ограничивать работу с функциями высокого риска, если пользователь дал на это согласие.
Подписание APK-файлов PQC
Теперь Android поддерживает гибридную схему подписи APK, которая обеспечивает защиту вашей подписи от потенциальной угрозы атак с использованием квантовых вычислений в будущем. Эта функция представляет новую схему подписи APK, которая позволяет сочетать классический ключ подписи (например, RSA или EC) с новым алгоритмом постквантовой криптографии (PQC) (ML-DSA).
Этот гибридный подход гарантирует защиту вашего приложения от будущих квантовых атак, сохраняя при этом полную обратную совместимость со старыми версиями Android и устройствами, использующими классическую проверку подписи.
Влияние на разработчиков
- Приложения, использующие Play App Signing: Если вы используете Play App Signing, вы можете подождать, пока Google Play предоставит вам возможность обновить гибридную подпись, используя ключ PQC, сгенерированный Google Play, что обеспечит защиту вашего приложения без необходимости ручного управления ключами.
- Приложения, использующие самостоятельно управляемые ключи: Разработчики, которые управляют собственными ключами подписи, могут использовать обновленные инструменты сборки Android (например, apksigner) для перехода к гибридной идентификации, сочетающей ключ PQC с новым классическим ключом. (Необходимо создать новый классический ключ, старый использовать нельзя.)
Подключение
В Android 17 добавлены следующие функции для улучшения взаимодействия устройств и приложений.
Ограниченные спутниковые сети
Внедряет оптимизации, позволяющие приложениям эффективно работать в сетях спутниковой связи с низкой пропускной способностью.
Пользовательский опыт и пользовательский интерфейс системы
В Android 17 внесены следующие изменения для улучшения пользовательского опыта.
Поток выделенного аудиопомощника
В Android 17 представлен выделенный поток громкости для приложений Assistant, воспроизводимый с параметром USAGE_ASSISTANT . Это изменение отделяет звук Assistant от стандартного медиапотока, предоставляя пользователям изолированное управление громкостью обоих потоков. Это позволяет, например, отключать воспроизведение мультимедиа, сохраняя при этом слышимость ответов Assistant, и наоборот.
Приложения-помощники, имеющие доступ к новому аудиорежиму MODE_ASSISTANT_CONVERSATION могут еще больше повысить согласованность регулировки громкости. Приложения-помощники могут использовать этот режим, чтобы подсказывать системе об активной сессии помощника, гарантируя, что потоком помощника можно управлять вне активной сессии воспроизведения USAGE_ASSISTANT или с помощью подключенных периферийных устройств Bluetooth.
Передавать
Handoff is a new feature and API coming to Android 17 that app developers can integrate with to provide cross-device continuity for their users. It allows the user to start an app activity on one Android device and transition it to another Android device. Handoff runs in the background of a user's device and surfaces available activities from the user's other nearby devices through various entry points, like the launcher and taskbar, on the receiving device.
Apps can designate Handoff to launch the same native Android app, if it is installed and available on the receiving device. In this app-to-app flow, the user is deep-linked to the designated activity. Alternatively, app-to-web Handoff can be offered as a fallback option or directly implemented with URL Handoff.
Handoff support is implemented on a per-activity basis. To enable Handoff, call
the setHandoffEnabled() method for the activity. Additional data may need to
be passed along with the handoff so the recreated activity on the receiving
device can restore appropriate state. Implement the
onHandoffActivityRequested() callback to return a HandoffActivityData object
which contains details that specify how Handoff should handle and recreate
the activity on the receiving device.
Обновление в реальном времени - API семантического цвета
With Android 17, Live Update launches the Semantic Coloring APIs to support colors with universal meaning.
The following classes support semantic coloring:
NotificationNotification.MetricNotification.ProgressStyle.PointNotification.ProgressStyle.Segment
Coloring
- Green: Associated with safety. This color should be used for the case where it lets people know you are in the safe situation.
- Orange: For designating caution and marking physical hazards. This color should be used in the situation where users need to pay attention to set better protection setting.
- Red: Generally indicates danger, stop. It should be presented for the case where need people's attention urgently.
- Blue: Neutral color for content that is informational and should stand out from other content.
The following example shows how to apply semantic styles to text in a notification:
val ssb = SpannableStringBuilder()
.append("Colors: ")
.append("NONE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_UNSPECIFIED), 0)
.append(", ")
.append("INFO", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_INFO), 0)
.append(", ")
.append("SAFE", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_SAFE), 0)
.append(", ")
.append("CAUTION", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_CAUTION), 0)
.append(", ")
.append("DANGER", Notification.createSemanticStyleAnnotation(SEMANTIC_STYLE_DANGER), 0)
Notification.Builder(context, channelId)
.setSmallIcon(R.drawable.ic_icon)
.setContentTitle("Hello World!")
.setContentText(ssb)
.setOngoing(true)
.setRequestPromotedOngoing(true)
API UWB Downlink-TDoA для Android 17
Downlink Time Difference of Arrival (DL-TDoA) ranging lets a device determine its position relative to multiple anchors by measuring the relative arrival times of signals.
The following snippet demonstrates how to initialize the Ranging Manager, verify device capabilities, and start a DL-TDoA session:
Kotlin
class RangingApp {
fun initDlTdoa(context: Context) {
// Initialize the Ranging Manager
val rangingManager = context.getSystemService(RangingManager::class.java)
// Register for device capabilities
val capabilitiesCallback = object : RangingManager.CapabilitiesCallback {
override fun onRangingCapabilities(capabilities: RangingCapabilities) {
// Make sure Dl-TDoA is supported before starting the session
if (capabilities.uwbCapabilities != null && capabilities.uwbCapabilities!!.isDlTdoaSupported) {
startDlTDoASession(context)
}
}
}
rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback)
}
fun startDlTDoASession(context: Context) {
// Initialize the Ranging Manager
val rangingManager = context.getSystemService(RangingManager::class.java)
// Create session and configure parameters
val executor = Executors.newSingleThreadExecutor()
val rangingSession = rangingManager.createRangingSession(executor, RangingSessionCallback())
val rangingRoundIndexes = intArrayOf(0)
val config: ByteArray = byteArrayOf() // OOB config data
val params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes)
val rangingDevice = RangingDevice.Builder().build()
val rawTagDevice = RawRangingDevice.Builder()
.setRangingDevice(rangingDevice)
.setDlTdoaRangingParams(params)
.build()
val dtTagConfig = RawDtTagRangingConfig.Builder(rawTagDevice).build()
val preference = RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
.setSessionConfig(SessionConfig.Builder().build())
.build()
// Start the ranging session
rangingSession.start(preference)
}
}
private class RangingSessionCallback : RangingSession.Callback {
override fun onDlTdoaResults(peer: RangingDevice, measurement: DlTdoaMeasurement) {
// Process measurement results here
}
}
Java
public class RangingApp {
public void initDlTdoa(Context context) {
// Initialize the Ranging Manager
RangingManager rangingManager = context.getSystemService(RangingManager.class);
// Register for device capabilities
RangingManager.CapabilitiesCallback capabilitiesCallback = new RangingManager.CapabilitiesCallback() {
@Override
public void onRangingCapabilities(RangingCapabilities capabilities) {
// Make sure Dl-TDoA is supported before starting the session
if (capabilities.getUwbCapabilities() != null && capabilities.getUwbCapabilities().isDlTdoaSupported) {
startDlTDoASession(context);
}
}
};
rangingManager.registerCapabilitiesCallback(Executors.newSingleThreadExecutor(), capabilitiesCallback);
}
public void startDlTDoASession(Context context) {
RangingManager rangingManager = context.getSystemService(RangingManager.class);
// Create session and configure parameters
Executor executor = Executors.newSingleThreadExecutor();
RangingSession rangingSession = rangingManager.createRangingSession(executor, new RangingSessionCallback());
int[] rangingRoundIndexes = new int[] {0};
byte[] config = new byte[0]; // OOB config data
DlTdoaRangingParams params = DlTdoaRangingParams.createFromFiraConfigPacket(config, rangingRoundIndexes);
RangingDevice rangingDevice = new RangingDevice.Builder().build();
RawRangingDevice rawTagDevice = new RawRangingDevice.Builder()
.setRangingDevice(rangingDevice)
.setDlTdoaRangingParams(params)
.build();
RawDtTagRangingConfig dtTagConfig = new RawDtTagRangingConfig.Builder(rawTagDevice).build();
RangingPreference preference = new RangingPreference.Builder(DEVICE_ROLE_DT_TAG, dtTagConfig)
.setSessionConfig(new SessionConfig.Builder().build())
.build();
// Start the ranging session
rangingSession.start(preference);
}
private static class RangingSessionCallback implements RangingSession.Callback {
@Override
public void onDlTdoaResults(RangingDevice peer, DlTdoaMeasurement measurement) {
// Process measurement results here
}
}
}
Out-of-Band (OOB) Configurations
The following snippet provides an example of DL-TDoA OOB configuration data for Wi-Fi and BLE:
Java
// Wifi Configuration
byte[] wifiConfig = {
(byte) 0xDD, (byte) 0x2D, (byte) 0x5A, (byte) 0x18, (byte) 0xFF, // Header
(byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
(byte) 0x02, (byte) 0x00, // Profile ID
(byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
(byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
(byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
(byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
(byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
(byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
(byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
(byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01 // Session ID
};
// BLE Configuration
byte[] bleConfig = {
(byte) 0x2D, (byte) 0x16, (byte) 0xF4, (byte) 0xFF, // Header
(byte) 0x5F, (byte) 0x19, // FiRa Sub-Element
(byte) 0x02, (byte) 0x00, // Profile ID
(byte) 0x06, (byte) 0x02, (byte) 0x20, (byte) 0x08, // MAC Address
(byte) 0x14, (byte) 0x01, (byte) 0x0C, // Preamble Index
(byte) 0x27, (byte) 0x02, (byte) 0x08, (byte) 0x07, // Vendor ID
(byte) 0x28, (byte) 0x06, (byte) 0xCA, (byte) 0xC8, (byte) 0xA6, (byte) 0xF7, (byte) 0x6F, (byte) 0x08, // Static STS IV
(byte) 0x08, (byte) 0x02, (byte) 0x60, (byte) 0x09, // Slot Duration
(byte) 0x1B, (byte) 0x01, (byte) 0x0A, // Slots per RR
(byte) 0x09, (byte) 0x04, (byte) 0xE8, (byte) 0x03, (byte) 0x00, (byte) 0x00, // Duration
(byte) 0x9F, (byte) 0x04, (byte) 0x67, (byte) 0x45, (byte) 0x23, (byte) 0x01 // Session ID
};
If you can't use an OOB configuration because it is missing, or if you need to
change default values that aren't in the OOB config, you can build parameters
with DlTdoaRangingParams.Builder as shown in the following snippet. You can use
these parameters in place of DlTdoaRangingParams.createFromFiraConfigPacket():
Kotlin
val dlTdoaParams = DlTdoaRangingParams.Builder(1)
.setComplexChannel(UwbComplexChannel.Builder()
.setChannel(9).setPreambleIndex(10).build())
.setDeviceAddress(deviceAddress)
.setSessionKeyInfo(byteArrayOf(0x01, 0x02, 0x03, 0x04))
.setRangingIntervalMillis(240)
.setSlotDuration(UwbRangingParams.DURATION_2_MS)
.setSlotsPerRangingRound(20)
.setRangingRoundIndexes(byteArrayOf(0x01, 0x05))
.build()
Java
DlTdoaRangingParams dlTdoaParams = new DlTdoaRangingParams.Builder(1)
.setComplexChannel(new UwbComplexChannel.Builder()
.setChannel(9).setPreambleIndex(10).build())
.setDeviceAddress(deviceAddress)
.setSessionKeyInfo(new byte[]{0x01, 0x02, 0x03, 0x04})
.setRangingIntervalMillis(240)
.setSlotDuration(UwbRangingParams.DURATION_2_MS)
.setSlotsPerRangingRound(20)
.setRangingRoundIndexes(new byte[]{0x01, 0x05})
.build();