Mudanças de comportamento: todos os apps

A plataforma Android 15 inclui mudanças de comportamento que podem afetar seu app. As mudanças de comportamento a seguir se aplicam a todos os apps quando executados no Android 15, independente de targetSdkVersion. Teste seu app e modifique-o conforme necessário para ficar compatível com essas mudanças, se necessário.

Consulte também a lista de mudanças de comportamento que afetam apenas os apps destinados ao Android 15.

Funcionalidade principal

O Android 15 modifica ou expande vários recursos principais do sistema Android.

Mudanças no estado interrompido do pacote

A intenção do estado FLAG_STOPPED do pacote (que os usuários podem acionar em builds do AOSP pressionando um ícone de app por muito tempo e selecionando "Forçar Parar") sempre foi manter os apps nesse estado até que o usuário os remova explicitamente, iniciando o app diretamente ou interagindo indiretamente com ele (pela sharesheet ou um widget, selecionando o app como papel de parede animado etc.). No Android 15, atualizamos o comportamento do sistema para estar alinhado com esse comportamento pretendido. Os apps só podem ser removidos do estado de interrupção por uma ação direta ou indireta do usuário.

Para oferecer suporte ao comportamento pretendido, além das restrições atuais, o sistema também cancela todas as intenções pendentes quando o app entra no estado parado em um dispositivo com o Android 15. Quando as ações do usuário removem o app do estado parado, a transmissão ACTION_BOOT_COMPLETED é enviada ao app, oferecendo a oportunidade de registrar novamente todas as intents pendentes.

Observação: os apps usam intents pendentes para atualizar os widgets do app. Se um app entrar no estado parado, todas as intents pendentes serão canceladas, e o sistema desativará os widgets do app. Os widgets estão esmaecidos, e o usuário do dispositivo não pode interagir com eles. O sistema reativa os widgets na próxima vez que o usuário abrir o app.

Chame o novo método ApplicationStartInfo.wasForceStopped() para confirmar se o app foi colocado no estado parado.

Suporte a tamanhos de página de 16 KB

从历史上看，Android 仅支持 4 KB 内存页面大小，这优化了系统内存性能，以适应 Android 设备通常拥有的平均总内存量。从 Android 15 开始，AOSP 支持配置为使用 16 KB 页面大小的设备（16 KB 设备）。如果您的应用直接或通过 SDK 间接使用任何 NDK 库，则需要重新构建应用，才能在这些 16 KB 设备上运行。

随着设备制造商不断制造出具有更大物理内存 (RAM) 的设备，许多此类设备将采用 16 KB（最终甚至更大）的页面大小来优化设备性能。添加对 16 KB 页面大小设备的支持，可让您的应用在这些设备上运行，并帮助您的应用受益于相关的性能改进。如果不重新编译，应用将无法在未来 Android 版本的 16 KB 设备上运行。

为帮助您为应用添加支持，我们提供了相关指南，介绍了如何检查应用是否受到影响、如何重新构建应用（如果适用），以及如何使用模拟器（包括 Android 模拟器的 Android 15 系统映像）在 16 KB 环境中测试应用。

Benefits and performance gains

Os dispositivos configurados com tamanhos de página de 16 KB usam um pouco mais de memória em média, mas também têm várias melhorias de desempenho para o sistema e os apps:

• Tempos de inicialização do app mais rápidos enquanto o sistema está sob pressão de memória: 3,16% mais baixos em média, com melhorias mais significativas (até 30%) em alguns apps testados.
• Redução do consumo de energia durante o lançamento do app: redução média de 4,56%
• Lançamento mais rápido da câmera: 4,48% mais rápido em média e 6,60% mais rápido em média
• Tempo de inicialização do sistema melhorado: melhoria de 8% (aproximadamente 950 milissegundos) em média

Essas melhorias são baseadas nos testes iniciais, e os resultados em dispositivos reais provavelmente serão diferentes. Forneceremos análises adicionais de ganhos em potencial para apps à medida que continuarmos nossos testes.

Check if your app is impacted

