Sampling rate refers to the number of samples per second from the microphone audio. TuneLab for Android requests a sampling rate of 22,050 samples per second from the device. If the device cannot satisfy this request, TuneLab will display an error message immediately, so you would know that TuneLab cannot run on that device.
However, that is not the end of the story. It turns out that a few Android devices (both tablets and phones) will tell TuneLab that it can satisfy that request, even though it can't. And so there will be no error message. So how does the device get away will promising us 22,050 samples per second and then failing to deliver on that promise? They do it by cheating.
Here is how the cheat works. Such devices typically are sampling the microphone at 8000 samples per second, which was the old standard cell phone audio sampling rate, back before the days of smartphones. 8000 samples per second was good enough to render voice intelligible, but was otherwise not quite up to the modern standards of high-fidelity sound that is in common use today. So if these devices only get 8000 audio samples per second from the microphone, how can they give TuneLab 22,050? They do it by duplication. Each of the 8000 audio samples is duplicated 2 or 3 times (2.75625 times on average) to expand the 8000 samples to 22,050. So TuneLab gets 22,050 samples, but many of those samples are duplicates.
What is the effect of this duplication trick? Well, here we have to get into a fact about digital signal processing. When you have 8000 samples per second, you can only detect frequencies that are half of that, i.e. 4000 Hz. What is more, any frequency on one side of 4000 Hz has an "alias" frequency on the other side of 4000 Hz. It is as if a mirror is placed at 4000 Hz, so that anything that happens on one side is mirrored on the other side. For example, if the microphone hears a tone at 4100 Hz, after it is sampled that tone will appear the same as a tone at 3900 Hz. In fact, the Spectrum Display in TuneLab will show two peaks in the graph - one at 4100 Hz and the other at 3900 Hz. And if the original frequency were 3900 Hz, you would get exactly the same two peaks. There is no way to tell which peak in the spectrum is "real" and which is the "alias".
Duplicating each sample 2 or 3 times after it is taken does not "fix" this problem. So even though TuneLab thinks everything is fine, the Spectrum Display (and the Phase Display too) will behave very oddly for frequencies around 4000 Hz, which just happens to be near the pitch of the note B7 on the piano. What you will see on this device is two very closely spaced peaks in the Spectrum Display when you play B7. And when you play C8 you will see peaks at C8 and A#7 (the mirror-image frequency on the other side of B7).
You may be able to work around these limitations. When you tune the note, the two peaks will move in opposite directions. One will go up and the other will go down. The peak that moves in the direction you expect is the "correct" one. But this will not be easy to do when the two peaks get very close together at B7. Also this false frequency aliasing means that inharmonicity readings of notes above A5 are going to be more difficult to get. The ideal solution is to get another Android device without this problem if your Android device has this fake sampling rate problem.
The picture below shows what the Spectrum Display looks like when playing a single string that sounds at 3950 Hz. on an Android device with this false sampling rate problem: