An Android app/GUI using Dear ImGui and Librador

[brentfpage]

Check out this Android app that I made for the Labrador board using Dear ImGui and Librador! There's more that I plan to add, but I think it's a solid foundation. Please let me know what you think!

[EspoTek]

No way, that's sick! Can't wait to try it! API level 36 too!

Should we consider deprecating the Qt version for Android and merging this one into the main Labrador repo? That way we can all work on it together more easily.

[brentfpage]

That would be more than good with me!

…

On Mar 14, 2026, at 12:55 AM, Chris Esposito ***@***.***> wrote: No way, that's sick! Can't wait to try it! API level 36 too! Should we consider deprecating the Qt version for Android and merging this one into the main Labrador repo? That way we can all work on it together more easily. — Reply to this email directly, view it on GitHub <#432 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQKPNTCR4NIOWHNGGHEYOD34QUF5PAVCNFSM6AAAAACWRYJD7SVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMJSHAZTMMY>. You are receiving this because you authored the thread.

[EspoTek]

Yep, it just works on my Pixel 5. UI seems like a work in progress but backend-wise everything seems to be smooth as butter! "Solid Foundation" is a bit of an understatement, haha.

Do you have thoughts about how the UI can look? I was thinking tabs would be a way to keep things feature-rich without being overwhelming. Also, we'll need to disable Power Supply controls since USB-OTG doesn't supply enough current to handle it.

[mi-hol]

how the UI can look? I was thinking tabs would be a way to keep things feature-rich without being overwhelming.

a Tabbed UI sounds like the best approach (for later other OS versions too).
Important is dynamic adaption to available display size of device and rotation (i.e. on tablet)

Would perhaps other maintainers & users have comments?

[brentfpage]

I agree that making parts of the settings panel collapsible will become necessary as more features are added. Hopefully the number of sub-panel openings/closings required in typical usage can be kept fairly small, as I think this ensures a smooth user experience.

[brentfpage]

Google Pixels and Samsung Galaxies dating back to ~2021 (and maybe earlier) have used USB Type-C 3. The OTG spec for USB 3, Ch. 3 says that, in their electrical characteristics, all SuperSpeed-capable (i.e.? USB 3) OTG products comply with both the OTG spec for USB 2 (included in this zip) and the USB 3 spec.

The OTG spec for USB 2 says (Table 4.1) that a host device's maximum current supply for peripherals is allowed to be as small as 8 mA and as large as 5 A. It also says (section 4.3.1) that an unconfigured peripheral is allowed to draw 2.5 mA at most, but once it's configured, it follows the same rules as laid out in the core USB 2 spec. This means it can draw between 100 mA and 500 mA. This seems a bit odd because it means there can be OTG hosts that do not support a single configured peripheral, (8 mA < 100 mA), but the spec itself admits that 8 mA is impractically low.

I see that the USB settings for the Labrador board specify that it will draw 500 mA at maximum. I would think that hosts would read this mA value at configuration time, decide whether they can provide it, and if not then disconnect from the board. Probably, exceeding this 500 mA max also would cause the host to disconnect.

Given all that, why would it be an issue to enable user-control of the power supply voltage in the android app? Can't it just be the responsibility of the user to keep the current draw under 500 mA? I'm assuming here that the board itself draws less than 500 mA when the power supply is maxed out.

[mi-hol]

Given all that, why would it be an issue to enable user-control of the power supply voltage in the android app?

@EspoTek in #279 (comment) you wrote:
"The host PC should never get damaged as the USB spec required OCP" and the USB specs are the same for PC and SmartPhones.
Finding a reference for above statement in the latest USB specs would mean we are on the "safe side", right?

[EspoTek]

We can't damage the host PC/phone, but it is possible for the device to shut itself down if it draws too much power.

[mi-hol]

Check out this Android app that I made for the Labrador board using Dear ImGui and Librador!

@brentfpage are you aware of LabraScope and the discussion #285 ?

[brentfpage]

Yes!

[brentfpage]

