I have:

<script>mermaid.initialize({startOnLoad:true,securityLevel:'loose'});</script>

So, AFAIK, I already have it set to loose.

#689 suggests that "#id" should work in click to jump to another portion of the current page. This does not appear to be working.

To Reproduce

Steps to reproduce the behavior:

1. UnZIP MermaidIdSyntaxIssue.zip, which will give you a mermaid-test.html file, pulling in https://unpkg.com/mermaid@8.4.6/dist/mermaid.min.js for the Mermaid distribution. In the first diagram, it contains:

click predstate0 "#state-PromptedForLocationServices"

to have a click jump the node with the id of state-PromptedForLocationServices.

2. Load that in your favorite Web browser (tested on Chromium and Firefox).

3. In the first flowchart diagram, click the "PromptedForLocationServices" bubble (bottom of left-most branch).

Expected behavior

To jump to the "2. PromptedForLocationServices" heading, the way that Test link #2 does at the bottom of the page, as that refers to the same id:

<a href="#state-PromptedForLocationServices">Test link #2</a>

Actual behavior

On Chromium, it goes to about:blank#blocked. On Firefox, the click seems to be ignored.

Note that if you replace "#state-PromptedForLocationServices" with a regular URL (e.g., "https://commonsware.com"), clicking the flowchart node works, so clicking in general is fine.

Desktop (please complete the following information):

• OS: Ubuntu 19.10
• Browser: Chromium 79.0.3945.79, Firefox 72.0.1

My fault! I apologize for messing that up. Fortunately, it looks like that @developernotes already committed a fix: https://github.com/sqlcipher/android-database-sqlcipher/commit/bdf9fa71e8bdd3ee62dbdd2dcecf536abf4bb6cd#diff-fa99240cf3130ab4b9d25c14923ee2d6

https://github.com/sqlcipher/android-database-sqlcipher#using-sqlcipher-for-android-with-room

The documentation here cites two constructors, and there are three:

• SupportFactory(byte[] passphrase)
• SupportFactory(byte[] passphrase, SQLiteDatabaseHook hook)
• SupportFactory(byte[] passphrase, SQLiteDatabaseHook hook, boolean clearPassphrase)

Also, we probably should explain more about what clearPassphrase does. If set to true (which is the default for the other two constructors), this will zero out the bytes of the byte[] after we open the database. This is safest from a security standpoint, but it does mean that the SupportFactory instance is a single-use object. Attempting to reuse the SupportFactory instance later will result in being unable to open the database, because the passphrase will be wrong. If you think that you might need to reuse the SupportFactory instance, pass false for clearPassphrase.

If you would like me to open a PR with these fixes, just let me know what branch to base it off of, and I'll happily do it!

Addressed in #489

(my apologies if this type of issue belongs on issuetracker.google.com...)

Description

The code sample in the documentation ActivityScenarioRule is missing some newlines.

Steps to Reproduce

Look at https://developer.android.com/reference/androidx/test/ext/junit/rules/ActivityScenarioRule?hl=en

Expected Results

Valid Java or Kotlin code in the "Example:" box.

Actual Results

It looks like newlines after the annotations were eaten by a grue:

Reproduced with Firefox 72.0.1 and Chromium 79.0.3945.79 on Ubuntu 19.10.

@hannesa2 You are happier with consumerProguardFiles than I am.

Unless something changed since I last checked, "It is not possible to override -keep rules; they only accumulate."

This means that a library has three options with respect to consumerProguardFiles:

1. Do not publish one, so each app needs to add rules (whether copied-and-pasted or made more specific to the app's needs)

2. Publish one with rules that represent the minimum set, where 100% of apps using the library definitely need those rules, but where some (perhaps many) apps might still need some of their own rules

3. Publish one with broader rules that might be appropriate for many apps, but where those rules will harm other apps (e.g., having them keep classes that those apps do not need)

IMHO, something like consumerProguardFiles would be a lot better if the rules supplied by the library could be overridden. For example, ProGuard could have used include/exclude semantics, where later rules could override earlier rules. Then, SQLCipher for Android could publish broad rules (to simplify most library users), and apps that wound up with extraneous classes could have their own rules to "revert" some of SQLCipher for Android's and remove those unnecessary classes.

Having consumerProguardFiles in SafeRoom is inappropriate, as I should not be providing rules for SQLCipher for Android's classes, given that those rules cannot be overridden. Plus, this library is discontinued, in favor of developers just using SQLCipher for Android directly.

You might consider asking about consumerProguardFiles in the SQLCipher category of the Zetetic Community site.

@auval The main README file is now README-original, and I added a section on ProGuard there.

@developernotes OK, the change is made!

This PR is in support of #488, clarifying a bit about the SupportFactory constructors and the use of the clearPassphrase parameter.

In the project README, you have:

<com.github.ahmadaghazadeh.editor.widget.CodeEditor
            bind:code="<html></html>"
            bind:lang="html"
            bind:isReadOnly="true"
             bind:isShowExtendedKeyboard="false"
            android:layout_width="match_parent"
            android:layout_height="match_parent"/>

However, this is invalid XML. That HTML needs to be escaped:

<com.github.ahmadaghazadeh.editor.widget.CodeEditor
            bind:code="&lt;html&gt;&lt;/html&gt;"
            bind:lang="html"
            bind:isReadOnly="true"
             bind:isShowExtendedKeyboard="false"
            android:layout_width="match_parent"
            android:layout_height="match_parent"/>

https://github.com/sqlcipher/android-database-sqlcipher#using-sqlcipher-for-android-with-room

The documentation here cites two constructors, and there are three:

• SupportFactory(byte[] passphrase)
• SupportFactory(byte[] passphrase, SQLiteDatabaseHook hook)
• SupportFactory(byte[] passphrase, SQLiteDatabaseHook hook, boolean clearPassphrase)

Also, we probably should explain more about what clearPassphrase does. If set to true (which is the default for the other two constructors), this will zero out the bytes of the byte[] after we open the database. This is safest from a security standpoint, but it does mean that the SupportFactory instance is a single-use object. Attempting to reuse the SupportFactory instance later will result in being unable to open the database, because the passphrase will be wrong. If you think that you might need to reuse the SupportFactory instance, pass false for clearPassphrase.

If you would like me to open a PR with these fixes, just let me know what branch to base it off of, and I'll happily do it!

@eygraber FWIW, the next version of SQLCipher for Android should have a SupportSQLite* implementation. At that point, you will no longer need SafeRoom or its associated repository, as you will be able to use SQLCipher for Android directly with Room, SqlDelight, or other androidx.sqlite clients.

I ran into two problems trying to follow the instructions at https://cashapp.github.io/sqldelight/.

First, it does not seem to mention the sqldelight closure that is required:

sqldelight {
  HockeyDb {
    packageName = "com.example.sqldelight.hockey"
  }
}

Without this, I cannot get any code to generate.

Also, this statement seems misleading:

From this SQLDelight will generate a Database Kotlin class

Given that the file above it is identified as src/main/sqldelight/com/example/sqldelight/hockey/data/Player.sq, it seems like this will generate a Player class, not a Database class.

Once I got past those two hiccups, I was able to get SQLDelight rocking in a Kotlin/JVM project!

Another related problem: https://cashapp.github.io/sqldelight/ has a link to https://cashapp.github.io/gradle ("apply the gradle plugin"), and that page does not exist.

java.lang.RuntimeException: An error occurred while executing doInBackground() at android.os.AsyncTask$3.done(AsyncTask.java:353) at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:383) at java.util.concurrent.FutureTask.setException(FutureTask.java:252) at java.util.concurrent.FutureTask.run(FutureTask.java:271) at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636) at java.lang.Thread.run(Thread.java:764) Caused by: net.sqlcipher.database.SQLiteException: file is not a database: , while compiling: select count(*) from sqlite_master; at net.sqlcipher.database.SQLiteCompiledSql.native_compile(Native Method) at net.sqlcipher.database.SQLiteCompiledSql.compile(SQLiteCompiledSql.java:91) at net.sqlcipher.database.SQLiteCompiledSql.<init>(SQLiteCompiledSql.java:64) at net.sqlcipher.database.SQLiteProgram.<init>(SQLiteProgram.java:89) at net.sqlcipher.database.SQLiteQuery.<init>(SQLiteQuery.java:48) at net.sqlcipher.database.SQLiteDirectCursorDriver.query(SQLiteDirectCursorDriver.java:60) at net.sqlcipher.database.SQLiteDatabase.rawQueryWithFactory(SQLiteDatabase.java:2012) at net.sqlcipher.database.SQLiteDatabase.rawQuery(SQLiteDatabase.java:1898) at net.sqlcipher.database.SQLiteDatabase.keyDatabase(SQLiteDatabase.java:2647) at net.sqlcipher.database.SQLiteDatabase.openDatabaseInternal(SQLiteDatabase.java:2577) at net.sqlcipher.database.SQLiteDatabase.openDatabase(SQLiteDatabase.java:1243) at net.sqlcipher.database.SQLiteDatabase.openOrCreateDatabase(SQLiteDatabase.java:1318) at net.sqlcipher.database.SQLiteOpenHelper.getWritableDatabase(SQLiteOpenHelper.java:166) at com.commonsware.cwac.saferoom.Helper$OpenHelper.getWritableSupportDatabase(Helper.java:173) at com.commonsware.cwac.saferoom.Helper.getWritableDatabase(Helper.java:83) at androidx.room.RoomDatabase.inTransaction(RoomDatabase.java:476) at androidx.room.RoomDatabase.assertNotSuspendingTransaction(RoomDatabase.java:281) at android.os.AsyncTask$2.call(AsyncTask.java:333) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:245)  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1162)  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:636)  at java.lang.Thread.run(Thread.java:764)

