Davranış değişiklikleri: Android 16 veya sonraki sürümleri hedefleyen uygulamalar

Önceki sürümlerde olduğu gibi Android 16 da uygulamanızı etkileyebilecek davranış değişiklikleri içerir. Aşağıdaki davranış değişiklikleri yalnızca Android 16 veya sonraki sürümleri hedefleyen uygulamalar için geçerlidir. Uygulamanız Android 16 veya sonraki sürümleri hedefliyorsa uygulanabilir durumlarda bu davranışları destekleyecek şekilde uygulamanızı değiştirmeniz gerekir.

Uygulamanızın targetSdkVersion değerinden bağımsız olarak, Android 16'da çalışan tüm uygulamaları etkileyen davranış değişiklikleri listesini de incelemeyi unutmayın.

Kullanıcı deneyimi ve sistem arayüzü

Android 16 (API düzeyi 36), daha tutarlı ve sezgisel bir kullanıcı deneyimi oluşturmak için aşağıdaki değişiklikleri içerir.

Uçtan uca kapsam dışında kalma özelliği kaldırılıyor

Android 15 强制执行全屏显示，但您的应用可以通过将 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 指南。

Tahmin edilen geri gitme özelliği için taşıma veya devre dışı bırakma işlemi gerekir

对于以 Android 16（API 级别 36）或更高版本为目标平台且在搭载 Android 16 或更高版本的设备上运行的应用，预测性返回系统动画（返回主屏幕、跨任务和跨 activity）默认处于启用状态。此外，系统不再调用 onBackPressed，也不再调度 KeyEvent.KEYCODE_BACK。

如果您的应用会拦截返回事件，但您尚未迁移到预测性返回，请更新应用以使用受支持的返回导航 API，或者通过在应用的 AndroidManifest.xml 文件的 <application> 或 <activity> 标记中将 android:enableOnBackInvokedCallback 属性设置为 false 来暂时选择停用。

预测性返回首页动画。

预测性跨 activity 动画。

预测性跨任务动画。

Elegant Font API'leri kullanımdan kaldırıldı ve devre dışı bırakıldı

Android 15'i (API düzeyi 35) hedefleyen uygulamalarda elegantTextHeight TextView özelliği varsayılan olarak true şeklinde ayarlanır. Bu sayede, kompakt yazı tipi çok daha okunabilir bir yazı tipiyle değiştirilir. elegantTextHeight özelliğini false olarak ayarlayarak bu durumu geçersiz kılabilirsiniz.

Android 16, elegantTextHeight özelliğinin desteğini sonlandırır. Uygulamanız Android 16'yı hedeflediğinde bu özellik yoksayılır. Bu API'ler tarafından kontrol edilen "UI fonts" desteği sonlandırılıyor. Bu nedenle, Arapça, Lao, Myanmar, Tamil, Gujarati, Kannada, Malayalam, Odia, Telugu veya Tayca dillerinde tutarlı ve gelecekte de geçerli olacak metin oluşturma için tüm düzenleri uyarlamanız gerekir.

Android 14'ü (API düzeyi 34) ve önceki sürümleri hedefleyen uygulamalarda veya elegantTextHeight özelliğini false olarak ayarlayarak varsayılan davranışı geçersiz kılan Android 15'i (API düzeyi 35) hedefleyen uygulamalarda

elegantTextHeight davranışı.

Android 16'yı (API düzeyi 36) hedefleyen uygulamalar veya elegantTextHeight özelliğini false olarak ayarlayarak varsayılanı geçersiz kılmayan Android 15'i (API düzeyi 35) hedefleyen uygulamalar için

elegantTextHeight davranışı.

Temel işlevler

Android 16 (API düzeyi 36), Android sisteminin çeşitli temel özelliklerini değiştiren veya genişleten aşağıdaki değişiklikleri içerir.

Sabit ücretli iş planlaması optimizasyonu

在以 Android 16 为目标平台之前，如果 scheduleAtFixedRate 因不在有效的进程生命周期内而错过了任务执行，则当应用返回到有效的生命周期时，所有错过的执行会立即执行。

以 Android 16 为目标平台时，当应用返回到有效的生命周期时，系统会立即执行最多 1 次未执行的 scheduleAtFixedRate 执行。此行为变更预计会提升应用性能。在您的应用中测试此行为，检查您的应用是否受到影响。您还可以使用应用兼容性框架并启用 STPE_SKIP_MULTIPLE_MISSED_PERIODIC_TASKS 兼容性标志进行测试。

