I\'m using the latest firebase(9.0.2):
build.gradle:
dependencies {
...
compile \"com.google.firebase:firebase-database:9.0.2\"
c
Just for the record:
We solved the Uncaught exception in Firebase runloop (3.0.0)
by removing following line
//remove this "feature" if you should use it
FirebaseApp.setAutomaticResourceManagmentEnabled(true)
API description:
If set to true it indicates that Firebase should close database connections automatically when the app is in the background. Disabled by default.
(Might be, that we missed some configurations for correct usage of this feature, but App is working as expected after not enabling the ResourceManagment)
This issue has been fixed in version 9.6. Check out the release notes.
However, when we enable the offline capabilities internet connection is still required for our app. Otherwise, write (at least) callbacks are never called.
I know it is an old post , i faced this issue and after some research , i upgraded my gradle to : implementation 'com.google.firebase:firebase-database:18.0.1' This helped the error go away. use the latest library. This Solved My Problem.
We are facing the same issue on version 9.0.2
and 9.2.0
. After many hours of investigation, we found that one way to reproduce this issue is to have a query with fixed endAt
and startAt
parameters. Let me explain with a sample code:
// Firebase dependencies
compile 'com.google.firebase:firebase-core:9.2.0'
compile 'com.google.firebase:firebase-database:9.2.0'
...
public class MainActivity extends AppCompatActivity {
private FirebaseDatabase m_Database;
private static boolean s_persistenceInitialized = false;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
m_Database = FirebaseDatabase.getInstance();
if (!s_persistenceInitialized) {
m_Database.setPersistenceEnabled(true);
s_persistenceInitialized = true;
}
m_Database.setLogLevel(Level.DEBUG);
}
@Override
protected void onStart() {
super.onStart();
long endAt = 100L; // Fixed value: CRASH on third app restart
// long endAt = new Date().getTime(); // Dynamic value: NO CRASH
getGoal("min_per_day", endAt, "some_uid");
}
private void getGoal(String p_goalId, long p_endAt, String p_uid) {
Query ref = m_Database.getReference("v0/data/meditation/goals").child(p_goalId).child(p_uid)
.orderByChild("time").endAt(p_endAt).limitToLast(1);
ref.addValueEventListener(new ValueEventListener() {
@Override
public void onDataChange(DataSnapshot dataSnapshot) {
Log.i("FB", "Snapshot: " + dataSnapshot);
}
@Override
public void onCancelled(DatabaseError error) {
Log.e("FB", "Error: " + error);
}
});
}
}
So the fixed endAt
param will crash the app on third start. I assume queries are cached to disk and then corrupted at some point if we recreate the same query from local cache multiple times (three). On the other hand, if endAt
is not fixed, for example current time in millis, then everything works as expected. The same applies for startAt
query parameter.
I too faced the same issue; After some point of time application was keep crashing on every launch.
For time being I've disabled this database persistance. FirebaseDatabase.getInstance().setPersistenceEnabled(true)
.
I don't see any such strange crashes now!
Hope Firebase team will resolve this issue soon.
UPDATE: It turns out there's another cause of this symptom, as mentioned by Kristijan in the comments. We've identified a bug where if you have a startAt() or endAt() call with an integer endpoint, e.g. startAt(10), it can trigger this sort of cache corruption. This bug will be fixed in the next release of the SDK. In the meantime, you may be able to use non-integer endpoints, e.g. startAt(10.001), as a workaround.
These symptoms match a known limitation with Firebase Realtime Database that prevents it from working if you have persistence enabled in multiple processes in an Android app.
Note that any Application.onCreate()
code will run for every process in a multi-process android app, and so if your app is multi-process, you are initializing Firebase Database with persistence enabled in multiple processes and this is liable to lead to corruption of our offline cache and the hardAssert error that you are reporting.
Keep in mind that sometimes your app may be multi-process without you realizing it. For instance if you're using firebase-crash, it currently creates a background process for the purpose of reporting crashes more reliably, and so if you use firebase-crash, you now have a multi-process app. Other 3rd-party libraries could have similar behavior.
To test, you could add code to your Application.onCreate() something like:
System.out.println('INITIALIZING APP FROM PID: ' + android.os.Process.myPid());
If you see that logged twice in logcat (with two different PIDs) that means your app is running with multiple processes and you're hitting the limitation I mentioned.
As a workaround, you can either:
setPersistenceEnabled()
code from your Application class and put it somewhere that will only be executed in your main process.Note that you'll likely need to clear your app data to get rid of the hardAssert error once you've hit it, as the error indicates that the offline cache has gotten into an invalid state, so to fix it, you must clear it completely.
In an upcoming release, we have added better detection of this scenario so you'll get a much better error message. Additionally, firebase-crash will in the future avoid spawning a 2nd process, which may make this less likely to be an issue.