Se o app usar código nativo, recompile o app com suporte para dispositivos de 16 KB. Se você não tiver certeza se o app usa código nativo, use o APK Analyzer para identificar se há código nativo e verifique o alinhamento dos segmentos ELF de bibliotecas compartilhadas encontradas. O Android Studio também oferece recursos que ajudam a detectar automaticamente problemas de alinhamento.

Se o app usa apenas código escrito na linguagem de programação Java ou Kotlin, incluindo bibliotecas ou SDKs, ele já oferece suporte a dispositivos de 16 KB. No entanto, recomendamos que você teste o app em um ambiente de 16 KB para verificar se não há regressões inesperadas no comportamento do app.

Mudanças necessárias para que alguns apps ofereçam suporte ao espaço particular

O espaço privado é um novo recurso do Android 15 que permite aos usuários criar um espaço separado no dispositivo para manter os apps sensíveis longe de olhares curiosos e sob uma camada adicional de autenticação. Como os apps no espaço particular têm visibilidade restrita, alguns tipos de apps precisam seguir outras etapas para poderem ser vistos e interagir com os apps no espaço particular de um usuário.

Todos os apps

Como os apps no espaço pessoal são mantidos em um perfil de usuário separado, semelhante aos perfis de trabalho, os apps não podem presumir que as cópias instaladas do app que não estão no perfil principal estão no perfil de trabalho. Se o app tiver uma lógica relacionada a apps de perfil de trabalho que fazem essa suposição, você precisará ajustar essa lógica.

Apps de medicina

Quando um usuário bloqueia o espaço particular, todos os apps nele são interrompidos e não podem realizar atividades em primeiro ou segundo plano, incluindo a exibição de notificações. Esse comportamento pode afetar significativamente o uso e a função de apps médicos instalados no espaço privado.

A experiência de configuração do espaço privado alerta os usuários de que ele não é adequado para apps que precisam realizar atividades importantes em primeiro ou segundo plano, como mostrar notificações de apps médicos. No entanto, os apps não podem determinar se estão sendo usados no espaço particular, portanto, não podem mostrar um aviso ao usuário nesse caso.

Por esses motivos, se você desenvolve um app médico, analise como esse recurso pode afetar seu app e tome as medidas adequadas, como informar aos usuários para não instalar o app no espaço privado, para evitar interromper os recursos essenciais do app.

Apps da tela de início

Se você desenvolver um app de tela de início, faça o seguinte antes que os apps no espaço privado fiquem visíveis:

1. Seu app precisa ser atribuído como o app de inicialização padrão do dispositivo, ou seja, ter o papel de ROLE_HOME.
2. O app precisa declarar a permissão normal ACCESS_HIDDEN_PROFILES no arquivo de manifesto do app.

Os apps de inicialização que declaram a permissão ACCESS_HIDDEN_PROFILES precisam processar os seguintes casos de uso do espaço privado:

1. O app precisa ter um contêiner de inicialização separado para apps instalados no espaço privado. Use o método getLauncherUserInfo() para determinar qual tipo de perfil de usuário está sendo processado.
2. O usuário precisa poder ocultar e mostrar o contêiner de espaço privado.
3. O usuário precisa poder bloquear e desbloquear o contêiner do espaço privado. Use o método requestQuietModeEnabled() para bloquear (transmitindo true) ou desbloquear (transmitindo false) o espaço privado.

4. Enquanto estiver bloqueado, nenhum app no contêiner do espaço privado poderá ser visível ou detectável por mecanismos como a pesquisa. O app precisa registrar um receptor para as transmissões ACTION_PROFILE_AVAILABLE e ACTION_PROFILE_UNAVAILABLE e atualizar a interface quando o estado bloqueado ou desbloqueado do contêiner do espaço privado mudar. Ambas as transmissões incluem EXTRA_USER, que o app pode usar para se referir ao usuário do perfil privado.

   Também é possível usar o método isQuietModeEnabled() para verificar se o perfil do espaço particular está bloqueado ou não.

Apps da app store

O espaço privado inclui um botão "Instalar apps" que inicia uma intent implícita para instalar apps no espaço privado do usuário. Para que o app receba essa intent implícita, declare uma <intent-filter> no arquivo de manifesto do app com uma <category> de CATEGORY_APP_MARKET.

Fonte de emoji baseada em PNG removida