I uploaded a new apk that features scalings of the layout that should improve cross-device compatibility. Of three emulated devices, one showed some small amount of overlap in the UI widgets towards the bottom. So, the scalings work decently well, but I may tweak them a bit more for this version 0 of the app. A future version 1 should have a more robust solution to cross-device compatibility.

[mi-hol]

UI looks better on my Motorola G84 now. I miss a simple Multimeter view though

[brentfpage]

Imo this app is ready to be added to the genuine Labrador repo. Because it features Android-specific edits to librador, I was thinking that it would be best to put the app in a new branch for now. One sticking point will be the submodules (SDL, imgui, implot), which presently are my forks (created for the sole purpose of the app). I could transfer those to the Espotek organization or just individually grant write access to anyone who wants to work on the app.

About the things discussed above – I ended up implementing a tiling system to allow the user to de-clutter the settings panel. The Readme describes how to use the tiling system, although it should be fairly intuitive. Also, I got around to doing more cross-device and cross-API compatibility debugging and think that the app will look good on all phone-like form factors. Lastly, what's the final word on PSU?

The apk in the current app repo is up-to-date. Most important on the to-do list is autogain. Right now, the gain is just set once to 4.

[mi-hol]

One sticking point will be the submodules (SDL, imgui, implot), which presently are my forks (created for the sole purpose of the app).

I'd prefer to check first, if these changes would be accepted by the original projects.

[brentfpage]

I tried for SDL (libsdl-org/SDL#15092), but the PR hasn't been accepted. I don't think any more changes to SDL will be needed. For imgui, it may be possible to ditch the fork and just add to the main app repo a few files that contain custom widgets. I'll look into doing that, but I already know of one small change that I made to imgui that will need a different workaround. For implot, I think it's best just to keep using the fork.

[EspoTek]

I agree, currently away on holiday but feel free to merge it all across!

For librador, I think we put the current version in a "legacy" directory and make the current version a WIP.
There are a few other changes I want to make too, like swapping it from using raw pointers to const ref, and making use of STL where appropriate.

[brentfpage]

That's great news! I'll get started on merging the app.

[mi-hol]

what's the final word on PSU?

My opinion: For Android that doesn't seem to have a high priority

[mi-hol]

I miss a simple Multimeter view though

Are you maybe considering to add that?

[brentfpage]

Already did! In the "inputs" tile,

the multimeter is activated by the lower-right checkbox, which only becomes checkable when the top 5 checkboxes are de-selected. Right now, the multimeter is just a 12 bit voltage difference CH1_scope - CH2_scope (or possibly the negation of that). Planned for the future is a UI tile that will enable R and C measurements like in the desktop app.

[mi-hol]

@brentfpage I tried to measure voltage of a 3.7V battery using the setup below, but was unsuccessful.
Should this work using v0.3 or am I doing something wrong?
Edit: removing the "Charger Doctor" did not change anything.

[brentfpage]

If the blue and yellow leads are connected to the CH1 DC and CH2 DC scope inputs on the board, then that setup should work if multimeter mode is selected in the app. I just tried the same thing and got a correct voltage reading.

I'm confused as to why no lines appear to be plotted on the phone screen in the photo you sent. When the app starts up and the board is connected, you do see a blue plotted line like in the photo below, right?

[mi-hol]

you do see a blue plotted line like in the photo below, right?

no, I guess a previous test with new firmware on Windows screwed up the board.
Does v03 reflash firmware at connect time?
Is perhaps a log file available so I can share details?

[brentfpage]

Just tested firmware flashing using this Android app again and confirmed that it works, but I would suggest using the desktop interface for firmware recovery. It doesn't matter if variant 1 or 2 gets uploaded – the important thing is to just establish board health. If it's variant 1, then the Android app will be able to replace it with variant 2.

In case you're still interested in logs, Logcat Reader https://play.google.com/store/apps/details?id=com.dp.logcatapp&hl=en-US has worked well for me – searching for "librador" within Logcat Reader should turn up entries related to the Labrador app. If you have android command-line tools, you can alternatively use adb, even over wifi in case the Labrador board is plugged in to the USB port.