Android Traceview (Sampling based trace) doesn't reflect the actual number of function calls

I'm profiling a function within an app which is executed every 5 seconds. However, I only see half of the calls in the "Calls + Rec/Total" option in the trace view. I am using samplebased profiling with 1 microsecond as a sampling interval. I tried to play with this sampling rate but no visible improvements. For example, when I run the view for 236 seconds, I should get 47 calls in the "Call + Rec/Total" option, however, it shows only 20 as shown in the picture below. Can anyone comment what I am doing wrong ?

Tested devices: 
Device 1: SmartWatch LG R (Android 6.0.1), observes this problem
Device 2: Samsung Galaxy S2 (Android 5.0.1 Custom ROM), observes this problem
Device 3: Samsung Galaxy S2 (Android 4.4, Custom ROM), works fine 

UPDATE: I installed Android 4.4.4 on the second Samsung (originally with Android 5.1.1) based on my discussion with @kws and now the sampling-based method is working fine with it. However, the smartwatch with Android 6.0.1 is still behaving the old way with trace view.

Update 2: I think the sampling based method doesn't have the resolution to capture very lightweight functions because it could be that these functions are executed between two samples and it will be missed by this the profiler. Though it records data with microseconds as an sampling interval, I doubt that it can reach to such detailed granularity. The reasoning behind this argument is that when I tested a very lightweight function with it, and not every call was caught on all three devices.

I did some tests and I noticed same behavior here (run on Kitkat and Marshmallow). It seems that if you use sample based profiling and set the sampling rate too low you get inaccurate results. If you increase the sampling rate it is likely to get more accurate results. On the other hand if you use trace based profiling the results are accurate.

I think those sample based profiling results are acceptable since profiler is supposed to return sample results and not the actual ones. As for the case of the 1 μs sampling interval, I think that its successful execution depends on the device also. Maybe a high-end device could produce better results.

Also an important point to be aware of is that according to docs, profiling should not used to generate absolute timings but rather is for checking the results of your code optimization.

Interpreted code runs more slowly when profiling is enabled. Don't try to generate absolute timings from the profiler results (such as, "function X takes 2.5 seconds to run"). The times are only useful in relation to other profile output, so you can see if changes have made the code faster or slower relative to a previous profiling run.

EDIT

If you want more precise results then you have either to go for trace based profiling or you have to use the more accurate Debug class. Using the latter you will be able to specify exactly where to start and stop logging trace data in your code. More info here.