The legacy, PNG-based emoji font file (NotoColorEmojiLegacy.ttf) has been removed, leaving just the vector-based file. Beginning with Android 13 (API level 33), the emoji font file used by the system emoji renderer changed from a PNG-based file to a vector based file. The system retained the legacy font file in Android 13 and 14 for compatibility reasons, so that apps with their own font renderers could continue to use the legacy font file until they were able to upgrade.

To check if your app is affected, search your app's code for references to the NotoColorEmojiLegacy.ttf file.

You can choose to adapt your app in a number of ways:

• Use platform APIs for text rendering. You can render text to a bitmap-backed Canvas and use that to get a raw image if necessary.
• Add COLRv1 font support to your app. The FreeType open source library supports COLRv1 in version 2.13.0 and higher.
• As a last resort, you can bundle the legacy emoji font file (NotoColorEmoji.ttf) into your APK, although in that case your app will be missing the latest emoji updates. For more information, see the Noto Emoji GitHub project page.

A versão mínima do SDK de destino foi aumentada de 23 para 24

Android 15 builds on the the changes that were made in Android 14 and extends this security further. In Android 15, apps with a targetSdkVersion lower than 24 can't be installed. Requiring apps to meet modern API levels helps to ensure better security and privacy.

Malware often targets lower API levels in order to bypass security and privacy protections that have been introduced in higher Android versions. For example, some malware apps use a targetSdkVersion of 22 to avoid being subjected to the runtime permission model introduced in 2015 by Android 6.0 Marshmallow (API level 23). This Android 15 change makes it harder for malware to avoid security and privacy improvements. Attempting to install an app targeting a lower API level results in an installation failure, with a message like the following one appearing in Logcat:

INSTALL_FAILED_DEPRECATED_SDK_VERSION: App package must target at least SDK version 24, but found 7

On devices upgrading to Android 15, any apps with a targetSdkVersion lower than 24 remain installed.

If you need to test an app targeting an older API level, use the following ADB command:

adb install --bypass-low-target-sdk-block FILENAME.apk

Segurança e privacidade

Android 15 introduces robust measures to combat one-time passcode (OTP) fraud and to protect the user's sensitive content, focusing on hardening the Notification Listener Service and screenshare protections. Key enhancements include redacting OTPs from notifications accessible to untrusted apps, hiding notifications during screenshare, and securing app activities when OTPs are posted. These changes aim to keep the user's sensitive content safe from unauthorized actors.

Developers need to be aware of the following to ensure their apps are compatible with the changes in Android 15:

OTP Redaction

Android will stop untrusted apps that implement a NotificationListenerService from reading unredacted content from notifications where an OTP has been detected. Trusted apps such as companion device manager associations are exempt from these restrictions.

Screenshare Protection

• Notification content is hidden during screen sharing sessions to preserve the user's privacy. If the app implements setPublicVersion(), Android shows the public version of the notification which serves as a replacement notification in insecure contexts. Otherwise, the notification content is redacted without any further context.
• Sensitive content like password input is hidden from remote viewers to prevent revealing the user's sensitive information.
• Activities from apps that post notifications during screenshare where an OTP has been detected will be hidden. App content is hidden from the remote viewer when launched.
• Beyond Android's automatic identification of sensitive fields, developers can manually mark parts of their app as sensitive using setContentSensitivity, which is hidden from remote viewers during screenshare.
• Developers can choose to toggle the Disable screen share protections option under Developer Options to be exempted from the screenshare protections for demo or testing purposes. The default system screen recorder is exempted from these changes, since the recordings remain on-device.

Câmera e mídia

O Android 15 faz as seguintes mudanças no comportamento da câmera e da mídia para todos os apps.

A reprodução de áudio direta e descarregada invalida as faixas de áudio diretas ou descarregadas abertas anteriormente quando os limites de recursos são atingidos

Antes do Android 15, se um app solicitasse a reprodução de áudio direta ou de transferência enquanto outro app estava reproduzindo áudio e os limites de recursos fossem alcançados, o app não conseguiria abrir uma nova AudioTrack.

A partir do Android 15, quando um app solicita a reprodução direta ou de descarga e os limites de recurso são alcançados, o sistema invalida todos os objetos AudioTrack abertos que impedem o atendimento da nova solicitação de faixa.

