O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Usando Binder IPC

Esta página descreve as mudanças no driver do fichário no Android 8, fornece detalhes sobre o uso do IPC do fichário e lista a política SELinux necessária.

Mudanças no driver do fichário

A partir do Android 8, a estrutura do Android e os HALs agora se comunicam usando o fichário. Como essa comunicação aumenta drasticamente o tráfego do fichário, o Android 8 inclui várias melhorias projetadas para manter o IPC do fichário rápido. SoC fornecedores e OEMs deve se fundir diretamente dos principais ramos da android-4.4, android-4.9 e superior do kernel / comum projeto.

Vários domínios de fichário (contextos)

Common-4.4 e superior, incluindo upstream

Para dividir corretamente o tráfego de aglutinante entre framework de código (específico do dispositivo) (independente dispositivo) e vendedor, Android 8 introduziu o conceito de um contexto aglutinante. Cada contexto de fichário tem seu próprio nó de dispositivo e seu próprio gerenciador de contexto (serviço). Você pode acessar o gerenciador de contexto apenas através do nó do dispositivo ao qual ele pertence e, ao passar um nó do binder por um determinado contexto, ele é acessível a partir desse mesmo contexto apenas por outro processo, isolando assim completamente os domínios uns dos outros. Para detalhes sobre a utilização, consulte vndbinder e vndservicemanager .

Scatter-reunir

Common-4.4 e superior, incluindo upstream

Nas versões anteriores do Android, todos os dados em uma chamada de fichário eram copiados três vezes:

  • Uma vez que para serializar-lo em um Parcel no processo de chamada
  • Uma vez na driver de kernel para copiar o Parcel para o processo de destino
  • Uma vez que a unserialize o Parcel no processo de destino

Android 8 usos reunidas por dispersão de otimização para reduzir o número de cópias de 3 a 1. Em vez de serialização de dados em um Parcel em primeiro lugar, restos de dados em seu layout e estrutura de memória original eo motorista imediatamente copia para o processo de destino. Depois que os dados estão no processo de destino, a estrutura e o layout da memória são os mesmos e os dados podem ser lidos sem a necessidade de outra cópia.

Travamento refinado

Common-4.4 e superior, incluindo upstream

Em versões anteriores do Android, o driver do binder usava um bloqueio global para proteger contra o acesso simultâneo a estruturas de dados críticas. Embora houvesse contenção mínima para o bloqueio, o principal problema era que se um encadeamento de baixa prioridade obtivesse o bloqueio e fosse interrompido, ele poderia atrasar seriamente os encadeamentos de alta prioridade que precisavam obter o mesmo bloqueio. Isso causou solavanco na plataforma.

As tentativas iniciais de resolver esse problema envolviam a desativação da preempção enquanto mantinha o bloqueio global. No entanto, isso foi mais um hack do que uma solução verdadeira, e acabou sendo rejeitado pelo upstream e descartado. As tentativas subsequentes se concentraram em tornar o bloqueio mais refinado, uma versão que está em execução em dispositivos Pixel desde janeiro de 2017. Embora a maioria dessas alterações tenha sido tornada pública, melhorias substanciais foram feitas nas versões subsequentes.

Depois de identificar pequenos problemas na implementação de bloqueio de baixa granularidade, criamos uma solução aprimorada com uma arquitetura de bloqueio diferente e enviamos as alterações em todos os ramos comuns do kernel. Continuamos testando essa implementação em um grande número de dispositivos diferentes; como não temos conhecimento de quaisquer problemas pendentes, esta é a implementação recomendada para dispositivos que vêm com Android 8.

Herança de prioridade em tempo real

Common-4.4 e common-4.9 (upstream em breve)

O driver do fichário sempre suportou uma boa herança de prioridade. Como um número crescente de processos no Android é executado em prioridade em tempo real, em alguns casos agora faz sentido que, se um encadeamento em tempo real fizer uma chamada de fichário, o encadeamento no processo que lida com essa chamada também será executado em prioridade em tempo real . Para oferecer suporte a esses casos de uso, o Android 8 agora implementa a herança de prioridade em tempo real no driver do fichário.

Além de herança de prioridade no nível da transação, herança de prioridade nó permite que um nó (aglutinante objeto de serviço) para especificar uma prioridade mínima em que chamadas para este nó deve ser executado. As versões anteriores do Android já suportavam a herança de prioridade de nó com bons valores, mas o Android 8 adiciona suporte para herança de nó de políticas de agendamento em tempo real.

Mudanças no espaço do usuário

Android 8 inclui todos userspace mudanças necessárias para o trabalho com o driver pasta atual no kernel comum com uma exceção: A implementação original para desativar a herança de prioridade em tempo real para /dev/binder utilizado um ioctl . O desenvolvimento subsequente mudou o controle de herança de prioridade para um método mais refinado que é por modo de fichário (e não por contexto). Assim, o ioctl não está no ramo comum Android e em vez disso é apresentado em nossos kernels comuns .

O efeito desta mudança é que a herança de prioridade em tempo real está desabilitada por padrão para cada nó. A equipe de desempenho do Android descobriu que é benéfico para permitir herança de prioridade em tempo real para todos os nós no hwbinder domínio. Para conseguir esse mesmo efeito, cereja-escolher esta mudança no espaço do usuário.

SHAs para kernels comuns

Para obter as alterações necessárias no driver do fichário, sincronize com o SHA apropriado:

  • Common-3.18
    cc8b90c121de ANDROID: fichário: não verifica as permissões de prio ao restaurar.
  • Common-4.4
    76b376eac7a2 ANDROID: fichário: não verifica as permissões prio na restauração.
  • Comum-4.9
    ecd972d4f9b5 ANDROID: binder: não verifica as permissões prio na restauração.