Cihaz form faktörleri

Android 16 (API düzeyi 36), büyük ekranlı cihazlarda gösterilen uygulamalar için aşağıdaki değişiklikleri içerir.

Uyarlanabilir düzenler

现在，Android 应用可在各种设备（例如手机、平板电脑、可折叠设备、桌面设备、汽车和电视）上运行，并且在大屏设备上支持多种窗口模式（例如分屏和桌面窗口），因此开发者应构建能够适应任何屏幕和窗口尺寸的 Android 应用，无论设备方向如何。在当今多设备的世界中，限制屏幕方向和尺寸可调整性等范式过于严格。

忽略屏幕方向、尺寸可调整性和宽高比限制

对于以 Android 16（API 级别 36）为目标平台的应用，屏幕方向、尺寸可调整性和宽高比限制不再适用于最小宽度 >= 600dp 的显示屏。无论宽高比或用户偏好的屏幕方向如何，应用都会填满整个显示窗口，且不会采用竖条模式。

此变更引入了新的标准平台行为。Android 正在向一种模型转变，在该模型中，应用需要适应各种屏幕方向、显示大小和宽高比。固定屏幕方向或有限的尺寸调整等限制会阻碍应用的适应性。使应用具有自适应性，以提供尽可能最佳的用户体验。

您还可以使用应用兼容性框架并启用 UNIVERSAL_RESIZABLE_BY_DEFAULT 兼容性标志来测试此行为。

常见的重大更改

忽略屏幕方向、可调整大小性和宽高比限制可能会影响应用在某些设备上的界面，尤其是那些专为锁定为纵向的小布局设计的元素，例如布局拉伸、动画和组件超出屏幕等问题。任何关于宽高比或屏幕方向的假设都可能导致应用出现视觉问题。详细了解如何避免这些问题并改进应用的自适应行为。

允许设备旋转会导致更多 activity 重新创建，如果未正确保留，可能会导致用户状态丢失。如需了解如何正确保存界面状态，请参阅保存界面状态。

实现细节

在全屏模式和多窗口模式下，以下清单属性和运行时 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 的屏幕

暂时停用

如需选择停用特定 activity，请声明 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 版本中以 API 级别 37 为目标平台时，此选择停用将不再适用。也就是说，对于以 API 级别 37 为目标的应用，在至少为 sw600dp 的显示屏上，系统会忽略屏幕方向、尺寸可调整性和宽高比限制。

Sağlık ve fitness

Android 16 (API düzeyi 36), sağlık ve fitness verileriyle ilgili aşağıdaki değişiklikleri içerir.

Sağlık ve fitness izinleri

Android 16 (API düzeyi 36) veya sonraki sürümleri hedefleyen uygulamalar için, BODY_SENSORS izinler, android.permissions.health altında daha ayrıntılı izinler kullanır. Bu izinler Health Connect tarafından da kullanılır. Android 16'dan itibaren, daha önce BODY_SENSORS veya BODY_SENSORS_BACKGROUND iznini gerektiren tüm API'ler bunun yerine ilgili android.permissions.health iznini gerektirir. Bu durum aşağıdaki veri türlerini, API'leri ve ön plan hizmeti türlerini etkiler:

• Wear OS'teki Sağlık Hizmetleri'nden HEART_RATE_BPM
• Android Sensor Manager'dan Sensor.TYPE_HEART_RATE
• Wear OS'te ProtoLayout'den heartRateAccuracy ve heartRateBpm
• FOREGROUND_SERVICE_TYPE_HEALTH, BODY_SENSORS yerine ilgili android.permission.health izninin gerektiği yerlerde

Uygulamanız bu API'leri kullanıyorsa ilgili ayrıntılı izinleri istemelidir:

• Nabız, SpO2 veya deri sıcaklığının kullanım sırasında izlenmesi için: BODY_SENSORS yerine android.permissions.health altındaki ayrıntılı izni (ör. READ_HEART_RATE) isteyin.
• Arka planda sensör erişimi için BODY_SENSORS_BACKGROUND yerine request READ_HEALTH_DATA_IN_BACKGROUND kullanın.

Bu izinler, sağlık, fitness ve sağlıklı yaşam verileri için Android veri deposu olan Health Connect'ten veri okuma erişimini koruyan izinlerle aynıdır.

Mobil uygulamalar