Quoting myself from my reply to one of your messages:

The user provided an incorrect passphrase, or the database is not encrypted, or the database somehow has been corrupted.

If you feel that there is a bug in SafeRoom, please follow the instructions for filing a bug report. Otherwise, if you have additional questions, please ask them on the discussion thread that I linked to.

what it is actually happening is that If I try to open without SafeHelperFactory, it destroys the encrypted DB (cause of fallbackToDestructiveMigration()) and Room creates a new non-encrypted DB, so that's why I cannot correctly access my data

That is my theory — hopefully, you can confirm that with tests (if you have not done so already). Ideally, fallbackToDestructiveMigration() would have no effect if Room could not open the database in the first place. I have never used fallbackToDestructiveMigration(), so I do not know its precise impact.

In terms of Stetho, you might see if somebody has created a Stetho version that supports SQLCipher for Android.

Once I did that, I cannot access any more data, it is like if the Database was corrupted or something.

It is encrypted. That is the point behind SQLCipher for Android. SafeRoom is a bridge between androidx.sqlite clients like Room and SQLCipher for Android.

Then, I relaunched the app without using it, and I have the same result, the Database is not accesible anymore even after relaunching the app with your helper.

Try it again without fallbackToDestructiveMigration() in step 3 and see if you have better results.

Is it a normal behaviour?

You cannot access a SQLCipher for Android database without using SQLCipher for Android and the correct passphrase, if that is what you mean.

How can I detect that my Database is corrupted due to unauthorised access?

If the database has been tampered with, SQLCipher for Android will refuse to open it. SQLCipher for Android will give you the same error if you try using the wrong passphrase.

