Sto provando un campione con Room Persistence Library . Ho creato un'entità:

@Entity
public class Agent {
    @PrimaryKey
    public String guid;
    public String name;
    public String email;
    public String password;
    public String phone;
    public String licence;
}

Creata una classe DAO:

@Dao
public interface AgentDao {
    @Query("SELECT COUNT(*) FROM Agent where email = :email OR phone = :phone OR licence = :licence")
    int agentsCount(String email, String phone, String licence);

    @Insert
    void insertAgent(Agent agent);
}

Creata la classe Database:

@Database(entities = {Agent.class}, version = 1)
public abstract class AppDatabase extends RoomDatabase {
    public abstract AgentDao agentDao();
}

Database esposto utilizzando la sottoclasse sottostante in Kotlin:

class MyApp : Application() {

    companion object DatabaseSetup {
        var database: AppDatabase? = null
    }

    override fun onCreate() {
        super.onCreate()
        MyApp.database =  Room.databaseBuilder(this, AppDatabase::class.java, "MyDatabase").build()
    }
}

Funzione di seguito implementata nella mia attività:

void signUpAction(View view) {
        String email = editTextEmail.getText().toString();
        String phone = editTextPhone.getText().toString();
        String license = editTextLicence.getText().toString();

        AgentDao agentDao = MyApp.DatabaseSetup.getDatabase().agentDao();
        //1: Check if agent already exists
        int agentsCount = agentDao.agentsCount(email, phone, license);
        if (agentsCount > 0) {
            //2: If it already exists then prompt user
            Toast.makeText(this, "Agent already exists!", Toast.LENGTH_LONG).show();
        }
        else {
            Toast.makeText(this, "Agent does not exist! Hurray :)", Toast.LENGTH_LONG).show();
            onBackPressed();
        }
    }

Sfortunatamente durante l'esecuzione del metodo precedente si blocca con la traccia dello stack sottostante:

    FATAL EXCEPTION: main
 Process: com.example.me.MyApp, PID: 31592
java.lang.IllegalStateException: Could not execute method for android:onClick
    at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:293)
    at android.view.View.performClick(View.java:5612)
    at android.view.View$PerformClick.run(View.java:22288)
    at android.os.Handler.handleCallback(Handler.java:751)
    at android.os.Handler.dispatchMessage(Handler.java:95)
    at android.os.Looper.loop(Looper.java:154)
    at android.app.ActivityThread.main(ActivityThread.java:6123)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757)
 Caused by: java.lang.reflect.InvocationTargetException
    at java.lang.reflect.Method.invoke(Native Method)
    at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:288)
    at android.view.View.performClick(View.java:5612) 
    at android.view.View$PerformClick.run(View.java:22288) 
    at android.os.Handler.handleCallback(Handler.java:751) 
    at android.os.Handler.dispatchMessage(Handler.java:95) 
    at android.os.Looper.loop(Looper.java:154) 
    at android.app.ActivityThread.main(ActivityThread.java:6123) 
    at java.lang.reflect.Method.invoke(Native Method) 
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757) 
 Caused by: java.lang.IllegalStateException: Cannot access database on the main thread since it may potentially lock the UI for a long periods of time.
    at android.arch.persistence.room.RoomDatabase.assertNotMainThread(RoomDatabase.java:137)
    at android.arch.persistence.room.RoomDatabase.query(RoomDatabase.java:165)
    at com.example.me.MyApp.RoomDb.Dao.AgentDao_Impl.agentsCount(AgentDao_Impl.java:94)
    at com.example.me.MyApp.View.SignUpActivity.signUpAction(SignUpActivity.java:58)
    at java.lang.reflect.Method.invoke(Native Method) 
    at android.support.v7.app.AppCompatViewInflater$DeclaredOnClickListener.onClick(AppCompatViewInflater.java:288) 
    at android.view.View.performClick(View.java:5612) 
    at android.view.View$PerformClick.run(View.java:22288) 
    at android.os.Handler.handleCallback(Handler.java:751) 
    at android.os.Handler.dispatchMessage(Handler.java:95) 
    at android.os.Looper.loop(Looper.java:154) 
    at android.app.ActivityThread.main(ActivityThread.java:6123) 
    at java.lang.reflect.Method.invoke(Native Method) 
    at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:867) 
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:757) 

Sembra che il problema sia correlato all'esecuzione dell'operazione db sul thread principale. Tuttavia, il codice di prova di esempio fornito nel collegamento precedente non viene eseguito su un thread separato:

@Test
    public void writeUserAndReadInList() throws Exception {
        User user = TestUtil.createUser(3);
        user.setName("george");
        mUserDao.insert(user);
        List<User> byName = mUserDao.findUsersByName("george");
        assertThat(byName.get(0), equalTo(user));
    }

Mi manca qualcosa qui? Come posso farlo eseguire senza crash? Per favore suggerisci.

L'accesso al database sul thread principale che blocca l'interfaccia utente è l'errore, come ha detto Dale.

Crea una classe annidata statica (per evitare perdite di memoria) nella tua attività che estende AsyncTask.

private static class AgentAsyncTask extends AsyncTask<Void, Void, Integer> {

    //Prevent leak
    private WeakReference<Activity> weakActivity;
    private String email;
    private String phone;
    private String license;

    public AgentAsyncTask(Activity activity, String email, String phone, String license) {
        weakActivity = new WeakReference<>(activity);
        this.email = email;
        this.phone = phone;
        this.license = license;
    }

    @Override
    protected Integer doInBackground(Void... params) {
        AgentDao agentDao = MyApp.DatabaseSetup.getDatabase().agentDao();
        return agentDao.agentsCount(email, phone, license);
    }

    @Override
    protected void onPostExecute(Integer agentsCount) {
        Activity activity = weakActivity.get();
        if(activity == null) {
            return;
        }

        if (agentsCount > 0) {
            //2: If it already exists then prompt user
            Toast.makeText(activity, "Agent already exists!", Toast.LENGTH_LONG).show();
        } else {
            Toast.makeText(activity, "Agent does not exist! Hurray :)", Toast.LENGTH_LONG).show();
            activity.onBackPressed();
        }
    }
}

Oppure puoi creare una classe finale sul proprio file.

Quindi eseguilo nel metodo signUpAction (View view):

new AgentAsyncTask(this, email, phone, license).execute();

In alcuni casi potresti anche voler mantenere un riferimento ad AgentAsyncTask nella tua attività in modo da poterlo annullare quando l'attività viene distrutta. Ma dovresti interrompere tu stesso qualsiasi transazione.

Inoltre, la tua domanda sull'esempio di test di Google ... In quella pagina web si afferma:

L'approccio consigliato per testare l'implementazione del database è scrivere un test JUnit che viene eseguito su un dispositivo Android. Poiché questi test non richiedono la creazione di un'attività, dovrebbero essere più veloci da eseguire rispetto ai test dell'interfaccia utente.

Nessuna attività, nessuna interfaccia utente.

--MODIFICARE--

Per le persone che si chiedono ... Hai altre opzioni. Consiglio di dare un'occhiata ai nuovi componenti ViewModel e LiveData. LiveData funziona alla grande con Room. https://developer.android.com/topic/libraries/architecture/livedata.html

Un'altra opzione è RxJava / RxAndroid. Più potente ma più complesso di LiveData. https://github.com/ReactiveX/RxJava

--EDIT 2--

Dal momento che molte persone potrebbero trovare questa risposta ... L'opzione migliore al giorno d'oggi, in generale, è Kotlin Coroutines. Room ora lo supporta direttamente (attualmente in beta). https://kotlinlang.org/docs/reference/coroutines-overview.html https://developer.android.com/jetpack/androidx/releases/room#2.1.0-beta01

Non è consigliato ma puoi accedere al database sul thread principale con allowMainThreadQueries()

MyApp.database =  Room.databaseBuilder(this, AppDatabase::class.java, "MyDatabase").allowMainThreadQueries().build()

Kotlin Coroutines (chiaro e conciso)

AsyncTask è davvero goffo. Le coroutine sono un'alternativa più pulita (basta cospargere un paio di parole chiave e il codice di sincronizzazione diventa asincrono).

// Step 1: add `suspend` to your fun
suspend fun roomFun(...): Int
suspend fun notRoomFun(...) = withContext(Dispatchers.IO) { ... }