READ_HEART_RATE ve diğer ayrıntılı izinleri kullanmaya geçen mobil uygulamalar, uygulamanın gizlilik politikasını göstermek için etkinlik bildirmelidir. Bu, Health Connect ile aynı koşuldur.

Önemli: Mobil uygulamalar için gerekçe sunulmaması, iznin iptal edilmesine neden olur.

Bağlantı

Android 16 (API düzeyi 36), çevre birimi cihazlarla bağlantıyı iyileştirmek için Bluetooth yığınında aşağıdaki değişiklikleri içerir.

Bağlantı kaybı ve şifreleme değişikliklerini işlemek için yeni amaçlar

Daha iyi bağ kaybı yönetimi kapsamında Android 16, uygulamalara bağ kaybı ve şifreleme değişiklikleri hakkında daha fazla bilgi sağlamak için 2 yeni intent de sunar.

Android 16'yı hedefleyen uygulamalar artık:

• Uzaktan bağ kaybı algılandığında ACTION_KEY_MISSING intent'i alır. Bu sayede daha bilgilendirici kullanıcı geri bildirimleri sağlayabilir ve uygun işlemleri yapabilirler.
• Bağlantının şifreleme durumu değiştiğinde bir ACTION_ENCRYPTION_CHANGE intent'i alın. Şifreleme durumu değişikliği, şifreleme algoritması değişikliği ve şifreleme anahtarı boyutu değişikliği buna dahildir. Uygulamalar, daha sonra ACTION_ENCRYPTION_CHANGE intent'i aldıktan sonra bağlantı başarıyla şifrelenirse bağın geri yüklendiğini dikkate almalıdır.

Farklı OEM uygulamalarında uyum sağlama

Android 16 bu yeni intent'leri kullanıma sunsa da bunların uygulanması ve yayınlanması farklı cihaz üreticilerine (OEM'ler) göre değişiklik gösterebilir. Uygulamanızın tüm cihazlarda tutarlı ve güvenilir bir deneyim sunmasını sağlamak için geliştiricilerin, bağlantı kaybı işlemelerini bu olası varyasyonlara sorunsuz bir şekilde uyum sağlayacak şekilde tasarlamaları gerekir.

Aşağıdaki uygulama davranışlarını öneririz:

• ACTION_KEY_MISSING intent'i yayınlanırsa:

  ACL (Asenkron Bağlantısız) bağlantısının bağlantısı sistem tarafından kesilir ancak cihazın bağ bilgileri saklanır (burada açıklandığı gibi).

  Uygulamanız, bağlantı kaybı algılama için birincil sinyal olarak bu intent'i kullanmalı ve cihazı unutma veya yeniden eşleme işlemini başlatmadan önce kullanıcıyı uzak cihazın kapsama alanında olduğunu onaylamasına yönlendirmelidir.

  Bir cihaz ACTION_KEY_MISSING alındıktan sonra bağlantısını keserse uygulamanız, cihaz artık sistemle bağlı olmayabileceğinden yeniden bağlantı kurarken dikkatli olmalıdır.

• ACTION_KEY_MISSING intent'i yayınlanmıyorsa:

  ACL bağlantısı bağlı kalır ve Android 15'teki davranışla aynı şekilde cihazın bağ bilgileri sistem tarafından kaldırılır.

  Bu senaryoda, uygulamanız, bağ kaybı etkinliklerini algılayıp yönetmek için önceki Android sürümlerindeki mevcut bağ kaybı işleme mekanizmalarını kullanmaya devam etmelidir.

Bluetooth eşlemesini kaldırmanın yeni yolu

Android 16'yı hedefleyen tüm uygulamalar artık CompanionDeviceManager'teki herkese açık bir API'yi kullanarak Bluetooth cihazlarının eşlemesini kaldırabilir. Bir tamamlayıcı cihaz CDM ilişkisi olarak yönetiliyorsa uygulama, ilişkili cihazdaki yeni removeBond(int) API'yi kullanarak Bluetooth bağını kaldırmayı tetikleyebilir. Uygulama, Bluetooth cihaz yayın etkinliğini dinleyerek ACTION_BOND_STATE_CHANGED bağ durumu değişikliklerini izleyebilir.

Güvenlik

Android 16 (API düzeyi 36) aşağıdaki güvenlik değişikliklerini içerir.

MediaStore sürüm kilitleme

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

Daha güvenli intent'ler