Caused by: net.sqlcipher.database.SQLiteException: file is not a database: , while compiling: select count(*) from sqlite_master; at net.sqlcipher.database.SQLiteCompiledSql.native_compile(Native Method) at net.sqlcipher.database.SQLiteCompiledSql.compile(Unknown Source:15) at net.sqlcipher.database.SQLiteCompiledSql.<init>(Unknown Source:43) at net.sqlcipher.database.SQLiteProgram.<init>(Unknown Source:116) at net.sqlcipher.database.SQLiteQuery.<init>(Unknown Source:0) at net.sqlcipher.database.SQLiteDirectCursorDriver.query(Unknown Source:7) at net.sqlcipher.database.SQLiteDatabase.rawQueryWithFactory(Unknown Source:35) at net.sqlcipher.database.SQLiteDatabase.rawQuery(Unknown Source:1) at net.sqlcipher.database.SQLiteDatabase.keyDatabase(Unknown Source:30) at net.sqlcipher.database.SQLiteDatabase.openDatabaseInternal(Unknown Source:14) at net.sqlcipher.database.SQLiteDatabase.openDatabase(Unknown Source:14) at net.sqlcipher.database.SQLiteDatabase.openOrCreateDatabase(Unknown Source:7) at net.sqlcipher.database.SQLiteOpenHelper.getWritableDatabase(Unknown Source:91) at com.commonsware.cwac.saferoom.Helper$OpenHelper.getWritableSupportDatabase(Unknown Source:4) at com.commonsware.cwac.saferoom.Helper.getWritableDatabase(Unknown Source:6) at androidx.room.RoomDatabase.inTransaction(Unknown Source:2) at androidx.room.RoomDatabase.assertNotSuspendingTransaction(Unknown Source:0) at com.kioskengineproject.dao.DaoAccess_Impl.insertBins(Unknown Source:2) at com.kioskengineproject.repository.KioskEngineRepository$1.doInBackground(Unknown Source:12) at com.kioskengineproject.repository.KioskEngineRepository$1.doInBackground(Unknown Source:2) at android.os.AsyncTask$2.call(AsyncTask.java:333)

In general, this error message means that the passphrase that was used to try to decrypt the database was incorrect. If you would like further help, please follow the instructions for getting support.

If you think that you have found a bug in SafeRoom, please follow the instructions and provide:

