I am trying to integrate Google Analytics in my Activities. As per the official documentation i used the "Easy Tracker" Library provided by Google and extended my activities from "TrackedActivity" The exact syntax i use is:
EasyTracker.getTracker().trackPageView("/myview"+viewname);
I am getting Null Pointer Exception randomly but Logcat shows "at Google Analytics" and surprisingly not at any place in my code. In some of my activities, I am calling system.gc() function in the onDestroy() method. (Could be the issue) Its supposed to be a singleton object I am worried if its getting garbage collected?
Needless to say as of now my app crashes. What worries me further is that even if i do a try catch or put exception checkers ie. check across null object. I am still worried that my activities might not get tracked even if the Crash is avoided.
Please Suggest.
Make sure that you don't invoke methods of EasyTracker before onStart() of your Activity. Also set ga_debug and ga_auto_activity_tracking to "true" to get debug statements and to track all activities of the application respectively.
Related
I've just started work with Koltin and my question might be a little strange to someone who have more experience,
but how can i see fatalExceptions in logcat? For example, i have an app that is already developed by another dev,
there is an error in one activity - after pressing the button apps crash and restart to main activity.
I don't see any usefull informations in logcat(in fabric also!), moving on trough whole code from listener to fragment and many classess is very time consuming. There must be some way to figure it out quicker, right?
Exceptions should be shown/thrown in logcat, same as with Java.
If the exception is thown within rxjava or a kotlin coroutine, make sure you have defined an error handler, otherwise the exception might get swallowed.
Then make sure you have selected the right app in logcat and that no filter is active.
Also make sure there is no other global Exception handler defined besides fabric.
I'm extremely curious how there is 0 code written within the application and all that is required is to use the library
compile 'com.google.firebase:firebase-crash:9.0.1'
in order to get firebase crash reporting working.
Is the initialization always a one time thing like how the application class' onCreate is always called just once?
What do I do if i want to enable crash reporting only after a certain event?
Update: There is now a comprehensive blog post about how Firebase components initialize.
Firebase Crash Reporting (in addition to other Firebase components) initialize in a ContentProvider that's included into your app automatically. ContentProviders are instantiated first, then your Application subclass, then whatever component was invoked (Activity, Service, BroadcastReciever).
When your project depends on an Android Library project (aar file), all of its manifest entries are merged into your app, so you get this ContentProvider for free simply by declaring declaring the dependency on firebase-crash.
I gave a talk at Google I/O 2016 about how this all works. Jump to 16:22 for the beginning of the content specific to crash reporting.
Unfortunately there is currently no way to programmatically enable or disable crash reporting, but that is coming soon.
So basically when I'm using Firebase Crash Reporting then I'm forced to do initialization in ContentProvider. My app have 2 processes because of this and if I do init in Application.onCreate then it's called twice - once for each process. But other processes don't care about my init code so I don't want to do it twice. So I can use a ContentProvider or check current process name.
Or maybe there is anything else that I'm missing?
I'm building an app that sometimes crashes, I want to know that it crashed in the next time I opened it so I can suggest to the user some post-crash options.
How can I detect the crash?
Also I want to be able to save the user's work before it crashes, I means real time detection of crash, can I do it without knowing where it crashed?
You will need to know where it crashed in order to set the try/catch blocks in the right place to, er, catch the crash and save the data or whatever you have in mind.
This is known as "graceful" termination if you want to consider it in more detail.
Unfortunately neither Java destructor/finalize methods nor lifecycle methods such as onDestroy are anywhere near as robust as try/catch blocks so I'm afraid that is your only option, and how many of us deal with exception prevention. No-one would wittingly provide a user experience that crashes, much less with loss of their data.
Take a took at the ACRA library. You can configure it so whenever a crash happens you can control it and even send the crash log by email
You can use try/catch blocks, then send details on the Exception in your catch.
There are implement UncaughtExceptionHandler as mentioned in these answers and write crash report in some file or use it another way.
ACRA is already mentioned.
However for paid version, I found BugSnag is very good at this.
Or if you want to take the extra mile, try AppSee.
AppSee even has video recording session of how the crash happens. It is from tapping that button on the second list, the menu button or even when the user slides left in your viewpager.
I've recently started using Crashlytics to monitor my app performance, however, I've noticed several occasions where my app would crash, but no crash report was sent to my dashboard.
This article says that it's okay to call Crashlytics.start() inside a Base activity class, but doesn't suggest it as a best practice.
I'm curious if not doing so would result in missing crash reports? I'd rather not make unnecessary calls if I don't have to. Currently I'm only calling Crashlytics.start() inside my app's launch activity specified by my androidmanifest.xml file.
I'm curious as to what happens when the user closes my app (by pressing the home button or launching a different activity) and the GC disposes of my activity while it's in the background. When the activity gets recreated and there is no call to Crashlytics.start(), will I be missing those crash reports?
If you don't want to lose any crashes, it is recommended to put the start() call as soon as possible.
And because the Application class is the first class to be instanced when you start your application, its onCreate() method is exactly where you should initialize the library.
If you refuse to do so, you may lose crashes related to your main Activity's inflation, for example.
I am implementing a billing service based on the Dungeons sample (which is the way Google recommend you go about it). It's slightly complicated by the following facts:
The main service class lives in a library project (because I want to reskin the code many times). As this stackoverflow answer suggests a service in a library project may cause problems, I have made the service abstract and inherited it in the sub-projects; this also lets me use different public keys for each reskin (which is desirable).
There are plenty of UI elements that need to know if billing is supported as soon as possible.
Consequently I am calling a function to check if billing is supported from the onCreate() method of the first activity run (actually any activity, but a preference will then be written so this should only happen once).
In the Dungeons sample, the code to check if billing is supported tries to bind to the billing service thus (from the Service class):
boolean bindResult = bindService(
new Intent(Consts.MARKET_BILLING_SERVICE_ACTION),
this, // ServiceConnection.
Context.BIND_AUTO_CREATE);
this call is throwing a NullPointerException. I've checked pretty carefully and none of these things are null; it's occurring within the function, apparently at line 370 of ContextWrapper.java.
Because of this other stackoverflow answer I wondered if checking billing from onCreate() might be premature but the Dungeons example project, again, calls it from here, so I don't think it's this.
I am using a much later version of Android (3.1) so that might have an effect, but I'd love to know the possible causes of this. One other thing: Eclipse is telling me customIntent is null, but it's not fully clear what that refers to and I've not been able to find much about it.
The answer turns out to be very, very simple: I missed this step in Activity#onCreate:
mBillingService = new BillingService()
//THIS STEP IS THE CRITICAL STEP
mBillingService.setContext(this);
//IF ONLY I HAD KNOWN
mBillingService.checkBillingSupported();
This calls attachBaseContext(context);
It works now :)