// Step 2: launch from coroutine scope
private fun myFun() {
    lifecycleScope.launch { // coroutine on Main
        val queryResult = roomFun(...) // coroutine on IO
        doStuff() // ...back on Main
    }
}

Dipendenze (aggiunge gli ambiti coroutine per i componenti dell'arco):

// lifecycleScope:
implementation 'androidx.lifecycle:lifecycle-runtime-ktx:2.2.0-alpha04'

// viewModelScope:
implementation 'androidx.lifecycle:lifecycle-viewmodel-ktx:2.2.0-alpha04'

- Aggiornamenti: 8
maggio 2019: la stanza 2.1 ora supporta il suspend
13 settembre 2019: aggiornato per utilizzare l' ambito dei componenti dell'architettura

Per tutti gli amanti di RxJava o RxAndroid o RxKotlin là fuori

Observable.just(db)
          .subscribeOn(Schedulers.io())
          .subscribe { db -> // database operation }

Non è possibile eseguirlo sul thread principale invece utilizzare gestori, thread asincroni o di lavoro. Un codice di esempio è disponibile qui e leggi l'articolo sulla libreria della stanza qui: Libreria della stanza di Android

/**
 *  Insert and get data using Database Async way
 */
AsyncTask.execute(new Runnable() {
    @Override
    public void run() {
        // Insert Data
        AppDatabase.getInstance(context).userDao().insert(new User(1,"James","Mathew"));

        // Get Data
        AppDatabase.getInstance(context).userDao().getAllUsers();
    }
});

Se vuoi eseguirlo sul thread principale che non è il modo preferito.

È possibile utilizzare questo metodo per ottenere risultati sul thread principale Room.inMemoryDatabaseBuilder()

Con lambda è facile da eseguire con AsyncTask

 AsyncTask.execute(() -> //run your query here );

Con la libreria Jetbrains Anko, puoi usare il metodo doAsync {..} per eseguire automaticamente le chiamate al database. Questo risolve il problema di verbosità che sembrava avessi avuto con la risposta di mcastro.

Utilizzo di esempio:

    doAsync { 
        Application.database.myDAO().insertUser(user) 
    }

Lo uso frequentemente per inserimenti e aggiornamenti, tuttavia per determinate query consiglio di utilizzare il flusso di lavoro RX.

Basta eseguire le operazioni sul database in un thread separato. In questo modo (Kotlin):

Thread {
   //Do your database´s operations here
}.start()

Devi eseguire la richiesta in background. Un modo semplice potrebbe essere usare un esecutore :

Executors.newSingleThreadExecutor().execute { 
   yourDb.yourDao.yourRequest() //Replace this by your request
}

È da utilizzare un'elegante soluzione RxJava / Kotlin Completable.fromCallable, che ti darà un Observable che non restituisce un valore, ma può essere osservato e sottoscritto su un thread diverso.

public Completable insert(Event event) {
    return Completable.fromCallable(new Callable<Void>() {
        @Override
        public Void call() throws Exception {
            return database.eventDao().insert(event)
        }
    }
}

O a Kotlin:

fun insert(event: Event) : Completable = Completable.fromCallable {
    database.eventDao().insert(event)
}

Puoi osservare e iscriverti come faresti di solito:

dataManager.insert(event)
    .subscribeOn(scheduler)
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(...)

Puoi consentire l'accesso al database sul thread principale ma solo a scopo di debug, non dovresti farlo in produzione.

Ecco il motivo.

Nota: Room non supporta l'accesso al database sul thread principale a meno che tu non abbia chiamato allowMainThreadQueries () nel builder perché potrebbe bloccare l'interfaccia utente per un lungo periodo di tempo. Le query asincrone, ovvero le query che restituiscono istanze di LiveData o Flowable, sono esentate da questa regola perché eseguono la query in modo asincrono su un thread in background quando necessario.

Semplicemente puoi usare questo codice per risolverlo:

Executors.newSingleThreadExecutor().execute(new Runnable() {
                    @Override
                    public void run() {
                        appDb.daoAccess().someJobes();//replace with your code
                    }
                });

Oppure in lambda puoi usare questo codice:

Executors.newSingleThreadExecutor().execute(() -> appDb.daoAccess().someJobes());

Puoi sostituire appDb.daoAccess().someJobes()con il tuo codice;

Poiché asyncTask è deprecato, potremmo utilizzare il servizio executor. OPPURE puoi anche usare ViewModel con LiveData come spiegato in altre risposte.

Per utilizzare il servizio esecutore, puoi usare qualcosa come di seguito.

public class DbHelper {

    private final Executor executor = Executors.newSingleThreadExecutor();

    public void fetchData(DataFetchListener dataListener){
        executor.execute(() -> {
                Object object = retrieveAgent(agentId);
                new Handler(Looper.getMainLooper()).post(() -> {
                        dataListener.onFetchDataSuccess(object);
                });
        });
    }
}

Viene utilizzato il Looper principale, in modo da poter accedere all'elemento dell'interfaccia utente dalla onFetchDataSuccessrichiamata.

Il messaggio di errore,

Impossibile accedere al database sul thread principale poiché potrebbe potenzialmente bloccare l'interfaccia utente per lunghi periodi di tempo.

È abbastanza descrittivo e accurato. La domanda è come evitare di accedere al database sul thread principale. Questo è un argomento enorme, ma per iniziare, leggi AsyncTask (clicca qui)

-----MODIFICARE----------

Vedo che hai problemi quando esegui uno unit test. Hai un paio di scelte per risolvere questo problema:

1. Esegui il test direttamente sulla macchina di sviluppo anziché su un dispositivo Android (o emulatore). Questo funziona per i test che sono incentrati sul database e non si preoccupano davvero se sono in esecuzione su un dispositivo.

2. Utilizza l'annotazione @RunWith(AndroidJUnit4.class) per eseguire il test sul dispositivo Android, ma non in un'attività con un'interfaccia utente. Maggiori dettagli su questo possono essere trovati in questo tutorial

Se sei più a tuo agio con l' attività Async :

  new AsyncTask<Void, Void, Integer>() {
                @Override
                protected Integer doInBackground(Void... voids) {
                    return Room.databaseBuilder(getApplicationContext(),
                            AppDatabase.class, DATABASE_NAME)
                            .fallbackToDestructiveMigration()
                            .build()
                            .getRecordingDAO()
                            .getAll()
                            .size();
                }

                @Override
                protected void onPostExecute(Integer integer) {
                    super.onPostExecute(integer);
                    Toast.makeText(HomeActivity.this, "Found " + integer, Toast.LENGTH_LONG).show();
                }
            }.execute();

Aggiornamento: ho ricevuto questo messaggio anche quando stavo cercando di creare una query utilizzando @RawQuery e SupportSQLiteQuery all'interno di DAO.

@Transaction
public LiveData<List<MyEntity>> getList(MySettings mySettings) {
    //return getMyList(); -->this is ok

    return getMyList(new SimpleSQLiteQuery("select * from mytable")); --> this is an error

Soluzione: creare la query all'interno di ViewModel e passarla a DAO.

public MyViewModel(Application application) {
...
        list = Transformations.switchMap(searchParams, params -> {

            StringBuilder sql;
            sql = new StringBuilder("select  ... ");

            return appDatabase.rawDao().getList(new SimpleSQLiteQuery(sql.toString()));

        });
    }

O...

Non dovresti accedere al database direttamente sul thread principale, ad esempio:

 public void add(MyEntity item) {
     appDatabase.myDao().add(item); 
 }

È necessario utilizzare AsyncTask per le operazioni di aggiornamento, aggiunta ed eliminazione.

Esempio:

public class MyViewModel extends AndroidViewModel {

    private LiveData<List<MyEntity>> list;

    private AppDatabase appDatabase;

    public MyViewModel(Application application) {
        super(application);

        appDatabase = AppDatabase.getDatabase(this.getApplication());
        list = appDatabase.myDao().getItems();
    }

    public LiveData<List<MyEntity>> getItems() {
        return list;
    }

    public void delete(Obj item) {
        new deleteAsyncTask(appDatabase).execute(item);
    }

    private static class deleteAsyncTask extends AsyncTask<MyEntity, Void, Void> {

        private AppDatabase db;

        deleteAsyncTask(AppDatabase appDatabase) {
            db = appDatabase;
        }

        @Override
        protected Void doInBackground(final MyEntity... params) {
            db.myDao().delete((params[0]));
            return null;
        }
    }

    public void add(final MyEntity item) {
        new addAsyncTask(appDatabase).execute(item);
    }

    private static class addAsyncTask extends AsyncTask<MyEntity, Void, Void> {

        private AppDatabase db;

        addAsyncTask(AppDatabase appDatabase) {
            db = appDatabase;
        }

        @Override
        protected Void doInBackground(final MyEntity... params) {
            db.myDao().add((params[0]));
            return null;
        }

    }
}

Se usi LiveData per selezionare le operazioni, non hai bisogno di AsyncTask.

Per query rapide puoi lasciare spazio per eseguirlo sul thread dell'interfaccia utente.

AppDatabase db = Room.databaseBuilder(context.getApplicationContext(),
        AppDatabase.class, DATABASE_NAME).allowMainThreadQueries().build();

Nel mio caso ho dovuto capire se l'utente cliccato nell'elenco esiste o meno nel database. In caso contrario, creare l'utente e avviare un'altra attività

       @Override
        public void onClick(View view) {



            int position = getAdapterPosition();

            User user = new User();
            String name = getName(position);
            user.setName(name);

            AppDatabase appDatabase = DatabaseCreator.getInstance(mContext).getDatabase();
            UserDao userDao = appDatabase.getUserDao();
            ArrayList<User> users = new ArrayList<User>();
            users.add(user);
            List<Long> ids = userDao.insertAll(users);

            Long id = ids.get(0);
            if(id == -1)
            {
                user = userDao.getUser(name);
                user.setId(user.getId());
            }
            else
            {
                user.setId(id);
            }

            Intent intent = new Intent(mContext, ChatActivity.class);
            intent.putExtra(ChatActivity.EXTRAS_USER, Parcels.wrap(user));
            mContext.startActivity(intent);
        }
    }

Puoi usare Future e Callable. Quindi non ti verrà richiesto di scrivere una lunga asynctask e puoi eseguire le tue query senza aggiungere allowMainThreadQueries ().

La mia query dao: -

@Query("SELECT * from user_data_table where SNO = 1")
UserData getDefaultData();

Il mio metodo di repository: -

public UserData getDefaultData() throws ExecutionException, InterruptedException {

    Callable<UserData> callable = new Callable<UserData>() {
        @Override
        public UserData call() throws Exception {
            return userDao.getDefaultData();
        }
    };

    Future<UserData> future = Executors.newSingleThreadExecutor().submit(callable);

    return future.get();
}

A mio parere, la cosa giusta da fare è delegare la query a un thread IO utilizzando RxJava.

Ho un esempio di soluzione a un problema equivalente che ho appena riscontrato.

((ProgressBar) view.findViewById(R.id.progressBar_home)).setVisibility(View.VISIBLE);//Always good to set some good feedback
        Completable.fromAction(() -> {
            //Creating view model requires DB access
            homeViewModel = new ViewModelProvider(this, factory).get(HomeViewModel.class);
        }).subscribeOn(Schedulers.io())//The DB access executes on a non-main-thread thread
        .observeOn(AndroidSchedulers.mainThread())//Upon completion of the DB-involved execution, the continuation runs on the main thread
        .subscribe(
                () ->
                {
                    mAdapter = new MyAdapter(homeViewModel.getExams());
                    recyclerView.setAdapter(mAdapter);
                    ((ProgressBar) view.findViewById(R.id.progressBar_home)).setVisibility(View.INVISIBLE);
                },
                error -> error.printStackTrace()
        );

E se vogliamo generalizzare la soluzione:

((ProgressBar) view.findViewById(R.id.progressBar_home)).setVisibility(View.VISIBLE);//Always good to set some good feedback
        Completable.fromAction(() -> {
            someTaskThatTakesTooMuchTime();
        }).subscribeOn(Schedulers.io())//The long task executes on a non-main-thread thread
        .observeOn(AndroidSchedulers.mainThread())//Upon completion of the DB-involved execution, the continuation runs on the main thread
        .subscribe(
                () ->
                {
                    taskIWantToDoOnTheMainThreadWhenTheLongTaskIsDone();
                },
                error -> error.printStackTrace()
        );