By means of "recycle bitmaps", I assume that you mean calling .recycle () on a Bitmap object.
Why do you think this will improve your OOM situation? Although I will admit that once upon a time Android (i.e. 2.x) really suffered from this problem. Raster images were stored in the native heap and required (at least) 2 GC passes to clear. Calling recycle () sometimes improved the situation.
Starting with Android 4.x 3.0, this has been a problem.
Note that the documentation addresses an extended call that is not commonly used: http://developer.android.com/reference/android/graphics/Bitmap.html#recycle ()
Regarding your recommendation for disposing of Bitmap in onDetachedFromWindow (), this seems like a bad idea. This method is called when the View is detached from the window, and there is no guarantee that the View will not be reattached later. If we redesigned Bitmap into onDetachedFromWindow (), we would throw an exception if the view was ever bound to the window again.
Also, if it were necessary, I would have thought that ImageView itself would handle it.
And for recording, Volley handles OOM well with the help of trying to scale the image at the viewing boundaries and only allowing one stream to decode the bitmap at the same time.
I suspect you have other problems causing your OOM ...
------------ EDIT ---------------
After commenting on the comment of Android developers, I updated my answer. Volley does not automatically scale the image within the view, but it supports it in ImageRequest (see Constructor: https://android.googlesource.com/platform/frameworks/volley/+/master/src/com/android/volley/toolbox/ ImageRequest.java with maxWidth and maxHeight)
This means that you will need to modify the NetworkImageView to use the correct ImageRequest constructor (you need to be careful to measure the view first)