Эта страница переведена с помощью Cloud Translation API.

Изменения в поведении: приложения для Android 16 или более поздней версии.

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

Обязательно ознакомьтесь со списком изменений поведения, которые влияют на все приложения, работающие на Android 16, независимо от targetSdkVersion вашего приложения.

Пользовательский опыт и системный пользовательский интерфейс

Android 16 (уровень API 36) включает в себя следующие изменения, направленные на создание более последовательного и интуитивно понятного пользовательского опыта.

Отказ от функции Edge to Edge прекращается

В Android 15 реализована функция «от края до края» для приложений, предназначенных для Android 15 (уровень API 35), но ваше приложение может отказаться от неё, установив параметр R.attr#windowOptOutEdgeToEdgeEnforcement в значение true . Для приложений, предназначенных для Android 16 (уровень API 36), R.attr#windowOptOutEdgeToEdgeEnforcement устарел и отключён, и ваше приложение не может отказаться от функции «от края до края».

Если ваше приложение ориентировано на Android 16 (уровень API 36) и работает на устройстве Android 15, R.attr#windowOptOutEdgeToEdgeEnforcement продолжает работать.
Если ваше приложение ориентировано на Android 16 (уровень API 36) и работает на устройстве Android 16, R.attr#windowOptOutEdgeToEdgeEnforcement отключен.

Для тестирования на Android 16 убедитесь, что ваше приложение поддерживает режим «от края до края», и удалите любое использование R.attr#windowOptOutEdgeToEdgeEnforcement , чтобы ваше приложение также поддерживало режим «от края до края» на устройстве Android 15. Чтобы узнать о поддержке режима «от края до края», см. руководство по созданию и просмотру сообщений .

Для прогнозируемого возврата требуется миграция или отказ

For apps targeting Android 16 (API level 36) or higher and running on an Android 16 or higher device, the predictive back system animations (back-to-home, cross-task, and cross-activity) are enabled by default. Additionally, onBackPressed is not called and KeyEvent.KEYCODE_BACK is not dispatched anymore.

If your app intercepts the back event and you haven't migrated to predictive back yet, update your app to use supported back navigation APIs, or temporarily opt out by setting the android:enableOnBackInvokedCallback attribute to false in the <application> or <activity> tag of your app's AndroidManifest.xml file.

The predictive back-to-home animation.

The predictive cross-activity animation.

The predictive cross-task animation.

API элегантных шрифтов устарели и отключены

В приложениях для Android 15 (уровень API 35) атрибут elegantTextHeight TextView по умолчанию установлен в true , что заменяет компактный шрифт на более читабельный. Вы можете переопределить это, установив атрибут elegantTextHeight в false .

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

Поведение `elegantTextHeight` для приложений, ориентированных на Android 14 (уровень API 34) и ниже, или для приложений, ориентированных на Android 15 (уровень API 35), которые переопределяют значение по умолчанию, устанавливая атрибут `elegantTextHeight` в `false` .

Поведение `elegantTextHeight` для приложений, ориентированных на Android 16 (уровень API 36), или для приложений, ориентированных на Android 15 (уровень API 35), которые не переопределяют значение по умолчанию путем установки атрибута `elegantTextHeight` в `false` .

Основная функциональность

Android 16 (уровень API 36) включает в себя следующие изменения, которые изменяют или расширяют различные основные возможности системы Android.

Оптимизация графика работы с фиксированной ставкой

Prior to targeting Android 16, when scheduleAtFixedRate missed a task execution due to being outside a valid process lifecycle, all missed executions immediately execute when the app returns to a valid lifecycle.

When targeting Android 16, at most one missed execution of scheduleAtFixedRate is immediately executed when the app returns to a valid lifecycle. This behavior change is expected to improve app performance. Test this behavior in your app to check if your app is impacted. You can also test by using the app compatibility framework and enabling the STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS compat flag.

Форм-факторы устройств

Android 16 (уровень API 36) включает следующие изменения для приложений при отображении на устройствах с большим экраном.

Адаптивные макеты

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

Игнорировать ограничения по ориентации, изменению размера и соотношению сторон

