Emulador do Android SDK no Ubuntu 16 - Resolvido

Recentemente passei por alguns problemas para fazer funcionar o emulador do Android SDK instalado juntamente com o Android Studio 2.3.3 em máquinas Ubuntu de onde trabalho.

Configuração das máquinas:

Intel® Core™ i7 CPU 870 @ 2.93GHz × 8

8GB de RAM

Ubuntu 16.04 64bit

A princípio, uma configuração suficiente pra rodar o Android Studio, mais precisamente o emulador que dava problema. Tanto na minha como nas máquinas de 2 colegas.

Depois de muitas pesquisas na documentação do Android Studio, stackoverflow e outros sites relacionados chegamos à solução do problema.

Problema:

Antes de chegar na questão, passamos por outras situações, tais como a solicitação de instalação do Intel HAXM (Hardware Accelerated Execution Manager) ou KVM (Kernel-based Virtual Machine), configuração de BIOS para habilitar a virtualização do processador, entre outros.

Após pesquisas vimos que era algo bem comum. Com vários relatos, inclusive de casos que funcionavam antes, mas não após o upgrade pra versão 2 do Android Studio.

Após a resolução das configurações iniciais citadas, chegamos num ponto em que o emulador é iniciado, mas dá crash, às vezes logo de início, às vezes no início do carregamento do sistema operacional.

Um das causas do problema parece estar relacionada à interface gráfica Unity, já que vimos soluções em que a mudança para o Mate resolveria, mas não era algo aplicável ao nosso caso.

Cheguei a pensar se o fato de usar um processador Intel de 1ª geração poderia ser complicador também, já que no meu notebook com processador de 5ª geração (i5-5200U) e 8GB de RAM o emulador rodou normalmente.

Solução:

Inicialmente, a CPU precisa suportar uma das seguintes tecnologias de virtualização:

• Intel Virtualization Technology (VT, VT-x, vmx) extensions
• AMD Virtualization (AMD-V, SVM) extensions (Linux only)

A chave de tudo é fazer funcionar o processo de aceleração

1) Aceleração de hardware

Ao usar aceleração de hardware seu emulador deve rodar mais rapidamente, mas o problema que temos é que exatamente por tentar usar isso que o erro ocorre. Muito provavelmente você está usando o driver SL Nouveau. Ele acaba tornando a renderização gráfica mais lenta ou ocasiona o crash.

Solução: atualizar/modificar o driver da placa de vídeo. No meu caso a placa era uma GeForce 8400. Bastou reverter para o driver do fabricante nvidia-340 que já estava até instalado, mas não em uso.

2) Se ainda assim não der certo... usar Aceleração via software

Aceleração via software é útil somente se o computador não dispõe de drivers gráficos compatíveis com o emulador. A imagem do Android deve ser criada definindo a opção Emulated Performance: Graphics como 'Software' para assim não usar a GPU do host. Mesmo com esse procedimento só funcionou a versão Lollipop do Android no nosso caso.

Além disso foram necessários mais alguns comandos:

• Instalação de bibliotecas:

sudo apt-get install lib64stdc++6:i386

sudo apt-get install mesa-utils

• Copiar pastas lib, lib64 e qemu da pasta emulator para tools dentro de $ANDROID_SDK.

• Renomeia pasta:

Na pasta '$ANDROID_SDK/emulator/lib64': 

mv libstdc++/ libstdc++.bak

• Linca pasta do emulador pra pegar as bibliotecas do sistema

Na pasta '$ANDROID_SDK/emulator/lib64': 

ln -s /usr/lib64/libstdc++.so.6 libstdc++

• Para rodar o emulador via linha de comando:

Na pasta '$ANDROID_SDK/tools$:

 ./emulator -list-avds

Na pasta '$ANDROID_SDK/tools$:

 ./emulator -use-system-libs -avd Nexus_5X_API_22

Em alguns casos não precisa do -use-system-libs. Em outros dá pra rodar direto do Android Studio.

Em qualquer dos casos, se prepare que muita memória vai ser consumida. Nem 8GB é o bastante quando uma aplicação está rodando e com navegadores e outros programas abertos.

Observação: você não pode rodar uma VM dentro de outra VM como VirtualBox ou VMWare. Você deve rodar o emulador diretamente do seu hardware.

Bug no Moto G após atualização para Android 6

Há algumas semanas atrás, minha prima me pediu ajuda com um problema que o seu celular Android estava apresentando. Ela tem um Moto G (não lembro se 2ª ou 3ª geração). Após a atualização para o Android 6 ocorria o seguinte:

-Não exibia mais as notificações dos aplicativos. Por exemplo, as mensagens de whatsapp chegavam, mas não aparecia a notificação na parte superior da tela.
-Impossibilidade de restaurar padrões de fábrica (algo que tentamos fazer quando não vimos solução para o problema acima). O botão ficava desabilitado. Aliás, ainda bem que ficava desabilitado, pois evitaria um contratempo maior tendo em vista que a solução é bem rápida.

Solução:

