O usuário médio do Android provavelmente já parou de se preocupar com o “problema de fragmentação” do Android. Mas o problema ainda assombra os desenvolvedores.
A fragmentação tem sido um problema controverso no Android, literalmente, desde que o sistema operacional móvel foi anunciado.
Além de ser um porrete para os trolls usarem em guerras online, a diversidade que acompanha a fragmentação é agora amplamente vista como um positivo líquido para os consumidores de dispositivos Android. Afinal, temos tanta liberdade na escolha do tipo de dispositivo com o tipo de software que queremos que é difícil para o consumidor médio se preocupar com a fragmentação. A visualização da incrível variedade de dispositivos Android produz um belo mosaico da representação diversificada do Android.
Mas a fragmentação de hardware e software não torna um desenvolvedor de software feliz. Na verdade, muito pelo contrário. Desenvolver um aplicativo em tantas configurações diferentes de hardware e software pode ser um grande incômodo durante a depuração. Os OEMs podem fazer alterações grandes ou sutis que precisam ser levadas em conta ao desenvolver um aplicativo, mas não há realmente uma maneira fácil para o desenvolvedor individual garantir que seu aplicativo funcionará universalmente. Embora o consumidor médio já tenha esquecido há muito tempo o debate sobre a fragmentação, o problema ainda assombra o Android desenvolvedores de aplicativos e aparentemente não há nada a fazer sobre isso, exceto engolir e lidar com os erros à medida que eles aparecer.
O lamentável estado de fragmentação
Um OEM em particular recebe grande parte do ódio pelas dores de cabeça que causa ao desenvolver um aplicativo – a Samsung. Os desenvolvedores vêm reclamando da Samsung há anos, alguns até escrevendo artigos contundentes como "Há um lugar especial para a Samsung no Android Hell" que descreve um bug particularmente frustrante decorrente de Dispositivos Samsung e a biblioteca appcompat de suporte. Gostaria de chamar a atenção para um parágrafo em particular do discurso do Sr. Ambri, que descreve de forma excelente por que os desenvolvedores ainda se preocupam com a fragmentação:
Se você é um desenvolvedor Android, seu ódio pelos dispositivos Samsung provavelmente não tem limites. Mais do que um usuário médio, para quem Samsung é sinônimo bobo Touchwiz e bloatware excessivo, você despreza a Samsung porque não tem escolha. Por causa da Samsung enorme participação de mercado, você simplesmente não pode optar por não oferecer suporte a dispositivos Samsung. E é isso que dói mais; o fato de que essa escolha foi tirada de você!
Este também não é um discurso retórico dos velhos tempos de existência do Android - este post foi publicado em meados de dezembro do ano passado. Serei sincero e declararei que não tenho certeza se esse problema já foi oficialmente corrigido, no entanto, Sr. Ambri forneceu uma correção em sua postagem para qualquer um que se deparasse com seu discurso por meio de uma pesquisa no Google pelo erro. Tudo que você precisa fazer é usar ProGuard com a seguinte linha única de código:
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}Isso não é tão ruim, não é? O problema, porém, é que essa correção foi retirada do Stack Overflow. Não me interpretem mal, Stack Overflow é um ótimo site. Mas não é realmente uma fonte ideal para descobrir soluções para seus aplicativos. Encontrar algo no Stack Overflow geralmente envolve mergulhar fundo nos links após muitas pesquisas de tentativa e erro no Google. Às vezes você encontrará outro usuário mencionando o mesmo bug que você está enfrentando, mas sem uma solução à vista. Ou ainda mais frustrantes são os momentos em que você encontra um tópico onde o autor da postagem original afirmou ter encontraram uma solução, mas há muito abandonaram o tópico sem instruir outras pessoas sobre como consertar o problema. emitir.
Um exemplo de problema de fragmentação sutil
Não sou desenvolvedor, mas estou familiarizado o suficiente com os recursos do Android, depois de anos mexendo no Tasker, e comecei a pseudoprogramar minhas próprias soluções para os problemas que enfrentei. E quando não consigo descobrir alguma coisa, procuro no Google, assim como todo mundo faz. Enquanto eu estava escrevendo meu artigo anterior sobre vasculhando o aplicativo Configurações do seu telefone em busca de atividades ocultas, me deparei com um bug bastante estranho que não consegui explicar. Um bug exclusivo dos dispositivos Huawei.
Sempre que eu tentava iniciar determinadas atividades (como o menu "Teste" que contém estatísticas de uso do aplicativo) no aplicativo Configurações, sempre encontrava um erro de permissão. Em particular, o aplicativo que eu estava usando para iniciar a atividade não tinha permissão huawei.android.permissão. HW_SIGNATURE_OR_SYSTEM. Nenhum outro dispositivo que testei exigiu permissões exclusivas para iniciar essas atividades de configurações, apenas telefones que executam a versão do Android da Huawei (EMUI). Uma análise de com.android.settings revelou que certas atividades no aplicativo Configurações estavam de fato sob um nível de proteção que exigia o assinatura ou permissão do sistema.
Infelizmente para mim, isso significa que apenas aplicativos instalados em /system ou aplicativos assinados com o mesmo assinatura, pois o aplicativo Configurações seria capaz de abrir essas atividades usando o método que eu estava tentando. Quando pesquisei no Google uma resposta para esse erro, eu (você adivinhou) me deparei com um Thread de estouro de pilha. O desenvolvedor que postou seu problema se deparou com o mesmo problema que eu (embora ele estivesse no processo de desenvolvimento de um aplicativo). Seu problema surgiu quando ele tentou executar o seguinte código:
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>A julgar pelas strings na intenção e na página da web do desenvolvedor, ele provavelmente estava tentando permitir que o usuário escolhesse um aplicativo de terceiros para reproduzir alguma mídia. A correção, fornecida por um desenvolvedor veterano CommonsWare, era bem simples: usar Intenção. CriarChooser em vez de ACTION_PICK_ACTIVITY. No entanto, por que devemos precisar implementar essa correção? Por que a Huawei está exigindo essa permissão em primeiro lugar? Por que precisávamos encontrar uma resposta no StackOverflow usando uma pesquisa muito específica no Google?
O paradoxo da escolha
Para encontrar uma resposta, CommonsWare apresentou um relatório de bug no rastreador de bugs do Android solicitando que o Google analise o problema. Em particular, o desenvolvedor solicitou que o Google proibisse requisitos de permissão não documentados de restringir o acesso de aplicativos de terceiros a ACTION_PICK_ACTIVITY. Ao escrever esses requisitos em CTS, a Huawei seria forçada a cumprir essas mudanças.
Para ser honesto, porém, esse bug em si não é grande coisa. Mesmo que nenhum outro aplicativo que experimentei (como o Tasker) tenha conseguido contornar essa permissão requisito e iniciar certas atividades no aplicativo Configurações, não fiquei exatamente desapontado com o resultado. Mas quando me lembrei do discurso do Sr. Ambri, percebi que pequenas mudanças como estas devem ser muito frustrantes de lidar, especialmente porque por mais minúsculos que sejam, eles sem dúvidaadicionar, às vezes o suficiente para causar dor de cabeça. Uma pequena alteração no aplicativo Configurações pode resultar em uma avaliação negativa imerecida contra um desenvolvedor. Uma pequena mudança que está mal documentada e exigiu que eu vasculhasse a Internet em busca de um thread Stack Overflow. Quantos outros pequenos bugs existem em outros dispositivos?
O aumento da concorrência no espaço móvel provou ser ótimo para o consumidor, mas depois de ver como essas mudanças sutis em tantas linhas de produtos diferentes pode afetar os desenvolvedores, passei a apreciar a visão do desenvolvedor em relação fragmentação. Não é que a escolha em si seja o problema, mas sim que a comunidade não está a fazer o suficiente para catalogar estas questões. Como o Sr. Ambri sugeriu em seu artigo, talvez os desenvolvedores Android precisem de sua própria versão do caniuse. com ou sdkcritic. com para coletar todos os bugs obscuros em um banco de dados. A única outra alternativa é fazer com que os OEMs documentem adequadamente essas alterações ou parem de fazê-las, mas boa sorte com isso.
Créditos da imagem em destaque: OpenSignal