As faixas de áudio diretas e de transferência geralmente são abertas para a reprodução de formatos de áudio compactados. Os casos de uso comuns para a reprodução de áudio direto incluem o streaming de áudio codificado por HDMI para uma TV. As faixas de transferência são geralmente usadas para reproduzir áudio compactado em um dispositivo móvel com aceleração de DSP de hardware.

Experiência do usuário e interface do sistema

O Android 15 inclui algumas mudanças que têm como objetivo criar uma experiência do usuário mais consistente e intuitiva.

Animações de gestos "Voltar" preditivos ativadas para apps que fizeram a adesão

A partir do Android 15, a opção para desenvolvedores de animações de volta preditiva foi removida. Animações do sistema, como voltar à tela inicial, entre tarefas e atividades, agora aparecem para apps que ativaram o gesto de volta preditivo inteiramente ou em um nível de atividade. Se o app for afetado, realize as seguintes ações:

• Confira se o app foi migrado corretamente para usar o gesto de volta previsivo.
• Verifique se as transições de fragmentos funcionam com a navegação de volta preditiva.
• Migrar de animações e transições de framework e usar animações e transições do androidx.
• Migração de backstacks que FragmentManager não conhece. Use backstacks gerenciadas por FragmentManager ou pelo componente de navegação.

Widgets desativados quando o usuário força a interrupção de um app

If a user force-stops an app on a device running Android 15, the system temporarily disables all the app's widgets. The widgets are grayed out, and the user cannot interact with them. This is because beginning with Android 15, the system cancels all an app's pending intents when the app is force-stopped.

The system re-enables those widgets the next time the user launches the app.

For more information, see Changes to package stopped state.

O chip da barra de status de projeção de mídia alerta os usuários sobre o compartilhamento, a transmissão e a gravação de tela

Note: This change is included on devices running Android 15 QPR1 or higher.

As explorações de projeção de tela expõem dados privados do usuário, como informações financeiras, porque os usuários não percebem que a tela do dispositivo está sendo compartilhada.

Para apps executados em dispositivos com o Android 15 QPR1 ou mais recente, um ícone grande e visível na barra de status alerta os usuários sobre qualquer projeção de tela em andamento. Os usuários podem tocar no ícone para impedir que a tela seja compartilhada, transmitida ou gravada. Além disso, a projeção da tela é interrompida automaticamente quando a tela do dispositivo é bloqueada.

Bloco da barra de status para compartilhamento de tela, transmissão e gravação.

Check if your app is impacted

By default, your app includes the status bar chip and automatically suspends screen projection when the lock screen activates.

To learn more about how to test your app for these use cases, see Status bar chip and auto stop.

Restrições de acesso à rede em segundo plano

No Android 15, os apps que iniciam uma solicitação de rede fora de um ciclo de vida de processo válido recebem uma exceção. Normalmente, um UnknownHostException ou outro IOException relacionado ao soquete. As solicitações de rede que acontecem fora de um ciclo de vida válido geralmente são devido a apps que continuam uma solicitação de rede sem saber, mesmo depois que o app não está mais ativo.

Para reduzir essa exceção, use componentes com reconhecimento de ciclo de vida para garantir que as solicitações de rede tenham reconhecimento de ciclo de vida e sejam canceladas ao sair de um ciclo de vida de processo válido. Se for importante que a solicitação de rede aconteça mesmo quando o usuário sair do aplicativo, programe a solicitação de rede usando o WorkManager ou continue uma tarefa visível para o usuário usando o Serviço em primeiro plano.

Suspensões de uso

A cada versão, algumas APIs específicas do Android podem se tornar obsoletas ou precisarem ser refatoradas para fornecer uma melhor experiência aos desenvolvedores ou oferecer suporte a novos recursos da plataforma. Nesses casos, descontinuamos oficialmente as APIs obsoletas e direcionamos os desenvolvedores para APIs alternativas.

Descontinuação significa que encerramos o suporte oficial para as APIs, mas elas continuarão disponíveis para os desenvolvedores. Para saber mais sobre as descontinuações importantes nesta versão do Android, consulte a página de descontinuações.