Для приложений, ориентированных на Android 16 (API уровня 36), Android 16 включает изменения в управлении ограничениями ориентации, изменения размера и соотношения сторон. На дисплеях с минимальной шириной >= 600 dp эти ограничения больше не действуют. Приложения также заполняют всё окно дисплея, независимо от соотношения сторон или предпочитаемой пользователем ориентации, при этом эффект «пилларбоксинга» не используется.

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

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

Общие критические изменения

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

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

Подробности реализации

Следующие атрибуты манифеста и API среды выполнения игнорируются на устройствах с большим экраном в полноэкранном и многооконном режимах:

Следующие значения screenOrientation , setRequestedOrientation() и getRequestedOrientation() игнорируются:

portrait
reversePortrait
sensorPortrait
userPortrait
landscape
reverseLandscape
sensorLandscape
userLandscape

Что касается изменения размера дисплея, android:resizeableActivity="false" , android:minAspectRatio и android:maxAspectRatio не оказывают никакого влияния.

Для приложений, ориентированных на Android 16 (уровень API 36), ограничения по ориентации, изменению размера и соотношению сторон приложения по умолчанию игнорируются на больших экранах, но каждое приложение, которое еще не полностью готово, может временно переопределить это поведение, отказавшись от него (что приводит к предыдущему поведению — переходу в режим совместимости).

Исключения

Ограничения Android 16 по ориентации, изменению размера и соотношению сторон не применяются в следующих ситуациях:

Игры (на основе флага android:appCategory )
Пользователи явно соглашаются на поведение приложения по умолчанию в настройках соотношения сторон устройства.
Экраны меньше sw600dp

Временно отказаться

Чтобы отказаться от определенного действия, объявите свойство манифеста PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY :

<activity ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
  ...
</activity>

Если слишком много частей вашего приложения не готовы к Android 16, вы можете полностью отказаться от этого, применив то же свойство на уровне приложения:

<application ...>
  <property android:name="android.window.PROPERTY_COMPAT_ALLOW_RESTRICTED_RESIZABILITY" android:value="true" />
</application>

Здоровье и фитнес

Android 16 (уровень API 36) включает следующие изменения, связанные с данными о здоровье и фитнесе.

Разрешения на здравоохранение и фитнес

Для приложений, ориентированных на Android 16 (уровень API 36) и выше, разрешения BODY_SENSORS используют более детальные разрешения в рамках android.permissions.health , которые также использует Health Connect . Начиная с Android 16, любой API, ранее требовавший BODY_SENSORS или BODY_SENSORS_BACKGROUND требует вместо этого соответствующего разрешения android.permissions.health . Это касается следующих типов данных, API и типов приоритетных служб:

HEART_RATE_BPM от Health Services на Wear OS
Sensor.TYPE_HEART_RATE из Android Sensor Manager
heartRateAccuracy и heartRateBpm от ProtoLayout на Wear OS
FOREGROUND_SERVICE_TYPE_HEALTH , где вместо BODY_SENSORS требуется соответствующее разрешение android.permission.health

Если ваше приложение использует эти API, оно должно запрашивать соответствующие детальные разрешения:

Для мониторинга частоты сердечных сокращений, SpO2 или температуры кожи во время использования: запросите детальное разрешение в android.permissions.health , например READ_HEART_RATE вместо BODY_SENSORS .
Для доступа к фоновому датчику: запросите READ_HEALTH_DATA_IN_BACKGROUND вместо BODY_SENSORS_BACKGROUND .

Эти разрешения аналогичны тем, которые защищают доступ к чтению данных из Health Connect — хранилища данных Android для здоровья, фитнеса и благополучия.

Мобильные приложения

Мобильные приложения, переходящие на использование READ_HEART_RATE и других детальных разрешений, также должны декларировать действие для отображения политики конфиденциальности приложения. Это требование аналогично Health Connect.

Связность

Android 16 (уровень API 36) включает следующие изменения в стеке Bluetooth для улучшения связи с периферийными устройствами.

Новые намерения по управлению потерями облигаций и изменениями в шифровании

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

