Hopefully this post will serve as a helper for anyone who runs into a similar issue, but here is the problem I recently encountered:

Background

We roll our own facebook login fragment and have made it relatively similar to the samples from the 3.0 sdk. The fragment is a setRetainInstance(true) fragment and it is expected that the callbacks from the facebook SDK will be delivered to the fragment in question. The login process would be kicked off in the onCreate() method of the fragment like so:

This only seemed to occur on the first login/authorize attempt for a user, where no cached access token existed in FB or our local cache. What would happen is that when the user accepted the read permission request, the facebook SDK would call our callback but our fragment would not perform any additional processing because we guarded the additional work in a check like so:

if (isResumed()) {
// Do processing (adding fragments, etc...)
}

We were seeing fragment transitions from paused to resumed, but it was on a new instance of the fragment, not the one that kicked off the login attempt. When I removed the check for isResumed() during debugging, the code would crash due to the fragment not being attached.

The Reason
The thing that we found is that you absolutely CANNOT perform the session initialization from the onCreate() method of the fragment due to the fact that facebook will launch it's own activity, which will cause the fragment to be made inactive by the FragmentManager (which causes a new fragment instance to be added to the fragment manager when our activity resumes). This occurs because the FragmentManager does this when initializing the fragment: