I'd suggest you try using the 'Android' app instead of Gadgetbridge. I'm pretty sure calls do work ok on that one

@gfwilliams I've actually been meaning to bring that up... I use Android integration and the Messages app on my Bangle 2 and do not get any call notifications on the watch.

Ok, and they are both up to date? Android 0.04, Messages 0.07

Because the code is definitely in there: https://github.com/espruino/BangleApps/blob/master/apps/android/boot.js#L38

Yes. Android integration 0.04 and Messages 0.07. Gadgetbridge app 0.62.0.

I concur. Same versions of Messages and Android installed and no notification of an incoming call. You do get a notification of a missed call but the buzz didn't work.
I then removed Android and installed Gadgetbridge (0.24) and that also does not give a notification of an incoming call but it does buzz for the missed call notification.

I've just added a Gadgetbridge debug app to the development app loader: https://espruino.github.io/BangleApps/#gbdebug

Please can you run that, receive a call and tell me what it says? I have a feeling that there could be an issue with the 0.62.0 Gadgetbridge app where it doesn't display the type of call properly (incoming/etc). It's an odd one as it works from me with the version I built from source, but somehow the fixes may not have made it into that version

Gadgetbridge Debug displays the following when a call is received:
{ "t": "call", "cmd": "", "name": "Me" }

Great - thanks for checking on that! So yes, that's the problem. Seems to be some issue with 0.62.0 :(

Can confirm this issue for Gadgetbridge 0.63.0 and Android Integration 0.04.

Any news about the incoming call notification problem?
I'm having the same issue using a phone with android 12 and a Bangle.js2 Version 2v11, Android Integration (v0.05), Gadgetbridge (v0.63.1).

Would also like this reopened. Running the latest android (.05), messages (.14) and official firmware (2v11). Do not get any call notifications.

The issue is already open? It's an odd one as the builds I did of Gadgetbridge here seem ok so I'm not quite sure what's different in the releases

So it is. Misread the closed tag on #1082 and assumed it was for this ticket. My mistake.

gadgetbridge 0.65.0, the problem persists.
it seems that it's gadgetbridge that doesn't send the "cmd" parameter and therefore the "Android" app not finding the "incoming" field does not set the "add" / "remove" field correctly.

t:event.cmd=="incoming"?"add":"remove", ( https://github.com/espruino/BangleApps/blob/master/apps/android/boot.js row: 41 )

could it be that an exception is thrown in that try-catch? (and therefore cmdName remains empty)

String cmdName = "";
try {
Field fields[] = callSpec.getClass().getDeclaredFields();
for (Field field : fields)
if (field.getName().startsWith("CALL_") && field.getInt(callSpec) == callSpec.command)
cmdName = field.getName().substring(5).toLowerCase();
} catch (IllegalAccessException e) {}
o.put("cmd", cmdName);
(https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/service/devices/banglejs/BangleJSDeviceSupport.java row: 385)

I tried the incoming calls feature with two different phones, it worked with one (Motorola Play X, Android 7.1.1), but it didn't work with the other (Fairphone 2, Lineage 18.1/Android 11). I am not sure why they behave differently, but I was able to get it working with both phones with a minimal change in the Gadgetbridge app.

I have created a pull request in the Gadgedbridge repo: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2576

@Low012 excellent - thanks! I'm surprised that fixed it, but maybe the exception ended up breaking out of some other code further up.

Also if it works on some phones and not others it explains why I was having so much trouble reproducing it :)

That makes sense. I also use lineage and wasn't getting the notifications.

The pull request has been merged.

In having this same issue with a Moto g stylus. Latest gagetbridge and Android apps installed and when I run gb debug I get the same as everyone above.

Yes, I don't think this'll work until gadgetbridge 0.66

I received version 0.66.0 of Gadgetbridge via F-Droid today. Unfortunately notifications for incoming calls did not work for me with this version while it works fine with my self compiled version. I am at my wits end, at least for today.

Can confirm that 0.66 does not fix call notifications.

A few months ago I theorised (read: made a wild guess) that this issue only affected release builds of Gadgetbridge:
http://forum.espruino.com/conversations/371846/#16351448

Maybe the UART RX fix didn't actually have anything to do with this and you're just seeing a fixed call notification since you're self-compiling...

Guessing wildly again.

Thanks for the wild guess. I just compared the F-Droid build and my own build which works for me. My working build is a debug build while the F-Droid build is a release build. I created a release build signed with my own key and it behaved just like the F-Droid build (no notification on incoming call).

I checked the debug and the release build and they have different structures:

Unfortunately I have no idea if this has anything to do with the different behaviour.

Main difference between debug and release is logging, right? So maybe there's something erroring out, but on debug it can continue since it's allowed to log while on release it just stalls (or something). I have very little knowledge of Android apps, so I've no idea if this makes any kind of sense (guessing wildly again).

It's possible that one difference is that the release build doesn't have symbols in it?

I always thought that the Java reflection API (which I think we use in the code?) was a core part of Java/Android and never got removed, but if the values for enums aren't available (maybe they get optimised out?) so that getDeclaredFields doesn't return anything then the code wouldn't work.

It might be easier just to hard-code the enum values - there are only 3 I think

@gfwilliams: I only do Android development as a hobby nowadays and I shy away from reflection in combination with build time optimizations. But I will take a look at the code, try to replace the values in question and report back once I am done.

Thanks - that would be awesome! If you don't think you'll get time soon let me know and I'll have a stab next week

I tried this:

            String cmdName = "unknown";
            try {
                Field fields[] = callSpec.getClass().getDeclaredFields();
                for (Field field : fields)
                    if (field.getName().startsWith("CALL_") && field.getInt(callSpec) == callSpec.command)
                        cmdName = field.getName().substring(5).toLowerCase();
            } catch (IllegalAccessException e) {
                cmdName = "error";
                o.put("message", e.getMessage());
            }

and it came out with "cmd":"unknown" and no error, so it does look like somehow reflection is broken.

Replacing it with a switch works, but it would be nicer if we could get the reflection to work.

Edit: I figured reflection is Scary, so just created a PR replacing it with a lookup table.

I added some logging and found out that in the release build all the public static int fields from the CallSpecclass were missing. After some googling research I found out that ProGuard was responsible for this behaviour. Adding a few lines in the proguard-rules.pro fixes the problem. I will create a pull request later tonight.

Here it is: https://codeberg.org/Freeyourgadget/Gadgetbridge/pulls/2619

edit: Ooops! I didn't notice the other pull request by @rigrig. Shall I retract my PR?

Excellent, thanks for sorting this! Looks like it's all merged now.

I think fixing the reflection is a good thing in its own right - Gadgetbridge doesn't need to obfuscate anything and it's worrying having Debug/Release builds behaving differently.

But maybe a switch statement is the best bet long term. I seem to recall I'd originally used the integer ID to look up in an array of strings, but at some point someone changed the integer IDs and it broke (maybe not calls, but something else like messages/media) - so I moved to reflection.

However actually having the enums mentioned explicitly, while more verbose, would at least cause a compile error if someone renamed something.

Gadgetbridge doesn't need to obfuscate anything

It seems it's not aimed at "hiding" things, but about reducing app size.

maybe a switch statement is the best bet long term

I added a Map of CALL_* to CMD_* constants in my (retracted) PR, but I figure the advantage of reflection is that it still works if another CALL_* constant is added. (At least on the GB side)

I think the best solution might actually be to change those constants to an enum. It seems like a better match for the data anyway, and the BangleJS code could just use .toString(). But that will involve quite a bit of changes all across GadgetBridge. (On the plus side: it would probably mean we can get a warning if some code misses a case.)