Develop Reference

How come BLE ScanCallBack is being retained and not being GC'd?

I'm not sure if it's my code, but I just noticed in the heap dump I record with Android Studio profiler that when I start setting my variables to null to free up the reference to an object. The object itself is still allocated, and when I check the Android profiler I see that it is due to my ScanCallback. This means every time I do the following logic:
var sensorScanner = SensorScanner(bleAdapter)
sensorScanner = null
my number of allocations keep increasing by 1, but it should not be doing that. If I call that line 24 times, I see 24 allocations.
If I were to comment out the following code in my SensorScanner():
bleAdapter.bluetoothLeScanner.startScan(scanFilters, scanSettings, scanCallback)
the number of allocations will stay at 1 which is what I expect. So if I did 24 allocations experiment again, the allocation stays at 1 when I view the heap dump.
It's weird because I also don't see any exposed methods from the bleAdapter that would allow me to clear the callback.
Thank you for viewing my question, if anyone has some thoughts or tips please share them if possible.

This is the method you must use to stop the scan:
https://developer.android.com/reference/android/bluetooth/le/BluetoothLeScanner#stopScan(android.bluetooth.le.ScanCallback)
Pass the same callback object you used when you started the scan.

How do I run a Performance Trace multiple times in Parallel?

I have a Firebase Performance Monitoring trace called my_trace.
Now, I start this trace when I load an image:
void loadImage() {
final Trace trace = performance.newTrace("my_trace");
trace.start();
// ... (loading that happens asynchronously)
trace.stop();
}
This works fine when I try to load a single image, however, in my application I need to load many images in parallel.
This means that the following error is reported when I load my images:
Trace 'my_trace' has already started, should not start again!
How do I correctly start a trace multiple times in parallel as I want to record the performance of every single loading process?
Note: I cannot use HTTPMetric as the loading trace also contains image conversion and not just downloading.

You can record it manually by storing the start time yourself and then just recording the duration. This should work.
Reference: https://firebase.google.com/docs/reference/js/firebase.performance.Trace#record

As the error message says, there can only be a single trace with a unique name active at any time. So you'll either have to wait for the first my_trace to finish before starting the second (running them sequentially instead of in parallel), or you'll have to generate a unique name for each trace.
Given how the API is structured it should be possible to allow multiple traces of the same name to run in parallel. If you think Firebase should consider allowing that, I recommend you file a feature request.

Traces are allowed to run in parallel already. Traces are not indexed by trace names. As long the trace object is unique, you should be able to run traces in parallel. Same trace object cannot be re-used.
Eg: (Incorrect way of using trace object)
final Trace trace = performance.newTrace("my_trace");
trace.start();
trace.start(); // This would not work. Fails with the error message that the trace is already started.
// ... (loading that happens asynchronously)
trace.stop();
Eg: Right way using the same trace name multiple times in parallel.
final Trace trace1 = performance.newTrace("my_trace");
final Trace trace2 = performance.newTrace("my_trace");
trace1.start();
trace2.start();
// ... (loading that happens asynchronously)
trace1.stop();
trace2.stop();

Syscall in android NDK

I have tried to use the this syscall macro for arm_64
It works with SYS_open, read and close. I can see the file content properly.
After that Android APK crashes with the following message:
A/libc: stack corruption detected A/libc: Fatal signal 6 (SIGABRT) at
0x00007689 (code=-6), thread 32141 (Thread-2910)
Does anybody knows how to fix it?

You have at least one bug in the code on the Godbolt link you posted. These statements lead to a buffer overflow (surrounding code and if() conditions removed.)
char buffer[2048];
length = syscall_read(fd, buffer, sizeof(buffer));
buffer[length] = 0;
buffer[length] = 0; accesses outside the array if sys_read returns 2048. As the man page says, read() attempts to read up to count bytes, not count-1. This could account for your stack corruption if the array was allocated right below something important.
You have to leave room for a 0 terminator if you want to use it as a C implicit-length string instead an explicit-length buffer+size with write or memcpy or whatever. Remember that file data can contain 0 bytes.
As usual, use a debugger, and make sure your code works with normal system calls as well as your inline wrappers.

How do I measure FPS of an android application that uses TextureView? (Am using OpenGL)

I have an infinite loop in my Render Thread. I tried measuring assuming that every call to eglSwapBuffers draws a new frame, but that is giving me results like 200 fps, which is not possible, right? The refresh rate cannot exceed 60?
Now I am doing the same thing but also using surfaceTexture.getTimeStamp() of the surfaceTexture of the SurfaceView. I consider a frame as having been drawn only if the timestamp returned in the previous iteration is not the same as in the current. Is the an acceptable way to measure? This is showing 50-55fps when I do no drawing. ie the loop has only eglSwapBuffers() and the getTimeStamp calls.

The surfaceTexture.getTimeStamp() seems to be giving the correct result. I tested it by adding up all the differences between results returned by consecutive getTimeStamp() calls and it is equal to the total time the code ran for. This indicates that no frames are being left unconsidered etc.
Another solution I found is this Android app. I do not know how it works but it is giving approximately the same results as the above method.

Android AsynkTask causes StackOverflow

I'm facing a big problem. My app is loading XML files (within AsyknTask) from the net and parses them into an local SQLite Database. The problem is after approximately 22 Files and app. 1500 inserts the whole thing crashes with this error:
threadid=8: stack overflow on call to Ljava/lang/String;.hashCode:I
method requires 40+20+0=60 bytes, fp is 0x428cc320 (32 left)
expanding stack end (0x428cc300 to 0x428cc000)
Shrank stack (to 0x428cc300, curFrame is 0x428cc334)
Any idea?
I can parse 20 and then 20 again but not 40 at once.
The content gets cached into an ArrayList and then gets
inserted into the database at the end of each file..
I hope there is a solution or I'm scr** :)
Cheers Ed

The level of recursions was too deep.
The OS crashed approximately within the 23 recursion with an StackOverflow.
Changed it to iteration and everything is fine now!
THANKS!