Safer Intents özelliği, Android'in amaç çözümleme mekanizmasının güvenliğini artırmak için tasarlanmış çok aşamalı bir güvenlik girişimidir. Amaç, niyet işleme sırasında kontroller ekleyerek ve belirli ölçütleri karşılamayan niyetleri filtreleyerek uygulamaları kötü amaçlı işlemlerden korumaktır.

Android 15'te gönderen uygulamaya odaklanan bu özellik, Android 16 ile birlikte kontrolü alan uygulamaya kaydırarak geliştiricilerin uygulama manifestlerini kullanarak katı amaç çözümlemeyi etkinleştirmesine olanak tanır.

İki önemli değişiklik uygulanıyor:

1. Belirgin Intent'ler Hedef Bileşenin Intent Filtresiyle Eşleşmelidir: Bir intent bir bileşeni açıkça hedefliyorsa bu bileşenin intent filtresiyle eşleşmelidir.

2. İşlem içermeyen Intent'ler herhangi bir Intent Filtresiyle eşleşemez: İşlemi belirtilmemiş Intent'ler herhangi bir Intent filtresiyle eşleşmemelidir.

Bu değişiklikler yalnızca birden fazla uygulamanın söz konusu olduğu durumlarda geçerlidir ve tek bir uygulamadaki amaç işleme özelliğini etkilemez.

Etki

Etkinleştirme özelliği, geliştiricilerin bu özelliğin geçerli olması için uygulama manifestlerinde açıkça etkinleştirmesi gerektiği anlamına gelir. Bu nedenle, özelliğin etkisi yalnızca geliştiricileri aşağıdaki koşulları karşılayan uygulamalarla sınırlı olacaktır:

• Daha Güvenli Amaçlar özelliği ve avantajları hakkında bilgi sahibi olmalıdır.
• Uygulamalarına daha katı amaç işleme uygulamalarını dahil etmeyi aktif olarak seçmelidir.

Bu etkinleştirme yaklaşımı, mevcut daha az güvenli amaç çözümleme davranışına bağlı olabilecek mevcut uygulamaların bozulma riskini en aza indirir.

Android 16'daki ilk etkisi sınırlı olsa da Safer Intents girişimi, gelecekteki Android sürümlerinde daha geniş bir etki yaratacak bir yol haritasına sahiptir. Nihayetinde katı amaç çözümlemeyi varsayılan davranış haline getirmek planlanmaktadır.

Daha Güvenli Amaçlar özelliği, kötü amaçlı uygulamaların amaç çözümleme mekanizmasındaki güvenlik açıklarından yararlanmasını zorlaştırarak Android ekosisteminin güvenliğini önemli ölçüde artırabilir.

Ancak mevcut uygulamalarla ilgili olası uyumluluk sorunlarını gidermek için devre dışı bırakma ve zorunlu yaptırım geçişi dikkatli bir şekilde yönetilmelidir.

Uygulama

Geliştiricilerin, uygulama manifestlerinde intentMatchingFlags özelliğini kullanarak daha katı amaç eşleşmesini açıkça etkinleştirmesi gerekir. Özelliğin uygulamanın tamamı için etkinleştirildiği ancak alıcıda devre dışı bırakıldığı/devre dışı bırakma seçeneğinin kullanıldığı bir örneği aşağıda bulabilirsiniz:

<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>

Not: Özellik, <application> etiketinde ve <activity>, <activity-alias>, <receiver>, <service>, <provider> gibi bileşen etiketlerinde de belirtilebilir. Bileşendeki özellik, <application> etiketindeki bilgileri geçersiz kılmak için kullanılabilir.

Desteklenen işaretler hakkında daha fazla bilgi:

İşaret Adı	Açıklama
enforceIntentFilter	Gelen intent'ler için daha katı eşleşme uygular.
yok	Gelen amaçlar için tüm özel eşleşme kurallarını devre dışı bırakır. Birden fazla işaret belirtilirken çakışan değerler, "none" işaretine öncelik verilerek çözülür.
allowNullAction	Eşleşme kurallarını gevşeterek işlem içermeyen niyetlerin eşleşmesine izin verir. Belirli bir davranış elde etmek için "enforceIntentFilter" ile birlikte kullanılacak bu işaret

Test ve Hata Ayıklama

