En una versión simplificada de mi aplicación, tengo dos actividades, A y B. La actividad A comienza con B, y después de algunos trabajos, B termina (). El uso de la Herramienta de análisis de memoria en la mayoría de los dispositivos (Galaxy Nexus con 4.2, Droid 4 con 4.0.4 y Droid 2 con 2.3.4) no muestra ningún rastro de la actividad B, que es lo que esperaba.

Pero en Samsung S3 con 4.1.1, MAT muestra los objetos de la actividad B que todavía existen, debido a las rutas a las siguientes raíces de GC (excluidas las referencias débiles / suaves):

Class Name                                                        | Shallow Heap | Retained Heap
-------------------------------------------------------------------------------------------------
com.myCo.myApp.ActivityB  @ 0x42720818                            |          264 |         3,280
|- <Java Local> java.lang.Thread @ 0x4271cf60  Thread-21941 Thread|           80 |        52,264
|- mOuterContext android.app.ContextImpl @ 0x426adf68             |          104 |           784
    |  '- mContext android.media.AudioManager @ 0x428e49a0        |           48 |           152
-------------------------------------------------------------------------------------------------

Cada vez que comienzo y detengo la actividad B, MAT muestra otra instancia de la huella de memoria de la actividad B. Y cuanto más abro / cierro la actividad B, mayor es la huella de memoria notificada en logcat. Forzar un GC a través de MAT no elimina las referencias a la memoria de la actividad B.

Tengo tres preguntas.

¿Por qué el comportamiento de la memoria / GC es diferente en los diferentes dispositivos?

En S3, ¿el sistema operativo finalmente regresará y cambiará los objetos de la actividad B varados (en otras palabras, no debería preocuparme por eso porque Android lo limpiará antes de que se produzca un fallo)?

Si no es así, ¿de dónde provienen las referencias de Thread y AudioManager, y cómo puedo eliminarlas?

Gracias a todos los "cazadores de fugas" con experiencia que hay!