Closed Bug 1154237 Opened 9 years ago Closed 9 years ago

Make sure NFC can still work after OTA

Categories

(Firefox OS Graveyard :: NFC, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: allstars.chh, Unassigned)

References

Details

NFC will communicate with nfcd, however if user updates Gecko through OTA (not FOTA), it will be possible that we break the communication protocol between Gecko/Daemon, and in turn NFC cannot work at all.

I think BT might have similar problem since it also uses bluetoothd.
For Bluetooth, we use the protocol defined at [1]. We intend to not do any incompatible changes, so we shouldn't run into compatibility problems. The actual protocol revision differs among Android versions, but that's probably not a problem for OTA updates.

[1]https://git.kernel.org/cgit/bluetooth/bluez.git/tree/android/hal-ipc-api.txt
Thanks Thomas.

Change Component to NFC.
Blocks: b2g-nfc
Component: General → NFC
Summary: Make sure NFC/BT can still work after OTA → Make sure NFC can still work after OTA
Hi Thomas
What about for the new feature? Suppose you land a new feature with Gecko + Bluetoothd changes, but now user does OTA and only Gecko is updated, his bluetoothd is still in older version.
So I'll imagine that some BT API could work but the newer API cannot work, and that will confuse user and perhaps confuse we developers, too. As it could just because of an older bluetoothd or actually a new bug.

Back to NFC,
In order to make NFC fully work in OTA, I think we still need to update nfcd as well.
Otherwise I'll afraid that after OTA, the partially working API shouldn't be acceptable (at least to me), specially when it comes to NFC payment.
Hi Yoshi,

The IPC protocol for bluetoothd is only a wrapper around Android HAL API. All the high-level logic of a feature is implemented in Gecko. This makes it easy to add, change and fix features in OTA updates. The daemon itself is so simple that it can hardly contain any bugs.

New profiles are usually dependent on the capabilities of the Bluetooth driver and hardware. To use any of it's capabilities, we have to register and initialize it when we start Bluetooth. If the driver doesn't support a profile, the registering fails and we can switch off the feature in Gecko.

For example, Gecko implements a number of Bluetooth profiles. Each of the profiles has to be registered with the Bluetooth daemon. Drivers that don't support certain profiles will return an error, and bluetoothd forwards the error to Gecko, which disables the profiles.

Each Android version comes with a specific set of available features and a slightly different API. For each version, we have a variant of the IPC protocol that fits the version's requirements. And detecting the Android API version is trivial at build time.

Bluetooth's IPC protocol is defined by BlueZ, but for Geolocation, we have the opportunity of inventing our protocol. I thought about returning a feature bitmask during the initialization of each of the components of Geolocation. That should make it easy to adapt Gecko to the available features.
Hi Thomas
Thanks for the detail answer.
But our problem for NFC will be more like Bug 1129257 from BT (that bug will change the communication protocol).

(Perhaps before that bug, some BT API was already not working)
After OTA with fixes from Bug 1129257, I assume user still has problem from Bug 1129257 even their Gecko has already come with the patch, because their bluetoothd cannot be updated to the commit in Bug 1129257.

Is my understanding correct?

Thanks
You're right. We could still fix bug 1129257, because bluetoothd had not been deployed yet.

If the daemon had already reached end users, we would have had a problem with compatibility. In this case, I guess we would have fixed the issue when porting to the next new Android release; and kept the old releases as they are.
Hi Naoki
We've discussed with BT/device team, and we cannot put nfcd in the OTA package, since nfcd is built with other native headers/libraries from gonk layer, so if nfcd is running on the device with older binaries, it could be possible that nfcd is still failing to execute, and the binary compatible problem will make us more harder to debug.

FOTA should fix this problem, and device team has some plans to do FOTA on Flame, but now they are waiting approvals, and this maybe take some time.

To fix your problem immediately, can you tell us which mailing-list should we send to inform you about the gonk layer change? 

Thanks
Flags: needinfo?(nhirata.bugzilla)
Thanks for the update!  I think dev-b2g and dev-gaia are the appropriate channels to send public announcements of gonk changes.

I think T2M has to do FOTA as well as update their drivers.  Esp if we go to lollipop.
Flags: needinfo?(nhirata.bugzilla)
Thanks Naoki.

Mark this as WONTFIX as this needs FOTA, and the solution now is to send notifications to dev-b2g/dev-gaia.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.