Feature Request: Implement AAPS-style receiver.

[Grntrenchman]

As more people are pushed off G6 to G7 by EOL, those of us using BYODA will no longer be able to use 640G/EverSense source, as the BYODA developer isn't implementing it for the G7 app.

Both apps have the option of AAPS-style broadcast, which requires an extra permission to receive the data, I would like to see this implemented in xDrip as a new source option.

I have found the AAPS implementation here: https://github.com/nightscout/AndroidAPS/blob/master/plugins/source/src/main/kotlin/app/aaps/plugins/source/DexcomPlugin.kt

The BYODA developer claims that other apps use the same system for receiving data from the BYODA app, I will edit/follow up when I can find more of these implementations, but if it is true, this means that something like a standard is being developed, making this a good option for xDrip to implement too.

EDIT: Here is another implementation, in a watch app: https://github.com/trupici/G-Watch-Wear/blob/1c6d2cb6fdf4b1c85a30f456213c2e78ebc5a6af/mobile/src/main/java/sk/trupici/gwatch/wear/receivers/DexComReceiver.java

[ahaarrestad]

xDrip has nothing for this today — there is no receiver for com.dexcom.cgm.EXTERNAL_BROADCAST or com.dexcom.g7.EXTERNAL_BROADCAST anywhere in the repo. The only com.dexcom.* references are the package list UiBasedCollector uses to scrape notifications, i.e. Companion App.

But before anyone writes a receiver, the sending side needs checking. The G7 patch I can read (DiaKEM/dexcom-g7-apk-patcher, patches/broadcast.patch) does this right before sending:

const-string v2, "info.nightscout.androidaps"
invoke-virtual {v1, v2}, Landroid/content/Intent;->setPackage(...)

That is an explicit broadcast. It is delivered to that package only, so a receiver in xDrip would never fire. G-Watch-Wear does the same on its side — its manifest receiver is literally named ExplicitBgBroadcastReceiver and it drops anything where intent.getPackage() is null.

So the question for the BYODA developer is whether he can address com.eveningoutpost.dexdrip too. If he keeps a list of target packages, that is one entry. Sending without setPackage also works, but is worse for xDrip: we target SDK 26, and Android O does not deliver implicit broadcasts to manifest-registered receivers, so we would have to register at runtime and would not wake up when the process is dead.

The payload itself is small if this gets sorted out: one glucoseValues extra, a Bundle of Bundles keyed "0","1",..., each with glucoseValue (int, mg/dL), timestamp (seconds) and trendArrow. The full reading list is sent every time, so backfill comes for free.

Separately: you do not need BYODA for G7 at all. xDrip talks to the G7 sensor directly over BLE — pick "Dex" as the collector and enter the short transmitter ID, and the OB1 collector handles G7 including backfill. That replaces the Dexcom app as the collecting app rather than sitting behind it, so it also drops the Companion App drawbacks you ran into.

[Grntrenchman]

The BYODA dev states

"The way the broadcast works does not keep a list of target packages in the code. It uses getPackagesHoldingPermissions to query all packages that hold the permission called "com.dexcom.cgm.EXTERNAL_PERMISSION". Then it iterates over those and uses setPackage and sendBroadcast to send over the readings. I think that means there shouldn't be a need to change code on the broadcast side and there shouldn't be issues with SDK 26 and Android O."

[ahaarrestad]

@Grntrenchman thanks for getting that answer — enumerating by permission is a better design than a
package list, and it changes part of what I said. I went and read the platform code to be sure.

getPackagesHoldingPermissions returns packages that have been granted the permission, not
packages that declare it: in AOSP the call ends in ComputerEngine.addPackageHoldingPermissions,
which keeps a package only if mPermissionManager.checkPermission(...) == PERMISSION_GRANTED. And
this one is a dangerous permission — AAPS declares it in its manifest and still has to ask for it
at runtime (DexcomPlugin.kt, checkSelfPermission → RequestDexcomPermissionActivity). If it were
a normal permission that code would be dead.

So this is doable, but <uses-permission> alone would not put us in his list; we'd need the same
runtime prompt AAPS has. That is our side of the fence, not his, and it's a known quantity rather
than a blocker.

One question worth putting back to the dev, because it decides whether we'd show up at all: that
call is subject to package visibility. It goes through generatePackageInfo, which returns null
when shouldFilterApplication matches, and the permission-based visibility rule only runs one way —
AppsFilterImpl records requester → definer, so an app that declares a permission can see the app
that defines it, not the reverse. His app is on the defining side. If it targets SDK 30+ with
neither QUERY_ALL_PACKAGES nor a <queries> entry, the enumeration comes back filtered. It clearly
works for AAPS today, so one of those is already in place — knowing which one tells us whether we'd
be picked up automatically.

I should also correct myself: I said he has to change his patch either way. For the G7 patch I can
read that still holds — it hardcodes setPackage("info.nightscout.androidaps") and contains no
permission enumeration. If what he's describing is the G6 app or a newer build, then for that path he
is right and I was wrong.

@Navid200 on your three points, and keeping them apart as you asked:

You're right that this should not be mixed with the manifest/wake work, and I think the measurements
back that up rather than blur it. On the emulator at targetSdk 26 (API 34), a plain implicit
NS_EMULATOR broadcast to a dead process delivers nothing, with or without the manifest entry —
Android O does not deliver implicit broadcasts to manifest receivers at all. Only setPackage or an
explicit component starts the process. So the manifest fix and this request cover different ground
and neither makes the other redundant.

On your condition — if backfill doesn't work today and still won't after the wake fix, then we
should add this mechanism — I think all three parts are already answered, and by measurement rather
than argument. NSEmulatorReceiver (:96-118) takes element 0 of collection=entries only when the
array has length 1; anything longer is routed to LibreOOPAlgorithm and is not treated as readings.
So that channel carries one reading per broadcast and structurally cannot fill a gap. The manifest
work fixes waking, not that. By your own condition, the gap survives the wake fix.

The alternative is still to widen the entries path on our side to accept several sgv objects, which
would fix backfill for every sender on that channel rather than just this one. It collides with the
OOP use of the same array today, so it isn't free — but it's the version that doesn't depend on
anyone else's build.

[Grntrenchman]

@ahaarrestad Thank you for the detailed info! I will pass this back BYODA way and see if they have a reply. To be clear, they are not using the DiaKEM patch, but have written something similar on their own AFAIK.

[Navid200]

I know we have code in xDrip that handles backfill. Several conditions have to pass for backfill to happen. So, we don't want to backfill over an existing reading possibly from a previous data source.
I simply think if we can get backfill from BYODA, it will be a good thing. But, that "if" possibly means spending time and working on existing code in xDrip. I am not sure how complicated that can be.

[Grntrenchman]

BYODA dev:

It has QUERY_ALL_PACKAGES permission. This is the way both the G6 AAPS broadcast works and the G7 broadcast. And you are correct, this is completely unrelated to DiaKEM.