• the Android OS version on which you are experiencing the problem
• the code necessary to reproduce the problem (this could be the repo's demo app, or it could be some demo project of yours that you publish)
• the steps necessary, using that code and that version of Android, to reproduce the problem

That stack trace does not seem to be complete. Since the difference is between debug and release, you may need to make some adjustments to your ProGuard file (see #22 for more).

If you need additional support, I list a few support options in the documentation. If you feel fairly confident that this is a bug, please follow the bug report guidelines for the project, so that I have a chance of reproducing the problem.

Hi, Everything seems ok when I run my app in debug mode. However the app crashes whenever it is opened in release mode. Any idea?

I recommend that you examine the stack trace associated with your crash and use that information to try to identify what is going wrong. For example, you may need to adjust your ProGuard rules, as somebody else did in #22.

If you have further questions, please use one of the support options that I list in the documentation. If you have evidence that the problem lies in the library, please follow the project contribution guidelines for filing a bug report.

If the APP has some fragment in the one ViewPager from one Activity and we needs block screenshot in just one these fragments, the SECURE_FLAG is apply in all Fragments and clearFlag doesn´t works . How we can fix this ?

FLAG_SECURE applies to a window. There is no means to apply FLAG_SECURE to part of a window, such as a fragment in a pager. Either:

• Secure the entire window, including all pages in the pager
• Do not secure the entire window, including all pages in the pager
• Move the to-be-secured UI out of the pager and into its own window (activity, dialog, etc.)

If you have further general questions about FLAG_SECURE, please use Stack Overflow or one of the many other Android developer support sites. Or, purchase a Warescription and use one of my support options there.

@hakimel I do not see such a config option (export PDFs with one page per slide, not one page per fragment) documented in the configuration section or the PDF export section.

As I indicated, I do not have a device with that very specific OS version and CPU match.

This ticket is basically a duplicate of #469, and there Zetetic indicated that they were working on acquiring test hardware.

@togikan: I cannot help you, without details for reproducing the problem.

The Jetpack Compose FAQ probably deserves a link. I was not certain what category it belonged to, so I put it in "Extras".

Does arm64 and x86_64 are supported in this version?

That is a question for Zetetic. The native libraries are from SQLCipher, not SafeRoom.

Using abiFilters for arm64 and x86_64 will solve the problem or do you have any solution for it

SafeRoom itself is not involved with native libraries for any architecture. SafeRoom depends upon SQLCipher for Android, and so your problem lies with with SQLCipher for Android. Zetetic offers a support board for SQLCipher questions — they may be able to give you some debugging advice there.

Crashstack

java.lang.UnsatisfiedLinkError: No implementation found for java.lang.String c.c.a.a.a.a(java.lang.String, int, int) (tried Java_c_c_a_a_a_a and Java_c_c_a_a_a_a__Ljava_lang_String_2II) at c.c.a.a.a.a(Native Method) at <package>.DetailActivity.onCreate(:1) at android.app.Activity.performCreate(Activity.java:7802) at android.app.Activity.performCreate(Activity.java:7791) at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1306) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3245) at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:3409) at android.app.servertransaction.LaunchActivityItem.execute(LaunchActivityItem.java:83) at android.app.servertransaction.TransactionExecutor.executeCallbacks(TransactionExecutor.java:135) at android.app.servertransaction.TransactionExecutor.execute(TransactionExecutor.java:95) at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2016) at android.os.Handler.dispatchMessage(Handler.java:107) at android.os.Looper.loop(Looper.java:214) at android.app.ActivityThread.main(ActivityThread.java:7356) at java.lang.reflect.Method.invoke(Native Method) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:492) at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:930)

You did not follow the instructions for filing bug reports.

You might try adding a -keep directive for com.commonsware.cwac.anddown.AndDown to your ProGuard/R8 configuration.

Otherwise, if you follow the instructions for filing bug reports and give me a way to reproduce your problem, I will be happy to look at it.

java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/com.my.project-ylDVYPJ077aLjRbuP05fyQ==/base.apk"],nativeLibraryDirectories=[/data/app/com.my.project-ylDVYPJ077aLjRbuP05fyQ==/lib/arm, /system/lib, /vendor/lib]]] couldn't find "libsqlcipher.so"

Crashed on the device: TCL 8082 OS version: Android 8.1.0 ABI:armeabi-v7a, armeabi

I have analyzed the apk and libsqlcipher.so is not found in MIPS lib.

But libsqlcipher.so have generated for these configurartions: x86_64 x86 arm64-v8a armeabi armeabi-v7a

I have analyzed the apk and libsqlcipher.so is not found in MIPS lib.

Zetetic does not distribute SQLCipher for Android for the MIPS architecture.

SafeRoom itself is not involved with native libraries for any architecture. SafeRoom depends upon SQLCipher for Android, and so your problem lies with with SQLCipher for Android. Zetetic offers a support board for SQLCipher questions — they may be able to give you some debugging advice there.

I tested the SafeRoom test suite on a Wileyfox Swift, which has that CPU, and the tests passed. However, the Swift is running 6.0.1, not 5.0.2.

FWIW, this page lists a hundred or so device models with that CPU. Personally, I do not appear to have a device (among the ~60 that I own) with that CPU that runs Android 5.x, let alone specifically 5.0.2.

i have UnEncrypted room db with version v1 i tried to upgrade to version v2 via room migration

i added new column in entity class apart from my earlier columns, also altering table during migration by adding new column.

@ColumnInfo(name="RubberStamp",typeAffinity = ColumnInfo.BLOB)
    private byte[] RubberStamp;

Migration callback works perfect without usingSQLCipherUtils.encrypt & openHelperFactory(factory) with existing database

