Anomalous memory consumption when specifying different applicationIds. What to do?

Question

Android

Ran into a strange thing. I looked into the Android Monitor to see the memory consumption, for some unknown reason, the memory flowed smoothly and slowly from 9 M to 15 M, followed by cleaning with a scavenger and a new one. Nothing happened in the application at that moment. Piece by piece I commented on the code looking for a leak. And I reached the limit - pure activity and manifesto. The memory was still leaking.
I created a clean application in the studio using a template with an applicationId chosen at random. I start, the memory is rooted to the spot. I dragged everything from the example into my project, the memory still flows with the same character.
Next came the rooftop. In this freshly baked virgin test project (!) in defaultConfig, I replace applicationId with the id from the working project. Your division, the memory has flowed! And one to one.
I replace applicationId back - memory costs. And so several times.
The working project was yesterday filled with alpha on the play. I thought that perhaps Google somehow attaches something on the device to my process for projects from the play to evaluate the behavior (well, what else can you think of?). I began to try to change the id of my published projects to other ones and watch the consumption. The memory is worth it. Jumps only with one specific package name.

// applicationId "com.*****.swf"// 10.79
// applicationId "com.*****.*****off"// 8.47-15
// applicationId "com.*****.*****lock.free"// 9.04 | 11.12 | 9.65
// applicationId "com.*****.*****lockplus"// 10.41 | 11.30
   applicationId "com.*****.*****_off"// 11.43 | 9.99-7.83

Interestingly, for example, an application with a package name with swf consistently consumed 10.79. Checked on restarts. Consumption with other package names is also visible. And that unfortunate name "com.*****.*****off" that started it all.
At random, I settled on the package name "com.*****.*****_off". It either stays stable at 11.4 MB or drops to 7.8 MB and stays there. It was enough just to add the symbol _.
All this on the 6th Android (LG) and the newest stable studio 2.2.3. Application from studio template - "Basic Activity".

apply plugin: 'com.android.application'

android {
  compileSdkVersion 25
  buildToolsVersion "25.0.2"
  defaultConfig {
    applicationId "com.*****.*****_off"
    minSdkVersion 21
    targetSdkVersion 25
    versionCode 1
    versionName "1.0"
    testInstrumentationRunner "android.support.test.runner.AndroidJUnitRunner"
  }
  buildTypes {
    release {
      minifyEnabled false
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
  }
}

dependencies {
  compile fileTree(dir: 'libs', include: ['*.jar'])
  androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
    exclude group: 'com.android.support', module: 'support-annotations'
  })
  compile 'com.android.support:appcompat-v7:25.1.0'
  compile 'com.android.support:design:25.1.0'
  testCompile 'junit:junit:4.12'
}

Pictures of memory consumption of the same empty application .
with a jumping package name: "com.*****.*****off"

with a package name: "com.*****.swf"

UPD. In one experiment, I changed the name of a jumping instance live (from "com.*****.*****off" to "com.*****.swf"), without restarting, as the studio can do, and gradually cleaning after cleaning by the scavenger, the memory dropped to 8.5 MB and calmed down. This can be seen in the picture below.

Answer 1

Memory leaks - this is when it is allocated but not released, for example, we hold a link to an activity somewhere. Turned the device - the current activity is stopped, launched again, but in a different orientation. In theory, the old activity instance should be removed from memory, but the link does not allow the GC to do this. Rotating your device multiple times will cause you to have a lot of activity instances in memory. And you do not have a leak, but the normal mode of operation of the application.
Who is memory? Monitor memory consumption and eat it. And then frees. This is fine. Similarly, the FPS counter reduces FPS. On the other hand, it's not very clear to me why some package names consume less memory. I would look at dumps and allocations.

Answer 2

• In the studio, right where the memory is, there is a "Start Allocation Tracking" button. This tool shows which instances are being created.
  
• When approaching the peak value, you can take a memory dump and figure out who eats the most.
  
• And you can also try to run on a clean emulator and run everything again. Maybe on a rooted device? Viruses? Antivirus?