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

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

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

Удобство для пользователей и системный интерфейс

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

Отказ от показа от края до края больше не поддерживается

В 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. Чтобы обеспечить поддержку полноэкранного режима, ознакомьтесь с рекомендациями по работе с Compose и Views.

Для предпросмотра при жесте "Назад" требуется перенос или отказ

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

Если ваше приложение перехватывает событие "Назад" и вы ещё не перешли на предпросмотр для жеста "Назад", обновите приложение, чтобы использовать поддерживаемые API обратной навигации, или временно отключите эту функцию, установив для атрибута android:enableOnBackInvokedCallback значение false в теге <application> или <activity> файла AndroidManifest.xml приложения.

Поддержка Elegant Font API прекращена, и они отключены

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

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

Основные функции

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

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

До ориентации на Android 16, когда scheduleAtFixedRate пропускало выполнение задачи из-за того, что оно находилось за пределами допустимого жизненного цикла процесса , все пропущенные выполнения выполнялись немедленно, когда приложение возвращалось к допустимому жизненному циклу.

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

Типы устройств

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

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

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

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

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

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

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

Распространенные критические изменения

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

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

Подробная информация о реализации

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

• screenOrientation
• resizableActivity
• minAspectRatio
• maxAspectRatio
• setRequestedOrientation()
• getRequestedOrientation()

Следующие значения для 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, которые также используются на платформе Здоровье и спорт. Начиная с Android 16 для любых API, требовавших разрешений BODY_SENSORS или BODY_SENSORS_BACKGROUND, теперь нужно использовать соответствующее разрешение android.permissions.health. Это касается следующих типов данных, API и активных служб:

• HEART_RATE_BPM из сервисов наблюдения за здоровьем на 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.

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

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

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

Функции связи

В 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, теперь могут отключать сопряжение устройств Bluetooth с помощью общедоступного API в CompanionDeviceManager . Если сопутствующее устройство управляется как ассоциация CDM, то приложение может инициировать удаление связи Bluetooth с помощью нового API removeBond(int) на связанном устройстве. Приложение может отслеживать изменения состояния связи, прослушивая событие широковещательной передачи устройства Bluetooth ACTION_BOND_STATE_CHANGED .

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

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

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

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

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

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

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

Мы вносим два основных изменения:

1. Явные интенты должны соответствовать фильтру интентов целевого компонента. Если интент явно нацелен на компонент, он должен соответствовать фильтру интентов этого компонента.

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

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

Влияние

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

• знаете о функции 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>

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

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

Когда принудительное применение активно, приложения должны работать правильно, если вызывающий объект намерения правильно заполнил намерение. Однако заблокированные интенты будут вызывать предупреждения в журнале, например "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:")

Фильтрация системных вызовов графического процессора

Чтобы усилить защиту графического процессора Mali, в рабочих сборках были заблокированы его системные вызовы IOCTL, которые устарели или предназначены только для разработки. Кроме того, 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.

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

1. Распространяются ли новые правила на всех OEM-производителей? Это изменение будет необязательным, но доступным для всех OEM-производителей, которые захотят использовать этот метод усиления защиты. Инструкции по реализации изменений можно найти в документации по реализации.

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

3. Должны ли производители однокристальных систем поддерживать список IOCTL в актуальном состоянии? Например, если на моем устройстве установлен графический процессор ARM Mali, нужно ли мне обращаться в ARM по поводу изменений? Отдельные однокристальные системы должны обновлять свои списки IOCTL для каждого устройства при выпуске драйвера. Например, ARM обновляет опубликованный список IOCTL при обновлении драйверов. Однако OEM-производители должны убедиться, что они включают обновления в свою SEPolicy, и при необходимости добавить в списки любые выбранные пользовательские IOCTL.

4. Это изменение применяется ко всем устройствам Pixel, доступным в вашем регионе, автоматически или требуется действие пользователя, чтобы включить или отключить что-то для применения этого изменения? Это изменение касается всех устройств Pixel, использующих графический процессор Mali (Pixel 6–9). От пользователей не требуется никаких действий.

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

6. Должен ли список IOCTL соответствовать текущим версиям пользовательского пространства и драйвера ядра? Да, список разрешенных IOCTL должен быть синхронизирован с IOCTL, поддерживаемыми драйверами пространства пользователя и ядра. Если IOCTL в пользовательском пространстве или драйвере ядра обновляются, список IOCTL SEPolicy должен быть обновлен соответствующим образом.

7. ARM относит IOCTL к категории ограниченных или предназначенных для инструментального контроля, но мы хотим использовать некоторые из них в производственных целях и/или запретить другие. Производители оборудования и систем на кристалле сами решают, как классифицировать используемые ими IOCTL, исходя из конфигурации библиотек Mali в пространстве пользователя. Список ARM может помочь принять решение, но у каждого OEM-производителя или SoC могут быть свои особенности.

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

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

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

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

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

План выпуска

Это изменение будет развернуто в два этапа: во втором квартале 2025 г. и втором квартале 2026 г. Разработчикам необходимо следовать этим рекомендациям во втором квартале 2025 года и делиться отзывами, поскольку эти меры защиты будут применяться в более поздней версии Android. Кроме того, им нужно будет обновить сценарии, которые зависят от неявного доступа к локальной сети, используя приведенные ниже рекомендации, и подготовиться к тому, что пользователи могут отклонить или отозвать новое разрешение.

Влияние

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

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

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

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

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

Исключения из правил:

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

Руководство для разработчиков (согласие)

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

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

3. Включите флажок Appcompat в adb:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

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

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

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

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

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

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

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

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Ошибки

Ошибки, связанные с этими ограничениями, будут возвращаться вызывающему сокету при каждом вызове метода 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 // Link Local
• 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;
• Несколько подсетей (будет определено позже)

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

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