|
Changes to switch the Qt-based agl-demo-platform demo from using
the older KUKSA.val server to the new gRPC based databroker. The
Flutter demo's vehicle signalling behavior ends up a bit broken
by these, but the image still boots and basic things still work.
A follow on set of changes will convert the Flutter apps to the
new gRPC API and remove the KUKSA.val server completely.
Notable changes:
- Updated libqtappfw, homescreen, ondemandnavi, and tbtnavi recipes
to pick up changes to switch to using the databroker.
- Updated agl-service-audiomixer and agl-service-hvac recipes to
pick up their rework for using the databroker.
- All the Qt demo applications that use the VehicleSignals class
from libqtappfw have had their .conf and .token files updated to
work with the databroker. As well, the JSON files used to create
the new app-specific authorization tokens have been checked in to
provide a reference of how things are configured.
- The DBC feeder configuration has been changed to push into the
databroker. Having a duplicate instance to also push into the
older server has not been set up, as hopefully the Flutter demo
conversion will follow on quickly enough to not require it.
- Packagegroups for the KUKSA.val server and databroker have been
factored out and are used instead of using the agl-ivi-services
packagegroup.
- kuksa-databroker-cli and the simple CAN simulator script are now
included into the demo images when building with agl-devel.
Bug-AGL: SPEC-4762
Change-Id: I416bcfbf961535062043ef54acdea6c353f84af1
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Reviewed-on: https://gerrit.automotivelinux.org/gerrit/c/AGL/meta-agl-demo/+/29171
Tested-by: Jenkins Job builder account
ci-image-build: Jenkins Job builder account
ci-image-boot-test: Jenkins Job builder account
Reviewed-by: Jan-Simon Moeller <jsmoeller@linuxfoundation.org>
|
|
Update the recipes for the Qt demo applications that were previously
using signal-composer either directly or indirectly to work with the
new VehicleSignals API in libqtappfw. For most of them this means
updating their SRCREV to pick up the application changes, and
installing the new configuration file and associated JSON web token
file for KUKSA.val authorization. At present all the apps are using
one of the default read-write tokens from the KUKSA.val install, but
ideally this will end up migrated to app specific tokens with
appropriate permissions JSON down the road, potentially obtained
via OAuth or similar mechanism.
Additionally, the tbtnavi recipe has been updated to install a
systemd unit to start it at boot.
Bug-AGL: SPEC-4409, SPEC-4426
Signed-off-by: Scott Murray <scott.murray@konsulko.com>
Change-Id: I46be098fc31be02852e7888ba0ffd14674efa12b
|