Yaptırım etkin olduğunda, niyet çağıran niyeti düzgün şekilde doldurmuşsa uygulamalar doğru şekilde çalışır. Ancak engellenen amaçlar, "Intent does not match component's intent filter:" ve "Access blocked:" gibi uyarı günlüğü mesajlarını "PackageManager." etiketiyle tetikler."PackageManager." Bu, uygulamayı etkileyebilecek olası bir soruna işaret eder ve dikkat gerektirir.

Logcat filtresi:

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

GPU sistem çağrısı filtreleme

Mali GPU yüzeyini sağlamlaştırmak için kullanımdan kaldırılan veya yalnızca GPU geliştirmesi için tasarlanan Mali GPU IOCTL'leri üretim derlemelerinde engellenmiştir. Ayrıca, GPU profil oluşturma için kullanılan IOCTL'ler kabuk işlemi veya hata ayıklanabilir uygulamalarla sınırlandırılmıştır. Platform düzeyindeki politika hakkında daha fazla bilgi için SAC güncellemesine bakın.

Bu değişiklik, Mali GPU'yu kullanan Pixel cihazlarda (Pixel 6-9) gerçekleşir. Arm, r54p2 sürümündeki Documentation/ioctl-categories.rst dosyasında IOCTL'lerinin resmi sınıflandırmasını sağlamıştır. Bu liste, gelecekteki sürücü sürümlerinde güncellenmeye devam edecektir.

Bu değişiklik, desteklenen grafik API'lerini (Vulkan ve OpenGL dahil) etkilemez ve geliştiricileri veya mevcut uygulamaları etkilemesi beklenmez. Streamline Performance Analyzer ve Android GPU Inspector gibi GPU profil oluşturma araçları etkilenmez.

Test

Aşağıdakine benzer bir SELinux reddi görüyorsanız uygulamanız bu değişiklikten etkilenmiş olabilir:

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

Uygulamanızın engellenen IOCTL'leri kullanması gerekiyorsa lütfen hata bildiriminde bulunun ve bildirimi [e-mail] adresine atayın.

SSS

1. Bu politika değişikliği tüm OEM'ler için geçerli mi? Bu değişiklik isteğe bağlı olacak ancak bu sağlamlaştırma yöntemini kullanmak isteyen tüm OEM'ler tarafından kullanılabilecek. Değişikliği uygulama talimatlarını uygulama belgelerinde bulabilirsiniz.

2. Bu özelliği uygulamak için OEM kod tabanında değişiklik yapmak zorunlu mu yoksa bu özellik varsayılan olarak yeni bir AOSP sürümüyle mi geliyor? Platform düzeyindeki değişiklik, varsayılan olarak yeni bir AOSP sürümüyle birlikte gelir. Sağlayıcılar, bu değişikliği uygulamak isterlerse kod tabanlarında etkinleştirebilirler.

3. IOCTL listesinin güncel tutulmasından SoC'ler mi sorumludur? Örneğin, cihazım ARM Mali GPU kullanıyorsa değişiklikler için ARM ile iletişime geçmem gerekir mi? Her SoC, sürücü yayınlandıktan sonra IOCTL listelerini cihaz başına güncellemelidir. Örneğin, ARM, sürücü güncellemesi yaptığında kendisine ait yayınlanmış IOCTL listesini günceller. Ancak OEM'ler, güncellemeleri SEPolicy'lerine dahil ettiklerinden ve gerektiğinde seçilen özel IOCTL'leri listelere eklediklerinden emin olmalıdır.

4. Bu değişiklik, piyasada bulunan tüm Pixel cihazlara otomatik olarak mı uygulanır yoksa kullanıcının bir ayarı etkinleştirmesi mi gerekir? Bu değişiklik, Mali GPU'yu kullanan tüm Pixel cihazlar için geçerlidir (Pixel 6-9). Bu değişikliğin uygulanması için kullanıcı işlemi gerekmez.

5. Bu politikanın kullanılması çekirdek sürücüsünün performansını etkiler mi? Bu politika, GFXBench kullanılarak Mali GPU'da test edilmiş ve GPU performansında ölçülebilir bir değişiklik gözlemlenmemiştir.

6. IOCTL listesinin mevcut kullanıcı alanı ve çekirdek sürücüsü sürümleriyle uyumlu olması gerekir mi? Evet, izin verilen IOCTL'lerin listesi hem kullanıcı alanı hem de çekirdek sürücüleri tarafından desteklenen IOCTL'lerle senkronize edilmelidir. Kullanıcı alanındaki veya çekirdek sürücüsündeki IOCTL'ler güncellenirse SEPolicy IOCTL listesinin de eşleşecek şekilde güncellenmesi gerekir.

