So after a little more research, and following some of the paths you pointed out, I came up with a Cake Recipe * as I was looking for.

I'll show you the solution that met my needs:

I followed the tips pointed out in this link , making some modifications to my needs.

public class DatabaseManager {
    private AtomicInteger mOpenCounter = new AtomicInteger();

private static DatabaseManager instance;
private static SQLiteOpenHelper mDatabaseHelper;
private SQLiteDatabase mDatabase;

    private DatabaseManager() {
        super();
    }

private static synchronized void initializeInstance(SQLiteOpenHelper helper) {
    if (instance == null) {
        instance = new DatabaseManager();
        mDatabaseHelper = helper;
    }
}

public static synchronized DatabaseManager getInstance(Context context,
        String dbName, int dbVersion) {
    if (instance == null) {
        initializeInstance(new DatabaseHelper(context, dbName, dbVersion));
        return instance;
    }

    return instance;
}

public synchronized SQLiteDatabase openDatabase() {
    if (mOpenCounter.incrementAndGet() == 1) {
        // Opening new database
        mDatabase = mDatabaseHelper.getWritableDatabase();
    }
    return mDatabase;
}

public synchronized void closeDatabase() {
    if (mOpenCounter.decrementAndGet() == 0) {
        // Closing database
        mDatabase.close();

    }
}
}

And in my old class of control I made some modifications that only apply to adapt my old class to the new class of connection management:

public abstract class GConexaoAdapter {

protected final Context ctx;
private final String dbName;
private final int dbVersion;

public GConexaoAdapter(Context ctx, String dbName, int dbVersion) {
    this.dbName = dbName;
    this.dbVersion = dbVersion;
    this.ctx = ctx;
}

protected SQLiteDatabase getConexao() {
    return DatabaseManager.getInstance(ctx, dbName, dbVersion)
            .openDatabase();
}

protected void closeConexao() {
    DatabaseManager.getInstance(ctx, dbName, dbVersion).closeDatabase();
}
}

This second class is not required you can use DatabaseManager directly in this way:

private long create(ContentValues valores) {
    try {
        DatabaseManager.getInstance(ctx, "db", 1).openDatabase()
                .beginTransaction();
        long result = DatabaseManager.getInstance(ctx, "db", 1).openDatabase().insert(nomeTabela, null, valores);
        DatabaseManager.getInstance(ctx, "db", 1).openDatabase().setTransactionSuccessful();
        return result;
    } finally {
        DatabaseManager.getInstance(ctx, "db", 1).openDatabase().endTransaction();
        DatabaseManager.getInstance(ctx, "db", 1).closeDatabase();
    }
}

Or adapt it to the way you work.

* ¹It is not a cake recipe as actually expected by the question, but for my specific case and I believe that for others too, it will be very useful, and can be easily adapted to your environment if you are working in a modular way and organized.

  

Note: This solution manages the SQLite connection in thread-safe

Synchronizing the bank's opening, reading / writing, and closing methods individually does not solve an essential problem that is the need for access to the bank to be atomic.

It would make your life easier if instead of using that lot of synchronized within that class (sync in a Context ??) you used within the doInBackground() method of your AsyncTask s, wrapping within a block synchronized an atomic operation in the bank composed of open() , read or write, close() :

doInBackground() {

    //Traz os dados do webservice;

    synchronized(objetoLock) {
        open();
        //lê ou grava no banco;
        close();
    }
}

I strongly recommend using an external queue (there are several solutions ready for this) for continuous insertion ... and separate a single thread to consume it function ... will not generate lock and will guarantee the chronological integrity of the data .. just will not be synchronous with reading the data in the original database ..

Start with the default "who opens the connection is who closes it", I'm sorry not to know if there is a cool name for this pattern ... :-)

Implementing the DataSource interface helps you define how you will work with the single connection in the database.

I think this might be a path ... :-)

I do not understand a lot of android, but we have a desktop application that also uses SQLite and the solution for using it in multiple threads was to create a class to be a Pool of connections and this pool had only 1 connection for writing and 2 for reading