Приложения для Android 16 теперь могут:

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

Адаптация к различным реализациям OEM

Хотя Android 16 представляет эти новые намерения, их реализация и трансляция могут различаться у разных производителей устройств (OEM). Чтобы гарантировать, что ваше приложение обеспечивает единообразный и надежный опыт на всех устройствах, разработчикам следует разработать обработку потери связи, чтобы изящно адаптироваться к этим потенциальным изменениям.

Мы рекомендуем следующее поведение приложения:

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

Новый способ удаления связи Bluetooth

现在，以 Android 16 为目标平台的所有应用都可以使用 CompanionDeviceManager 中的公共 API 解除蓝牙设备配对。如果配套设备作为 CDM 关联进行管理，则应用可以在关联的设备上使用新的 removeBond(int) API 触发蓝牙配对的移除。该应用可以通过监听蓝牙设备广播事件 ACTION_BOND_STATE_CHANGED 来监控配对状态变化。

Безопасность

Android 16 (уровень API 36) включает следующие изменения безопасности.

Блокировка версии MediaStore

对于以 Android 16 或更高版本为目标平台的应用，MediaStore#getVersion() 现在将是每个应用的唯一标识。这会从版本字符串中移除标识属性，以防止滥用和用于指纹识别技术。应用不应对此版本的格式做出任何假设。在使用此 API 时，应用应已处理版本变更，并且在大多数情况下无需更改其当前行为，除非开发者尝试推断超出此 API 预期范围的其他信息。

Более безопасные намерения

Функция Safer Intents — это многоэтапная инициатива безопасности, призванная повысить безопасность механизма разрешения намерений Android. Цель — защитить приложения от вредоносных действий путём добавления проверок при обработке намерений и фильтрации намерений, не соответствующих определённым критериям.

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

Реализуются два ключевых изменения:

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

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

Влияние

Политика добровольного включения означает, что разработчики должны явно включить её в манифесте своего приложения, чтобы она вступила в силу. В результате влияние функции будет ограничено приложениями, разработчики которых:

Знают о функции Safer Intents и ее преимуществах.
Активно внедрять в свои приложения более строгие методы обработки намерений.

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

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

Функция Safer Intents может значительно повысить безопасность экосистемы Android, затруднив вредоносным приложениям использование уязвимостей в механизме разрешения намерений.

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

Выполнение

Разработчикам необходимо явно включить более строгое сопоставление намерений с помощью атрибута intentMatchingFlags в манифесте приложения. Вот пример, где эта функция включена для всего приложения, но отключена/отключена для получателя:

<application android:intentMatchingFlags="enforceIntentFilter">
    <receiver android:name=".MyBroadcastReceiver" android:exported="true" android:intentMatchingFlags="none">
        <intent-filter>
            <action android:name="com.example.MY_CUSTOM_ACTION" />
        </intent-filter>
        <intent-filter>
            <action android:name="com.example.MY_ANOTHER_CUSTOM_ACTION" />
        </intent-filter>
    </receiver>
</application>

Подробнее о поддерживаемых флагах:

Название флага	Описание
EnsureIntentFilter	Обеспечивает более строгое соответствие входящим намерениям
никто	Отключает все специальные правила сопоставления для входящих намерений. При указании нескольких флагов конфликтующие значения разрешаются путём предоставления приоритета флагу «none».
allowNullAction	Ослабляет правила сопоставления, позволяя сопоставлять намерения без действия. Этот флаг следует использовать вместе с «enforceIntentFilter» для достижения определённого поведения.

Тестирование и отладка

При включенном принудительном применении приложения должны работать корректно, если вызывающая сторона правильно заполнила намерение. Однако заблокированные намерения приведут к появлению предупреждений в журнале, таких как "Intent does not match component's intent filter:" и "Access blocked:" с тегом "PackageManager." Это указывает на потенциальную проблему, которая может повлиять на работу приложения и требует внимания.

Фильтр Logcat:

tag=:PackageManager & (message:"Intent does not match component's intent filter:" | message: "Access blocked:")

Фильтрация системных вызовов GPU

