Você provavelmente já ouviu alguma conversa sobre o root e a versão mais recente do Android, e talvez até tenha ouvido coisas como "a morte do root". As coisas mudaram e os novos recursos de segurança do Android agora limitam o que os processos com privilégios de superusuário podem fazer na partição do sistema. Vou tentar explicar o melhor possível, sem dar muitas palavras que ninguém (bem, quase ninguém) entenderá. Alguns são inevitáveis, no entanto.
Você pode precisar derramar um rígido para isso.
Todos os aplicativos Android se baseiam em um processo do sistema conhecido como zigoto. No Android 4.3, as coisas foram alteradas e agora o zygote tem uma nova política de segurança. Mesmo que possamos dividir um processo com privilégios suid (superusuário), as novas restrições limitam o que podemos fazer com ele. Esse é o objetivo do SELinux, que é uma coisa boa para a segurança do usuário. Nosso novo processo (pense nele como o aplicativo raiz que você está tentando executar) tecnicamente tem acesso root, mas na verdade não pode fazer nada de útil. Essa é uma maneira muito boa de proteger o sistema de processos não autorizados que você não deseja - como no ZOMGMALWARE em potencial - tenha acesso a tudo.
Há duas maneiras de abordar esse novo conjunto de políticas de segurança. Uma é que o acesso root através do shell - onde você conectou o telefone a um computador e usa a linha de comando para se comunicar - ainda funciona bem. Você pode elevar seu status de usuário e fazer as mesmas coisas que você sempre poderia fazer através do adb. E as chances são muito pequenas que não acontecerão sem que você saiba.
A outra maneira é com um daemon su.
Um daemon é um processo em segundo plano que não está sob controle direto do usuário ativo. Ele roda silenciosamente, aguardando o tempo necessário para fazer algo útil. Quando é chamado, ele faz o que foi projetado para fazer e depois se esconde. Um daemon su precisa ser chamado durante a inicialização do sistema, que se torna um ponto de atrito para invadir o acesso root nas ROMs "padrão".
A implementação do Android fornecida com o Nexus não procura políticas adicionais em / data / system / sepolicy, como o CyanogenMod e o upstream, indicando que deveria. Ele carrega o arquivo / sepolicy do ramdisk e o chama por dia.
+ Koushik Dutta
Você precisa, no mínimo, de uma imagem de inicialização modificada para iniciar um daemon personalizado no seu dispositivo Android. Isso não é um problema com algo como o CyanogenMod, mas isso significa que você está exibindo algo diferente do estoque para fazer isso acontecer. Imagens personalizadas, kernels e ROMs intermitentes são algo que muitas pessoas simplesmente não querem fazer.
Então é onde estamos. Os maiores nomes da comunidade Android trabalham duro para organizar tudo, mas há uma chance muito boa de que a raiz, do jeito que você conhece hoje, exigirá que você atualize o firmware personalizado acima e além do aplicativo SU e do binário. É bom que o Android esteja migrando para um modelo de segurança mais seguro, e você terá que aprender um pouco mais sobre como o sistema funciona e como modificá-lo para obtê-lo na condição desejada - o que no final é outra coisa boa.
O Google sabe que os usuários querem coisas como permissões de superusuário. Há uma chance muito boa de que eles resolvam esses problemas de alguma forma, seja exigindo raiz para menos coisas ou criando uma solução no próprio Android. Se você executa o Linux ou OSX no seu computador, sabe que ter uma pasta pessoal permite fazer a maioria das coisas sem elevar nenhuma permissão. Talvez o Google vá nessa direção. Ou talvez eles adicionem funções de superusuário ao Android nas opções do desenvolvedor. Enquanto isso, eles continuarão a fabricar telefones Nexus totalmente desbloqueáveis para usuários que desejam ou precisam atualizar o firmware personalizado - e pessoas como os desenvolvedores do CyanogenMod (e de outros lugares) continuarão a construí-lo.