Algo bem simples, mas meio difícil de descobrir. Basta ir em Configurar -> Usuários. Entrar como o usuário Convidado, o que vai fazer imediatamente as notificações surgirem. Depois basta voltar para a sua conta de usuário principal que a exibição de notificações estará normalizada.
Ainda não sei ao certo quais modelos podem apresentar esse problema. No Moto G 2ª geração da minha esposa e no meu Moto X conseguir atualizar para o Android 6 sem problemas.

Operadoras cobrando internet mesmo com o serviço desabilitado no smartphone

Como já é de costume nossas operadoras de telefonia, mais uma vez elas inventam uma nova forma de cobrar dos seus clientes algo que não foi solicitado.

Tenho um plano pós-pago da Oi juntamente com a minha esposa, sendo que somente na linha dela tem internet. Pra usar internet no meu aparelho revezo chips pré-pago da Claro e da TIM. Motivo: a Oi não pega no interior onde meus pais moram e por isso preciso de outras opções para me comunicar com eles gastando menos com tarifas, além de poder receber ligações quando estou por lá. Interessante que na região em que eles vivem quando a Claro apresenta um bom sinal, o sinal da TIM piora, mas isso já é outra história. Enfim, não vale a pena pra mim fechar outro plano pós-pago, por isso prefiro continuar com o pré-pago.

O problema: De uns tempos pra cá, a Claro tem cobrado a tarifa diária (pré-pago) de internet mesmo nos casos em que o serviço está desabilitado no smartphone. Percebi que todo dia pela manhã ocorria o desconto de R$0,99, usando ou não a internet. Em outras palavras, você vai gastar R$30 por mês, esteja usando a internet ou não. Pelo que pesquisei na internet, a TIM parece fazer o mesmo, mas não ocorreu comigo.

A solução: Pelo menos no caso da Claro, percebi que a cobrança se devia ao fato do 4G estar habilitado no aparelho na opção Redes Preferenciais. Basta então, sempre que não for usar a internet, colocar 3G como rede preferencial, além de desativar o tráfego de dados. No Moto X, você deve entrar em Configurações -> Redes -> Redes celulares -> Tipo de rede preferencial. Fazendo isso, no dia seguinte você não será mais tarifado. Você terá que lembrar sempre de fazer este procedimento um dia antes.

Internet Wi-Fi muito lenta no Moto X e/ou Android Lollipop - Resolvido

No mês de julho de 2015, tive um problema com a minha internet wi-fi, que será detalhado neste post. Tenho internet GVT 25Mb que me atende muito bem em todos os dispositivos, inclusive simultaneamente:

• CPU
• Notebook
• Tablet
• Celular Moto X [Lollipop] e Moto G[Kitkat] (meu e da minha esposa)
• PlayStation3
• 2 TVs Smart (Samsung e LG)

Em resumo, simples navegações, downloads, YouTube, Netflix, games online, enfim tudo funciona perfeitamente bem de forma que poucas vezes tive algum problema.

O Problema

Há pouco mais de uma semana, passei por um dos problemas mais estranhos que já vi na rede local da minha residência.
Ao conectar o meu Moto X de 2ª geração à rede Wi-Fi, percebi que em alguns momentos a internet ficava muito lenta. Cheguei a fazer testes em que alguma páginas chegavam a demorar cerca de 60 a 90 segundos para ser carregadas, exatamente como mostrado no vídeo abaixo:

http://www.stevenf.com/downloads/iphone-6-moto-x.mp4

Ao receber uma visita de parentes, pude perceber que todos os celulares do pessoal, tais como Samsung Galaxy e Iphones não apresentavam este problema. Juntando todas as peças cheguei a seguinte conclusão: o problema não podia ser atribuído somente a minha rede, já que todos os dispositivos citados até agora não apresentavam lentidão, exceto os nossos celulares Motorola; mas também deveria haver alguma mudança recente ocorrida na rede ou na configuração do meu roteador, visto que meu Moto X não apresenta este problema ao conectar em outras redes Wi-Fi.

A Solução

Depois de muitas pesquisas e muitos testes e mudanças de configuração no celular e no roteador, este artigo resolveu os meus problemas:

http://forums.androidcentral.com/lg-g4/542447-slow-wifi-fixed.html
Que nos remete a este outro link
http://phandroid.com/2015/05/13/comcast-wireless-gateway-lollipop-bug/

Em resumo, o problema parece ocorrer não só nos celulares da Motorola mas também em outros modelos com a versão Lollipop do Android (e pelo que vi depois, versões anteriores também). A causa do problema é que o celular tenta solicitar um endereço IPV6 do roteador e nesse momento ele não consegue conversar com ele por algum motivo. Logo, ou você desabilita o ipv6 no seu roteador (opção que não tenho, pois não desbloqueei meu roteador) ou desabilita o ipv6 no Android, o que me pareceu mais simples e rápido do que mexer em toda uma infraestrutura já funcional.

