Telegram VS Android-BLE-Library

Also, if you want to go hardcore: https://github.com/DrKLO/Telegram

Compare https://github.com/signalapp/Signal-Desktop/commits/main with https://github.com/DrKLO/Telegram/commits/master

Here's a good example https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/ui/ChatActivity.java

Forkgram have more features, but not a fork of Telegram-FOSS, is based on official source witch can contain some proprietary blobs

For a couple of updates already I've been noticing this behavior on my Android phone. Telegram support has been silent unsurprisingly, so I've considered opening an issue directly on github, but repo for android client doesn't allow this. I'm out of ideas how to bring attention to this, because I know other android users with the same issue so it's not user-specific

I see this huge C++ file and I raise you a Java file that's so enormous github refuses to render it: https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/...

— Do not use checkboxes and radio buttons in cells. Due to the complex xml structure and internal layers coloring, simple initialization of the checkbox on old phones took a very long time. As a solution, either use the checkbox images (but then they will be without animation), or use a custom checkbox, as for example telegram uses https://github.com/DrKLO/Telegram/blob/master/TMessagesProj/src/main/java/org/telegram/ui/Components/CheckBoxSquare.java Made by analogy on kotlin: https://github.com/ivan200/buyer/blob/master/app/src/main/java/app/simple/buyer/util/views/CheckBoxSquare.kt

It feels like Kable & this https://github.com/NordicSemiconductor/Android-BLE-Library are what people use nowadays. Nothing will ever be perfect though because the API is cursed and samsung are incompetent and petty

This library makes it slightly better.

Android 13 has introduced a new Bluetooth stack [Gabeldorsche](https://blog.esper.io/android-13-deep-dive/#bluetooth\_gabeldorsche) for Bluetooth Low Energy operations. The nature of the Android ecosystem is that Google releases their "bare-bone" Android OS (AOSP), and other device manufacturers (OEM) modify it to meet their hardware requirement criteria. This enables OEMs to choose their hardware components (case in point here, Bluetooth chip-set) without writing the entire OS layer themselves. With the introduction of this stack, developers have started noticing reliability issues while connecting to Bluetooth Low Energy peripherals LE Privacy enabled. These issues were reported to Google as early as Aug 2022. [Issuetracker](https://issuetracker.google.com/issues/242755161?pli=1) If we go by the reported issues, we will notice instances of devices -- 1) [Tesla keys](https://issuetracker.google.com/issues/242755161#comment29) 2) [Garmin smartwatches](https://issuetracker.google.com/issues/242755161#comment42) 3) [Whoop wearables](https://issuetracker.google.com/issues/242755161#comment198) 4) [Polar wearables](https://issuetracker.google.com/issues/242755161#comment309) not working or not working reliably. While some may have been fixed, some wearables still face these issues. To communicate data between a Bluetooth Low Energy peripheral (Bluetooth wearable) and a Bluetooth Central (typical smartphones in our scenario) must transmit command packets between them. These command packets are intercepted at a hardware layer (HCI layer in case of smartphones; similar driver software layer at wearables) over which application layers (Android app in smartphone, firmware layer at wearables) have no or little control. In the ongoing issue, the communication in these layers is breaking, for which we have no data transmission. To resolve this issue, OEMs (both on the smartphone and wearable side) must devise a solution. This raises a question why are not all Android 13 devices and all wearables facing this issue? How does some pair of smartphone and wearable work fine while others do not? The answer is fragmentation in the Android ecosystem; Google Pixel devices and Samsung devices are notably less affected by this issue. Ultrahuman Ring can transmit data when connecting to these smartphones. In some other manufacturers (like OnePlus, Realme, Mi, etc.), while on the Android 13 version of their OS, our Ring faces data communication problems. As stated earlier, OEMs on the wearable side can too take part in resolving this issue. We manufacture Ultrahuman Ring, and our Bluetooth chip manufacturer is Nordic Semiconductors. They write the driver software for talking to a Bluetooth radio. We have notified them of this issue which they have acknowledged, and are in constant communication to resolve it in both [public forums](https://github.com/NordicSemiconductor/Android-BLE-Library/issues/448) and across private channels. We are exploring options to change hardware components or rewrite the entire firmware to circumvent this issue. Still, the nature of the problem remains that it is hard to stipulate a timeline to fix this issue. We understand the frustration and are actively working to find a solution. We want you to know that our website and FAQs need an update to reflect the current situation, and we will update it accordingly. We appreciate your feedback and assure you that we are taking responsibility for this issue. We will update you on any upcoming updates or firmware that will fix this issue. We hope you continue to believe in our product, and thank you for your patience and understanding. Feel free to let me know if you have more questions.

You can use this library. Here is an example app that uses it (the actual code is in the profile_... directories). If you don't use a library you will end up with code like this.

- https://github.com/NordicSemiconductor/Android-BLE-Library

I developed nrf devices as a hobby. This is their basic app. To proceed, I have to decipher Kotlin and Coroutines, sidestepping new fads it's not that simple for a hobbyist.

Read up on GAP (For connecting), GATT(For communicating), and Services(Things that receive/send data i.e. battery service, heartbeat service, etc.) for Ble and understand what they are. Every Service has a UUID, find out what that is and that will be what you write to. Then use a library to write to that Service. We use Nordic's Android library at my company because we use a Nordic board but you can use any one that you like. It is significantly easier with a library than using a stock android solution.

I'm trying to develop an Android app to get the BP, HRV, HR, SpO2, ECG, PPG, BPM, steps, activity, temperature, sleep quality from Spovan H02 fitness tracker (www.spovan-en.com/.../2669112013571072.html)) which uses NORDIC 52832 CPU and SI1182 sensor. The use of H-Band app (https://play.google.com/store/apps/details?id=com.veepoo.hband&hl=en) is made in the instructions manual, but it doesn't provide the option to save details and that's why I'm building the app. I've discovered the Android BLE Scanner Compat library (https://github.com/NordicSemiconductor/Android-Scanner-Compat-Library)) to scan for the BLE devices and the Android BLE Library (https://github.com/NordicSemiconductor/Android-BLE-Library)) to connect to and communicate with BLE peripherals. I'm not able to proceed further, any help will be appreciated. Thanks in advance.