APK?
How do you verify that the crash occurs during "Register For" ?
What we can do is output to a file, step by step.........
Can you upload your Project and Sketch files for us to check?
yes i download the project as an APK file and transfer it onto my mobile using USB then install it.
I disable the RegisterFor block and then open the app on my mobile...
The above does not crash, but as soon as the RegisterForInteger is enabled it always crash. Same with the other RegisterFor blocks... and also the same if i use a ReadInteger block etc.
Here is the aia project file:
Fresh.aia (201.1 KB)
and here is the Arduino sketch ino file:
BLE_Nano33.ino (2.5 KB)
Right now i have removed as much as possible to keep the program/app as simple and easy to read as possible.
All i want is to be able to open the app on my Galaxy S22 and receive an integer from the ardruino.
Connecting using BLE works fine and i can also send variables from the app to the arduino, but not the other way around.
By the way do i need to do anything special with the BLE block icon?
Is the above ok?
I already played around a little and test NoLocationNeeded, but i got the same result.
That's fine. You are not the only developer with a Samsung S22 BLE issue, but I don't think it's the phone at fault.
Have tried a Read Block instead of a Register Block? I made a simple Project for you.
Yeah i've tried adding a clock that calls the ReadInteger block after 10 seconds... the app connects correctly to the arduino, and then after 10 seconds (minus the seconds it take to connect) it crash. And Disabling the ReadInteger block fixes the crash issue like always.
You can simply scan the QR code, App Inventor will use WiFi to send the APK to your phone.
I apologize as I haven't had time to read the thread in its entirety, but have you power cycled the Bluetooth stack on the phone (usually turning Bluetooth off and on is sufficient)? The typical BLE use case on Android involves the UUIDs not changing so the OS caches the services/characteristics advertised by the device. If you changed the UUIDs, App Inventor may be making the request but the system says they don't exist since the cache is stale, resulting in the crash.
A second thing, if you're comfortable doing it, is to enable Developer Mode on your phone and then using adb logcat to obtain a stack trace of the crash. This will help pinpoint where the code is failing on your specific device.
I had not tried turning off BLE and on again, but i have tried restarting my mobile phone, i'm guessing that should also do it.
Just to be sure i tried turning off BLE and back on again right now and it's the same result.
I will look into adb logcat and try to figure that out - thanks for the link Chris.
Im hoping to get it up and running during the weekend, but i have a few other plans.. ill fit it in 
I just dug up my old Oneplus3 phone running android 9.
I get the exact same reaction when i run my app on that phone.
I'll look into the adb logcat next
I havnt given up... I'm just a bit busy these days.
I got the Oneplus phone set to developer mode and reading about adb logcat.
Maybe next week.
Hello @App_novice,
Try this inside when BytesReceived
Make sure that the length of the received is equal to or greater than the indexes being accessed.
Also, make sure that the UIID corresponds to the characteristic you expect.
Okay thank you osmany I will try that when I get home Monday 
Hi Osmany.
This is what i tried:
Unfortunately i get the same result.
You're idea works though it would handle the bytes just fine, but my issue is that as soon as the RegisterForInteger block is called my app crash, i dont even reach the IntegerReceived block.
I've tried a few different things and it always comes back to the same result, as soon as RegisterForInteger is called the app crash, even if i have a completely scrapped down simple program that simply connects to the NANO and calls RegisterForInteger.
I think there's no way around it, i have to get adb logcat up and running so i can see what crashes the app.
Dear @App_novice,
Kindly please, don't use RegisterForIntegers, instead use RegisterForBytes. The first one never worked for me.
If you are still sure that when BytesReceived never happens after RegisterForBytes then I don't know what to tell you. Please remove all the BytesReceived code and only leave code that lets you know what happened there (notification or write a label). Calling RegisterForBytes will call BytesReceived async when data arrive.
My point was to check that if you register to receive data, and when receiving it if you use an index out of range the app will crash.
The code I sent you works for when 4 bytes arrive and convert it to an integer, not 4 integers.
Don't give up, keep looking for the cause of the problem.
Best regards,
Osmany
1 Like
Thank you for the advice Osmany.
The app still crash if i change to bytes.
I have also tried altering the code running on the NANO33 dev board so that it never sends any data, but my app still crash as soon as RegisterForBytes or RegisterForInteger is called... any RegisterForXxxxx will crash the app, even if no data is sent/received.
I will have to find some time and get the adb logcat up and running so i can get more information about what is causing the crash, right now my problem is that i get zero feedback... the app just crash.
I also tried adding a clock that waits 10 seconds and then calls the RegisterForBytes. If i do that then the app connects correctly and then after 10 seconds the app crash.
Hi @App_novice
Also try test CanRegisterForCharacteristic before call RegisterForBytes.
Although I read in one of your messages that you were able to register for notifications from nRF Connect.
(Make sure to test that everything works from nRFConnect and remember to disconnect before run your app).
I kindly wish you luck,
Osmany
Oh no !
I found the issue, i had quotation marks around my characteristic UUID in the
BLEIntCharacteristic function, but it was already declared a string in the define above.
The reason I was so focused on the app crashing was that if i use LightBlue or nRFConnect they both worked without issues - but i suppose they must have something that can handle this situation.
Sorry for the hassle @ABG , @ChrisWard, @Osmany_Ferrer_Borges and @ewpatton
//----------------------------------------------------------------------------------------------------------------------
// BLE UUIDs
//----------------------------------------------------------------------------------------------------------------------
#define BLE_UUID_TEST_SERVICE "4fafc201-1fb5-459e-8fcc-c5c9c331914b"
#define BLE_UUID_ACCELERATION "beb5483e-36e1-4688-b7f5-ea07361b26a8"
//----------------------------------------------------------------------------------------------------------------------
// BLE
//----------------------------------------------------------------------------------------------------------------------
BLEService testService( BLE_UUID_TEST_SERVICE );
BLEIntCharacteristic accelerationCharacteristic( "BLE_UUID_ACCELERATION" , BLERead | BLENotify);
1 Like
Ouch! Your Sketch compiled OK so I assume the quotation marks are tolerated by the function too.
It is quite something to find your own tiny bug like that, usually it's very difficult, so I award you this trophy: 
In C, macro expansion happens on tokens. "BLE_UUID_ACCELERATION" would be a string so wouldn't be subject to token expansion by the preprocessor. In theory, the library handling the UUIDs on the Arduino should have indicated some sort of error, but that's much harder to do in an embedded environment since that's not a valid UUID.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.