7. ARM, IOCTL'leri "kısıtlanmış" / "enstrümantasyon" olarak sınıflandırdı ancak bazılarını üretim kullanım alanlarında kullanmak ve/veya diğerlerini reddetmek istiyoruz. Kullanıcı alanı Mali kitaplıklarının yapılandırmasına bağlı olarak, kullandıkları IOCTL'leri nasıl sınıflandıracaklarına karar vermek OEM/SoC'lerin sorumluluğundadır. Bu konuda karar vermenize yardımcı olması için ARM'nin listesini kullanabilirsiniz ancak her OEM/SoC'nin kullanım alanı farklı olabilir.

Gizlilik

Android 16 (API düzeyi 36) aşağıdaki gizlilik değişikliklerini içerir.

Yerel Ağ İzni

LAN'daki cihazlara, INTERNET iznine sahip tüm uygulamalar erişebilir. Bu, uygulamaların yerel cihazlara bağlanmasını kolaylaştırır ancak kullanıcının parmak izini oluşturma ve konum için proxy olma gibi gizlilik etkileri de vardır.

Yerel Ağ Korumaları projesi, yerel ağa erişimi yeni bir çalışma zamanı izniyle sınırlayarak kullanıcının gizliliğini korumayı amaçlar.

Yayın planı

Bu değişiklik, sırasıyla 25Q2 ve 26Q2 olmak üzere iki sürüm arasında uygulanacaktır. Geliştiricilerin 25Q2 için bu yönergelere uyması ve geri bildirim paylaşması zorunludur. Çünkü bu korumalar daha sonraki bir Android sürümünde zorunlu kılınacaktır. Ayrıca, aşağıdaki yönergeleri kullanarak örtülü yerel ağ erişimine bağlı senaryoları güncellemeleri ve kullanıcıların yeni izni reddetmesine ve iptal etmesine hazırlanmaları gerekir.

Etki

LNP, şu anki aşamada etkinleştirilmesi gereken bir özelliktir. Bu nedenle, yalnızca etkinleştirilen uygulamalar etkilenir. Katılma aşamasının amacı, uygulama geliştiricilerin uygulamalarının hangi bölümlerinin örtülü yerel ağ erişimine bağlı olduğunu anlamalarını sağlamaktır. Böylece, bir sonraki sürümde bu bölümler için izin koruması hazırlayabilirler.

Uygulamalar, kullanıcının yerel ağına aşağıdaki yöntemlerle erişirse etkilenir:

• Yerel ağ adreslerinde (ör. mDNS veya SSDP hizmeti keşif protokolü) ham soketlerin doğrudan veya kitaplık aracılığıyla kullanımı
• Yerel ağa erişen çerçeve düzeyindeki sınıfların (ör. NsdManager) kullanılması

Yerel ağ adresine giden ve gelen trafik için yerel ağ erişimi izni gerekir. Aşağıdaki tabloda sık rastlanan bazı durumlar listelenmiştir:

Uygulama Düşük Düzeyli Ağ İşlemi	Yerel Ağ İzni Gerekli
Giden TCP bağlantısı oluşturma	evet
Gelen TCP bağlantılarını kabul etme	evet
UDP tek noktaya yayın, çok noktaya yayın veya yayın gönderme	evet
Gelen UDP tek yayını, çoklu yayını ve yayını alma	evet

Bu kısıtlamalar, ağ yığınına derinlemesine uygulanır ve bu nedenle tüm ağ API'leri için geçerlidir. Yerel veya yönetilen kodda oluşturulan soketler, Cronet ve OkHttp gibi ağ kitaplıkları ve bunların üzerinde uygulanan tüm API'ler buna dahildir. Yerel ağdaki hizmetleri (ör. .local soneki olanlar) çözmeye çalışmak için yerel ağ izni gerekir.

Not: Yerel ağ erişimi gerektiren Android web görünümlerinden kaynaklanan trafik, izin durumunu barındıran uygulamadan devralır.

Yukarıdaki kurallarla ilgili istisnalar:

• Bir cihazın DNS sunucusu yerel ağdaysa bu cihaza veya bu cihazdan gelen trafik (53 numaralı bağlantı noktasında) için yerel ağ erişim izni gerekmez.
• Uygulama içi seçici olarak Çıkış Değiştirici'yi kullanan uygulamaların yerel ağ izinlerine ihtiyacı olmayacak (2025'in 4. çeyreğinde daha fazla bilgi paylaşılacak).

Not: Birçok medya yayını senaryosu yerel ağa erişime bağlıdır ve bu değişiklikten etkilenir. Ancak yayınlama özelliği sunan tüm uygulamaların yeni izni istemesi gerekmeyecektir. Gelecekteki API'ler ve yayın senaryolarıyla ilgili rehberlik 2025'in 4. çeyreğinde sağlanacaktır.

Geliştirici Kılavuzu (Etkinleştirme)

Yerel ağ kısıtlamalarını etkinleştirmek için aşağıdakileri yapın:

1. Cihazda 25Q2 Beta 3 veya sonraki bir sürümü yükleyin.
2. Test edilecek uygulamayı yükleyin.

3. adb'de Appcompat işaretini açın/kapatın:

   adb shell am compat enable RESTRICT_LOCAL_NETWORK <package_name>
   

4. Cihazı yeniden başlatın

Artık uygulamanızın yerel ağa erişimi kısıtlanmıştır ve yerel ağa erişme girişimleri soket hatalarına yol açar. Uygulama sürecinizin dışında yerel ağ işlemleri gerçekleştiren API'ler (ör. NsdManager) kullanıyorsanız bu API'ler, kayıt aşamasında etkilenmez.

Erişimi geri yüklemek için uygulamanıza NEARBY_WIFI_DEVICES izni vermeniz gerekir.

1. Uygulamanın, manifest dosyasında NEARBY_WIFI_DEVICES iznini beyan ettiğinden emin olun.
2. Ayarlar > Uygulamalar > [Uygulama Adı] > İzinler > Yakındaki cihazlar > İzin ver'e gidin.

Not: Bu özellik, gelecekteki bir Android sürümünde Yakındaki cihazlar izin grubundaki yeni bir izinle korunacaktır

Uygulamanızın yerel ağa erişimi geri yüklenir ve tüm senaryolarınız, uygulamayı kaydetmeden önceki gibi çalışır.

Yerel ağ koruması zorunlu kılındıktan sonra uygulama ağ trafiği şu şekilde etkilenecek:

İzin	Giden LAN İsteği	Giden/Gelen İnternet İsteği	Gelen LAN İsteği
Verildi	Works	Works	Works
İzin Verilmedi	Başarısızlar	Works	Başarısızlar

Uygulama uyumluluğu işaretini devre dışı bırakmak için aşağıdaki komutu kullanın.

adb shell am compat disable RESTRICT_LOCAL_NETWORK <package_name>

Hatalar

Bu kısıtlamalardan kaynaklanan hatalar, yerel bir ağ adresine gönderme veya gönderme varyantı çağrıldığında arayan sokete döndürülür.

Örnek hatalar:

sendto failed: EPERM (Operation not permitted)

sendto failed: ECONNABORTED (Operation not permitted)

Yerel Ağ Tanımı

Bu projedeki yerel ağ, kablosuz veya Ethernet gibi yayın yapabilen bir ağ arayüzünü kullanan bir IP ağıdır ancak hücresel (WWAN) veya VPN bağlantıları hariçtir.

Aşağıdakiler yerel ağ olarak kabul edilir:

IPv4:

• 169.254.0.0/16 // Bağlantı Yerel
• 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:

• Bağlantı yerel
• Doğrudan bağlı rotalar
• Thread gibi saplama ağlar
• Birden fazla alt ağ (henüz belli değil)

Ayrıca, hem çok noktalı yayın adresleri (224.0.0.0/4, ff00::/8) hem de IPv4 yayın adresi (255.255.255.255) yerel ağ adresleri olarak sınıflandırılır.

Uygulamaya ait fotoğraflar

Android 16 veya sonraki sürümleri çalıştıran cihazlarda SDK 36 veya sonraki sürümleri hedefleyen bir uygulama tarafından fotoğraf ve video izinleri istendiğinde, seçili medyaya erişimi sınırlamayı seçen kullanıcılar, uygulamaya ait tüm fotoğrafları fotoğraf seçicide önceden seçili olarak görür. Kullanıcılar önceden seçilmiş öğelerden herhangi birinin seçimini kaldırabilir. Bu durumda uygulamanın söz konusu fotoğraf ve videolara erişimi iptal edilir.