but when same code is used with SQLCipherUtils.encrypt & openHelperFactory(factory) , room creates new Database/tables with version2 onCreate is called, not the migration code. all old will be lost.

@Database(entities =
        {
                Article.class
        },
        version = 2,exportSchema = false)
private static final String      DB_NAME = "mydb.db";
    private static       APPDatabase INSTANCE;
    public abstract      APPDao      appDao();
    private final static SafeHelperFactory.Options options = SafeHelperFactory.Options.builder().build();
    private final static Editable passPhrase=new SpannableStringBuilder("mypassword");

    private final static SafeHelperFactory factory=SafeHelperFactory.fromUser(passPhrase,options);


public static APPDatabase getDatabase(Context mContext)
    {
        if(INSTANCE==null)
        {
            INSTANCE=BuildDatabase(mContext);
        }
        return INSTANCE;
    }


private static APPDatabase BuildDatabase(Context mContext)
    {
        
        SQLCipherUtils.State sqlCipherUtils= SQLCipherUtils.getDatabaseState(mContext,APPDirectories.DATABASE_PATH+DB_NAME);
        if(sqlCipherUtils==SQLCipherUtils.State.UNENCRYPTED)
        {
            try
            {
                Log.e("Encryption","Started");
                SQLCipherUtils.encrypt(mContext,new File(APPDirectories.DATABASE_PATH+DB_NAME),passPhrase.toString().toCharArray());
                Log.e("Encryption","Finished");
            }
            catch (IOException e)
            {
                e.printStackTrace();
                Log.e("init","Error in DB Encryption");
            }
        }

        return Room.databaseBuilder(mContext,APPDatabase.class,APPDirectories.DATABASE_PATH+DB_NAME)
                .openHelperFactory(factory)
               
                .allowMainThreadQueries()
                .addCallback(new Callback()
                {
                    @Override
                    public void onCreate(@NonNull SupportSQLiteDatabase db)
                    {
                        Log.e("onCreate","Called");
                         //super.onCreate(db);
                    }

                    @Override
                    public void onOpen(@NonNull SupportSQLiteDatabase db)
                    {
                        Log.e("Version",String.valueOf(db.getVersion()));

                        //super.onOpen(db);
                    }
                })
                .addMigrations(new Migration(1,2)
                {
                    @Override
                    public void migrate(@NonNull SupportSQLiteDatabase database)
                    {
                        Log.e("Migration","Migration Called");
                        String query="ALTER TABLE Articles ADD COLUMN 'RubberStamp' BLOB DEFAULT NULL;";
                        try
                        {
                            database.execSQL(query);
                        }
                        catch (Exception ex)
                        {
                            
                        }
                    }
                })
                .build();
    }

Kidnly give me solution as soon as possible

please host some sample apps.

@raveesh08 I recommend that you replace:

String query="ALTER TABLE Articles ADD COLUMN 'RubberStamp' BLOB DEFAULT NULL;";

with:

String query="ALTER TABLE Articles ADD COLUMN 'RubberStamp' BLOB;";

That will have your table match what Room expects. With Room 2.2.0, you could try using defaultValue in your @ColumnInfo annotation, if you want the SQL to use a DEFAULT value.

In terms of reproducing your problem, here is my latest attempt:

RoomMigration.zip

You will find three projects in that directory:

• V1/Notes/ contains a small Room project, including a "test" that saves a couple of rows to a database file
• V2/Notes/ contains the same project with a schema change and a test that demonstrates upgrading the schema via a Migration
• V2Encrypted/Notes/ contains a variant of V2 that encrypts the V1 database, then opens it using Room and SafeHelperFactory

All tests succeed, including the one that does the encrypt-then-migrate scenario.

At this point, I am closing this ticket as not reproducible. If you can give me a complete set of code and instructions for reproducing your problem, I will be happy to take a look at it.

