I would suggest you to run your app and use all activities your app contains of and also switching orientation several times, then exit the app and trigger a GC (there's buttons for all of this) after that dump a hprof (this asumes you are using Eclipse) and fire the leak suspects report, use the histogram button to view what allocations have been done and sort of #objects (try to filter on your package name since String / byte[] etc tend to dominate such a leak suspect report even though the don't have to be leaks). A guide to: debugging memory in Android.
As for your questions to those specific classes (when i say, "could leak a context" i mean activty context, since application is singleton):
Notifications are preferably handled by the Notification.Builder, that one takes a context so holding on to notification in a static variable could leak a context
PendingIntents are obtained from helper methods where context are sent in see PendingIntent could leak context as well
BroadcastReceivers can be registered in manifest (not leaking context here) or at run time, if you are not unregistering in onPause (registering in onResume) you could leak the BroadcastReceiver which in turn leaks the current activity context (this)
SharedPreferences are fetched from the current activity if your activity gets recreated there might be a leak as well
This is a hard topic, that's why i suggest you to profile your are app i suggest in the top of this answer. Other than that i don't quite get the point of holding on to several of the asked classes as static instnace variables, what do you want to achieve with that? Especially if you are not sure if you leak contexts or not.