В упрощенной версии моего приложения у меня есть два действия: A и B. Actvity A начинает B, а после некоторой работы B вызывает метод finish (). Использование инструмента анализатора памяти на большинстве устройств (Galaxy Nexus с 4.2, Droid 4 с 4.0.4 и Droid 2 с 2.3.4) не показывает никаких следов активности B, чего я и ожидал.

Но на Samsung S3, работающем под управлением 4.1.1, MAT показывает объекты активности B, которые все еще существуют, из-за путей к следующим корням GC (исключая слабые / мягкие ссылки):

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
-------------------------------------------------------------------------------------------------

Каждый раз, когда я запускаю и останавливаю упражнение B, MAT показывает другой случай следа памяти в занятии B. И чем больше я открываю / закрываю действие B, тем больше объем памяти, указанный в logcat. Принудительный сбор GC через MAT не удаляет ссылки на память действия B.

У меня три вопроса.

Почему поведение памяти / ГХ различно на разных устройствах?

На S3 вернется ли ОС в конечном итоге и GC заблокирует объекты активности B (другими словами, не стоит ли мне беспокоиться об этом, потому что Android очистит его перед сбоем)?

Если нет, откуда берутся ссылки на Thread и AudioManager и как мне их очистить?

Спасибо всем опытным «охотникам за утечками»!