Для повышения безопасности графического процессора Mali в производственных сборках заблокированы устаревшие или предназначенные исключительно для разработки графических процессоров IOCTL-коды Mali GPU. Кроме того, IOCTL-коды, используемые для профилирования графических процессоров, ограничены процессом оболочки или отлаживаемыми приложениями. Подробнее о политике на уровне платформы см. в обновлении SAC.

Это изменение происходит на устройствах Pixel с графическим процессором Mali (Pixel 6-9). Компания Arm предоставила официальную классификацию своих IOCTL в Documentation/ioctl-categories.rst версии r54p2 . Этот список будет поддерживаться в будущих версиях драйверов.

Это изменение не повлияет на поддерживаемые графические API (включая Vulkan и OpenGL) и, как ожидается, не повлияет на разработчиков или существующие приложения. Инструменты профилирования графического процессора, такие как Streamline Performance Analyzer и Android GPU Inspector, не будут затронуты.

Тестирование

Если вы видите сообщение об отказе SELinux, похожее на следующее, скорее всего, это изменение повлияло на ваше приложение:

06-30 10:47:18.617 20360 20360 W roidJUnitRunner: type=1400 audit(0.0:85): avc:  denied  { ioctl }
for  path="/dev/mali0" dev="tmpfs" ino=1188 ioctlcmd=0x8023
scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:gpu_device:s0 tclass=chr_file
permissive=0 app=com.google.android.selinux.pts

Если вашему приложению необходимо использовать заблокированные IOCTL, сообщите об ошибке и направьте ее на адрес android-partner-security@google.com.

Часто задаваемые вопросы

Распространяется ли это изменение политики на всех OEM-производителей? Это изменение будет добровольным, но доступным для всех OEM-производителей, желающих использовать этот метод защиты. Инструкции по внедрению изменения можно найти в документации по внедрению.
Обязательно ли вносить изменения в кодовую базу OEM для реализации этого, или это по умолчанию включено в новый релиз AOSP? Изменения на уровне платформы по умолчанию будут включены в новый релиз AOSP. Поставщики могут включить это изменение в свою кодовую базу, если захотят.
Отвечают ли SoC за поддержание списка IOCTL в актуальном состоянии? Например, если в моём устройстве используется графический процессор ARM Mali, нужно ли мне обращаться в ARM за какими-либо изменениями? Каждый SoC должен обновлять свои списки IOCTL для каждого устройства после выпуска драйвера. Например, ARM обновляет опубликованный список IOCTL при обновлении драйверов. Однако OEM-производители должны включить обновления в свою политику безопасности (SEPolicy) и добавлять в списки любые выбранные пользовательские IOCTL по мере необходимости.
Применяется ли это изменение автоматически ко всем устройствам Pixel, доступным на рынке, или для его применения требуется действие пользователя, чтобы включить какой-либо переключатель? Это изменение применяется ко всем устройствам Pixel, доступным на рынке, с графическим процессором Mali (Pixel 6-9). Для применения этого изменения не требуется никаких действий пользователя.
Повлияет ли использование этой политики на производительность драйвера ядра? Эта политика была протестирована на графическом процессоре Mali с помощью GFXBench, и никаких заметных изменений производительности графического процессора не наблюдалось.
Необходимо ли, чтобы список IOCTL соответствовал текущим версиям драйверов пользовательского пространства и ядра? Да, список разрешённых IOCTL должен быть синхронизирован с IOCTL, поддерживаемыми как драйверами пользовательского пространства, так и драйверами ядра. Если IOCTL в пользовательском пространстве или драйвере ядра обновляются, список IOCTL SEPolicy также должен быть обновлён для соответствия.
Компания ARM классифицировала IOCTL как «ограниченные»/«инструментальные», но мы хотим использовать некоторые из них в производственных сценариях и/или запретить другие. Каждый OEM-производитель/систем на кристалле самостоятельно определяет, как классифицировать используемые им IOCTL, основываясь на конфигурации библиотек Mali в пользовательском пространстве. Список ARM может помочь в принятии решения, но сценарии использования каждого OEM-производителя/системы на кристалле могут отличаться.