Usando aglutinante IPC

Historicamente, os processos do fornecedor têm usado a comunicação entre processos do binder (IPC) para se comunicar. Em Android 8, o /dev/binder nó de dispositivo torna-se exclusiva para processos de enquadramento, ou seja, processos de fornecedores já não têm acesso a ele. Processos de fornecedor pode acessar /dev/hwbinder , mas deve converter suas interfaces AIDL ao uso HIDL. Para fornecedores que desejam continuar usando interfaces AIDL entre processos de fornecedores, o Android oferece suporte a IPC de fichário conforme descrito abaixo.

vndbinder

Android 8 suporta um novo domínio ligante para uso por serviços de fornecedores, acessado usando /dev/vndbinder em vez de /dev/binder . Com a adição de /dev/vndbinder , Android agora tem os seguintes três domínios IPC:

Domínio IPC Descrição
/dev/binder IPC entre processos de framework / aplicativo com interfaces AIDL
/dev/hwbinder IPC entre processos de estrutura / fornecedor com interfaces HIDL
IPC entre os processos do fornecedor com interfaces HIDL
/dev/vndbinder IPC entre fornecedores / processos de fornecedores com interfaces AIDL

Para /dev/vndbinder a aparecer, assegure o item de configuração do kernel CONFIG_ANDROID_BINDER_DEVICES está definido como "binder,hwbinder,vndbinder" (este é o padrão em árvores do kernel comuns do Android).

Normalmente, os processos do fornecedor não abrir o driver da pasta directamente e em vez disso ligar contra o libbinder biblioteca userspace, que abre o motorista aglutinante. A adição de um método para a ::android::ProcessState() selecciona o controlador de ligante para libbinder . Processos vendedor deve chamar esse método antes de chamar para ProcessState, IPCThreadState , ou antes de fazer qualquer chamada de ligante em geral. Para usar, coloque a seguinte chamada após o main() de um processo fornecedor (cliente e servidor):

ProcessState::initWithDriver("/dev/vndbinder");

vndservicemanager

Anteriormente, os serviços de encadernação foram registrados servicemanager , onde poderiam ser recuperadas por outros processos. Em Android 8, servicemanager é agora usado exclusivamente por processos de enquadramento e de aplicativos e processos de fornecedores já não pode acessá-lo.

No entanto, os serviços de fornecedores podem agora usar vndservicemanager , uma nova instância do servicemanager que usa /dev/vndbinder em vez de /dev/binder e que é construído a partir das mesmas fontes como quadro servicemanager . Processos vendedor não precisar fazer alterações para falar com vndservicemanager ; quando um processo fornecedor abre / dev/vndbinder , pesquisas de serviço vai automaticamente para vndservicemanager .

O vndservicemanager binário está incluída no makefiles padrão do dispositivo do Android.

Política SELinux

Os processos do fornecedor que desejam usar a funcionalidade de fichário para se comunicarem precisam do seguinte:

  1. Acesso a /dev/vndbinder .
  2. Binder {transfer, call} ganchos em vndservicemanager .
  3. binder_call(A, B) para qualquer domínio Um vendedor que quer pôr em domínio fornecedor B através da interface do fornecedor ligante.
  4. Permissão para {add, find} serviços em vndservicemanager .

Para cumprir os requisitos 1 e 2, use o vndbinder_use() macro:

vndbinder_use(some_vendor_process_domain);

Para cumprir a exigência 3, o binder_call(A, B) para o fornecedor processa A e B que necessidade de falar sobre aglutinante pode ficar no lugar, e não precisa de renomeação.

Para cumprir o requisito 4, você deve fazer alterações na maneira como os nomes de serviço, rótulos de serviço e regras são tratados.

Para mais detalhes sobre o SELinux, consulte Security-Enhanced Linux no Android . Para mais detalhes sobre SELinux no Android 8.0, consulte SELinux para o Android 8.0 .

Nomes de serviço

Anteriormente, os processos de fornecedores registrados nomes de serviços em um service_contexts arquivo e acrescentou regras de acesso que arquivo correspondente. Exemplo service_contexts arquivo de device/google/marlin/sepolicy :

AtCmdFwd                              u:object_r:atfwd_service:s0
cneservice                            u:object_r:cne_service:s0
qti.ims.connectionmanagerservice      u:object_r:imscm_service:s0
rcs                                   u:object_r:radio_service:s0
uce                                   u:object_r:uce_service:s0
vendor.qcom.PeripheralManager         u:object_r:per_mgr_service:s0

Em Android 8, vndservicemanager carrega os vndservice_contexts arquivo em seu lugar. Serviços de fornecedores migrando para vndservicemanager (e que já estão na idade service_contexts arquivo) deve ser adicionado ao novo vndservice_contexts arquivo.

Rótulos de serviço

Anteriormente, serviço de rótulos como u:object_r:atfwd_service:s0 foram definidos em um service.te arquivo. Exemplo:

type atfwd_service,      service_manager_type;

Em Android 8, você deve alterar o tipo de vndservice_manager_type e mover a regra para o vndservice.te arquivo. Exemplo:

type atfwd_service,      vndservice_manager_type;

Regras do Servicemanager

Anteriormente, réguas concedido domínios de acesso para adicionar ou encontrar serviços de servicemanager . Exemplo:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;

No Android 8, essas regras podem permanecer em vigor e usar a mesma classe. Exemplo:

allow atfwd atfwd_service:service_manager find;
allow some_vendor_app atfwd_service:service_manager add;