Atualizado dia 07/08/2016:
O problema não ocorre somente em celulares Motorola. Foi reportado que até o momento o bug já ocorreu em outras modelos de outros fabricantes também: Positivo S480, Zen Fone, XPeria Z2, Galaxy J5, Galaxy S7.

A solução dada pelos links acima foi instalar o DNSET, que cria uma VPN que vai forçar o celular Android a conectar usando IPV4. Não necessita nem rootar o seu aparelho. Na descrição do aplicativo, ele afirma que configura o seu aparelho pra usar os servidores DNS do Google (8.8.8.8, 8.8.4.4) e o app desliga após a VPN ser estabelecida. Eu cheguei a tentar configurar manualmente meu DNS pros do Google, mas o problema de lentidão persistiu, sendo resolvido somente com o DNSET mesmo.

Algumas pessoas não confiam muito nesse aplicativo pelo tráfego ter que passar por uma VPN, apesar de segundo o desenvolvedor, e até onde pude analisar com o traceroute, o tunelamento é feito localmente. Na verdade, não deu pra entender por completo o funcionamento, mas caso não queria usar o aplicativo existe uma outra forma de se resolver o problema seria editando um arquivo de configuração para desabilitar o IPV6, conforme explicado neste link:
http://www.reddit.com/r/Android/comments/2z1gyo/fix_lollipop_wifi_issues_and_coincidentally_the/

Concluindo, comecei a utilizar o DNSET em casa e não tive mais problema de lentidão. Em outras redes Wi-Fi que não tenham esse problema (a grande maioria) basta desabilitar o mesmo. Em 27/09/2015, percebi que Acredito que a GVT modificou alguma configuração na sua rede, pois já faz mais de 1 semana que o problema não mais ocorre.

Estas são outras soluções mais completas, conforme dicas recentemente dada nos comentários [Atualizado dia 29/08/2016]: 
1) O aplicativo Disable IPV6, mas seu aparelho precisa de root
2) Se tiver um roteador Wi-Fi antigo, conecte esse roteador na saída do roteador principal. Crie uma segunda rede Wi-Fi (sem IPV6) com outro nome e conecte nesta os dispositivos Android que possuem a falha. A rede principal ficaria para os outros dispositivos. Esse roteador secundário fica em modo roteador e não em modo access point.

Análise técnica do problema [Atualizado dia 24/08/2016]:
Após alguns ótimos comentários do André Lange, resolvi atualizar o post com uma análise mais detalhada do problema feita por ele, além das novas soluções já listadas acima. Pra quem quiser uma análise ainda mais apurada, sugiro que confiram os comentários dele nesse post. O fato é que o Android tem um bug no IPV6, mas especificamente no seu protocolo da camada de enlace NDP. É incrível como até hoje esse bug do Android ainda não foi corrigido, o que tem prejudicado bastante a migração para IPV6.
"No momento em que você conecta o smartphone em uma rede WiFi com IPv6, a navegação em IPv6 funciona normalmente durante alguns minutos. Passados esses minutos, o celular para de responder ao protocolo NDP, mesmo o roteador enviando inúmeras requisições de Neighbor Solicitation para o endereço IPv6 do celular. Isso faz com que o roteador WiFi pense que o celular não está mais presente na rede e assim os pacotes que chegam para o endereço IPv6 dele não tem para onde ir (o roteador não sabe qual o MAC associado àquele endereço IPv6 ou essa informaçao já expirou) e são descartados. Os pacotes IPv6 gerados pelo celular continuam indo para a internet. São as respostas que não retornam ao celular pq ele deixa de responder o protocolo NDP, que é fundamental." Uma das soluções apontadas pelo André (veja nos comentários) é setar o MAC do smartphone manualmente através de um script.
E qual a real importância da adoção do IPV6? "O acesso IPv4 com NAT (tradução de endereços no roteador para permitir compartilhamento de um endereço IP entre várias máquinas) já criou inúmeros problemas e dificuldades para os usuários. Por exemplo, a necessidade de configurar port forwarding nos roteadores para jogar online, baixar torrent, fazer acesso remoto ou simplesmente pra obter a qualidade total nas chamadas de audio/vido em apps como o Skype. Acontece que com a exaustão dos endereços v4 públicos (a internet cresceu e os números acabaram) isso já está piorando, pois os provedores não tem alternativa senão implantar mais uma camada NAT no próprio provedor (CG-NAT) e amontoar diversos clientes atrás de um único endereço IP. Como nós usuários (mesmo os mais avançados) não temos acesso administrativo a esse NAT do provedor, não temos mais como fazer port forwarding e os programas que faziam automaticamente isso por nós (via UPnP) também não conseguem mais fazer. A qualidade do acesso em v4 vai piorar cada vez mais com esse CG-NAT, ficando muitos usuários bloqueados em algum site porque o endereço IP que eles compartilham no provedor teria sido alguma vez utilizado de forma maliciosa/fraudulenta no acesso à esse site. A única solução de longo prazo para tudo isso é a implantação do IPv6, que por ter uma quantidade muito maior de endereços disponível elimina a necessidade de compartilhamento de endereços (NAT)."