Конфиденциальность

Android 16 (уровень API 36) включает следующие изменения в политике конфиденциальности.

Разрешение локальной сети

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

Проект Local Network Protections направлен на защиту конфиденциальности пользователя путем ограничения доступа к локальной сети с помощью нового разрешения во время выполнения.

План выпуска

Это изменение будет внедрено между двумя выпусками: 25-м кварталом 2020 года и 2021 года (будет объявлено позднее). Разработчикам крайне важно следовать этим рекомендациям во 2-м квартале 2020 года и делиться отзывами, поскольку эти меры защиты будут реализованы в более позднем выпуске Android . Кроме того, им необходимо будет обновить сценарии, зависящие от неявного доступа к локальной сети, следуя следующим рекомендациям, и подготовиться к отклонению и отзыву нового разрешения пользователем.

Влияние

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

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

Прямое или библиотечное использование сырых сокетов на локальных сетевых адресах (например, протокол обнаружения сервисов mDNS или SSDP)
Использование классов уровня фреймворка, которые обращаются к локальной сети (например, NsdManager)

Для передачи трафика с адреса локальной сети и в обратном направлении требуется разрешение на доступ к локальной сети. В следующей таблице перечислены некоторые распространённые случаи:

Сетевые операции низкого уровня приложения	Требуется разрешение локальной сети
Создание исходящего TCP-соединения	да
Прием входящих TCP-соединений	да
Отправка UDP-одноадресного, многоадресного, широковещательного сообщения	да
Прием входящего UDP-одноадресного, многоадресного, широковещательного сообщения	да

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

Исключения из правил, указанных выше:

Если DNS-сервер устройства находится в локальной сети, то для трафика к нему или с него (через порт 53) не требуется разрешение на доступ к локальной сети.
Приложениям, использующим Output Switcher в качестве встроенного средства выбора, не потребуются разрешения локальной сети (более подробные инструкции появятся в четвертом квартале 2025 года).

Руководство для разработчиков (по желанию)

Чтобы включить ограничения локальной сети, выполните следующие действия:

Перепрошейте устройство до сборки 25Q2 Beta 3 или более поздней.
Установите приложение для тестирования.

Переключить флаг Appcompat в adb:

adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>

Перезагрузите устройство.

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

Чтобы восстановить доступ, необходимо предоставить приложению разрешение NEARBY_WIFI_DEVICES .

Убедитесь, что приложение объявляет разрешение NEARBY_WIFI_DEVICES в своем манифесте.
Откройте Настройки > Приложения > [Имя приложения] > Разрешения > Устройства поблизости > Разрешить .

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

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

Разрешение	Исходящий запрос локальной сети	Исходящий/входящий Интернет-запрос	Входящий запрос локальной сети
Предоставленный	Работы	Работы	Работы
Не предоставлено	Неудачи	Работы	Неудачи

Используйте следующую команду, чтобы отключить флаг App-Compat.

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Ошибки

Ошибки, возникающие из-за этих ограничений, будут возвращаться вызывающему сокету всякий раз, когда он вызывает send или вариант send на локальный сетевой адрес.

Примеры ошибок:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Определение локальной сети

Под локальной сетью в данном проекте понимается IP-сеть, которая использует сетевой интерфейс с возможностью широковещательной передачи, такой как Wi-Fi или Ethernet, но исключает сотовые (WWAN) или VPN-подключения.

Локальными сетями считаются:

IPv4:

169.254.0.0/16 // Локальная ссылка
100.64.0.0/10 // CGNAT
10.0.0.0/8 // RFC1918
172.16.0.0/12 // RFC1918
192.168.0.0/16 // RFC1918

IPv6:

Локальная ссылка
Маршруты с прямым соединением
Заглушки сетей типа Thread
Несколько подсетей (TBD)

Кроме того, как многоадресные адреса (224.0.0.0/4, ff00::/8), так и широковещательный адрес IPv4 (255.255.255.255) классифицируются как адреса локальной сети.

Фотографии, принадлежащие приложению

{% включают "/training/data-storage/shared/___owned-photos" %}