Estou tentando seguir as práticas recomendadas do Android; portanto, no modo de depuração, ative o seguinte:

StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all thread violations
StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder().detectAll().penaltyLog().build()); //detect and log all virtual machine violations

Android agora grita comigo quando tento usar qualquer tipo de acesso a arquivos ou SQL no thread principal (UI). Mas vejo muitas recomendações para usar o acesso a arquivos e / ou SQL no thread principal. Por exemplo, a atividade principal deve carregar valores de preferência padrão dentro deonCreate() caso ainda não tenham sido definidos:

PreferenceManager.setDefaultValues(context, resId, readAgain);

Oops --- isso resulta em um acesso ao arquivo na primeira execução do aplicativo, porqueonCreate() é chamado no thread da interface do usuário. A única maneira de contornar isso é iniciar um thread separado - que introduz uma condição de corrida com outro código de interface do usuário que pode ler as preferências e esperar que os valores padrão já estejam definido

Pense também em serviços como o DownloadManager. (Na verdade, é tão problemático que é inútil na vida real, mas vamos fingir que funciona por um segundo.) Se você enfileira um download, recebe um evento (no thread principal) informando que o download foi concluído. Para realmente obter informações sobre esse download (ele fornece apenas um ID de download), é necessário consultar o DownloadManager --- que envolve um cursor, causando um erro se você tiver uma política rígida ativada.

Então, qual é a história --- é bom acessar os cursores no thread principal? Ou é uma coisa ruim e metade da equipe de desenvolvimento do Android e os autores de livros do Android se esqueceram disso?