I can't figure out how to build a jar for this project, but this setup is supposed to work and automatically provide the right proguard rules for anyone using R8 or proguard v6+ (bundled with AGP 3.2+)

Sorry, but I have elected to discontinue work on this library.

As I note in the revised README, for certificate pinning, consider just using OkHttp and its built-in support for certificate pinning. If you need certificate pinning elsewhere, consider TrustKit-Android.

@pmolcany If you can provide me:

• the Android OS version on which you are experiencing the problem
• the code necessary to reproduce the problem (this could be the repo's demo app, or it could be some demo project of yours that you publish)
• the steps necessary, using that code and that version of Android, to reproduce the problem

...then I can try to reproduce the problem.

@kuFEAR That would further suggest that the problem lies in the newer versions of SQLCipher for Android. SafeRoom 0.x used SQLCipher for Android 3.x. SafeRoom 1.x uses SQLCipher for Android 4.x.

@kuFEAR It is unlikely that this has anything to do with SafeRoom itself, as SafeRoom has no dependencies on things like CPU architecture. SQLCipher for Android may have issues with that particular CPU. You may wish to inquire on the SQLCipher discussion board whether there are known problems with that CPU.

Here is the stack trace I have been getting in Crashlytics

The stack trace indicates that you are trying to open a database that either is:

• Not encrypted
• Encrypted with a different passphrase than the one that you are using
• Not a recognized database (e.g., data corruption)

This error is coming from SQLCipher for Android. By design, for security reasons, it does not indicate which of those three scenarios occurred (and, in many cases, it cannot tell, anyway).

When I download the app directly from the Play Store, I see that I have about 15 MB worth of User Data

That cannot have come from SafeRoom, as none of your code will have been executed immediately after your app has been downloaded.

For some odd reason, this issue is only happening in my device.

If you have android:allowBackup="true" in your <application> in the manifest, perhaps it is some past file that Android/Google are restoring.

I am not sure if somehow SafeRoom is saving the encrypted data in a database outside of the app

The database will go wherever you told your RoomDatabase to put it. SafeRoom itself is not involved in that decision.

completely removing the app and re-downloading the APK did not resolve the issue

Sorry, but I do not understand what you mean by this.

The passphrase has not changed either.

FWIW, the passphrase should be unique to each user, either coming from the user themselves or from some encrypted file secured by their device.

Has this been reported in the past?

I am not quite certain what the scope of "this" is. The stack trace is fairly common in SQLCipher for Android use.

I can provide more information if needed.

This repository comes with contribution guidelines, including instructions for filing bug reports. If you feel that this is a bug in SafeRoom specifically (and not in SQLCipher for Android), I need steps to reproduce the problem.

This feels like a support question, which could be better handled elsewhere.

@andrew-koster- As I commented earlier, I was able to use DB Browser for SQLite on macOS to open a database. Outside of that particular instance, I can't recall the last time that I needed to access an encrypted database from something other than the app itself. I am sorry if my particular development approach is atypical.

Other than that, make sure your database is closed before you try copying it, and if you see that there are multiple files (e.g., db and wal and stuff), copy all of them. And, if you can give me a project that reproduces a problem, I'll be happy to look at it.

I cannot do that in an instrumented test. The schema version is part of the @Database annotation, and I cannot replace it at runtime. That is why I needed two RoomDatabase classes. Similarly, I needed two @Entity classes so that I could introduce a schema change.

Your scenario will also require two RoomDatabase classes and two entity classes — it is just that in normal development, those two versions will be the same file, changing over time. There is no practical way that I can think of to do that in an automated test, other than by the approach that I took.

A way for you to provide a reproducible set of code that mimics your situation is:

• Create a project
• In that project, implement the code that represents your "before the encrypt-and-migrate" state
• Make a copy of that project
• In the copy, modify the code to handle your encrypt-and-migrate scenario (notably, do not change class names, applicationId, etc.)
• Confirm that if you run the first project, then run the second project, that the problem occurs
• ZIP up both projects (note: you may need to delete the build/ and app/build/ directories in the ZIP files to get them small enough)
• Attach those ZIP files to a comment on this issue, preferably with some instructions

If you do not do that, I might eventually try it myself, but that may not be for several weeks.

I need either:

• A complete project that can reproduce the problem (or 2 if you cannot reproduce it with just a single project), or
• A similar test case that can reproduce the problem, or
• If the test crashes in your environment, the details of that environment (e.g., library version, device that you are testing on), or
• Detailed instructions on how I can modify this test case to reproduce the problem

From Room's standpoint, the name of the RoomDatabase class should not matter.

I added a test of encrypting an existing database, then migrating it. The test works fine.

At this point, I need either:

• A complete project that can reproduce the problem, or
• A similar test case that can reproduce the problem, or
• If the test crashes in your environment, the details of that environment (e.g., library version, device that you are testing on), or
• Detailed instructions on how I can modify this test case to reproduce the problem

If the root you’ve chosen to sign your certificate is not trustworthy, you should choose another root.

I suspect that few developers have the ability to determine whether a particular root certificate authority is or is not trustworthy. Also, "trustworthy" itself is somewhat nebulous. For example, if the attacker is able to get a fraudulent certificate via apparently legitimate means (e.g., law enforcement requests), is that certificate authority now somehow not trustworthy?

IMHO, a better framing is in terms of the abilities of an attacker:

• If an attacker can obtain a fraudulent certificate, but only from an authority of their choosing (e.g., one where they have successfully bribed the right people), then pinning the root certificate of your CA may be acceptable. It comes down to the number of potential attackers who might try pulling off this sort of attack.

• If the attacker can obtain a fraudulent certificate from a wide range of authorities ("nation-state level adversary"), pinning at the root CA level will be less effective.

Or, in matrix form:

Most apps should in the few/weak attackers quadrant, so pinning the root certificate should be fine (exemplary, even). For any individual project, it's a matter of coming up with your "threat vectors" and deciding which quadrant you are in, and whether you are in position to deal with the challenges of pinning the site certificate.

My best guess is that they are doing ProGuard/D8-style bytecode manipulation, and they have a bug that trips over something that I am doing. My code isn't too unusual — SafeHelperFactory in particular is rather boring.

If you have not done so already, you might contact the MDM and inquire about this, or have them reach out to me and perhaps we can figure out a solution together.

What you are describing should work. I already have a test case for migrations, but I do not have a test case for encrypting a database and then immediately triggering a migration. I will work on a test case for that this weekend. If the test case fails, I can try to fix the bug. If the test case succeeds, you will be able to see what I did and see if you can adjust your code to match mine.

onCreate() is called when the database is created for the first time. See the documentation. It will not be called for a migration, as the database already exists.

onCreate is called not the migration code

There is no onCreate() in a Migration, so I do not know what you mean by this.

Migration callback works perfect with doing SQLCipherUtils.encrypt & openHelperFactory(factory)

You seem to be using SQLCipherUtils.encrypt() and openHelperFactory(factory) in the code in the question. I do not know what the difference is between what you believe works and what you believe does not work. And, I do not know if the code that you included in this issue works or does not work.

But after... implementing the generated .aar file in my project

How exactly are you doing this?

From your symptoms, my guess is that you copied the AAR into some directory (e.g., libs/) and are adding it to the project Gradle file via a statement like implementation fileTree(dir: 'libs', include: ['*.jar']). If so, that will not work for most AAR files. That approach only adds the AAR itself, not any transitive dependencies. The pre-built AAR is distributed via a Maven repository, with a POM file that contains a list of the transitive dependencies, so Gradle knows to download them. You would need to decide how to include those transitive dependencies in your project. One simple but crude approach is to copy the relevant lines from the library's build.gradle file into your own (in this case, implementation "androidx.sqlite:sqlite:2.0.1").