CI/CD: Promote lib files to ncs-door-lock-app @1629bf99e2b4

Source commit ID: @1629bf99e2b4

Signed-off-by: Miecznik, Rafał <rafal.miecznik@nordicsemi.com>

Author: Miecznik, Rafał

app/src/platform/uwb_impl/uwb_dummy_impl/CMakeLists.txt

@@ -5,3 +5,7 @@
 #
 
 zephyr_include_directories(.)
+
+file(GLOB uwb_src CONFIGURE_DEPENDS *.cpp)
+
+zephyr_library_sources(${uwb_src})

app/src/platform/uwb_impl/uwb_dummy_impl/uwb_impl.cpp

@@ -0,0 +1,56 @@
+/*
+ * Copyright (c) 2025 Nordic Semiconductor ASA
+ *
+ * SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
+ */
+
+#include "uwb_impl.h"
+
+namespace Aliro::Uwb {
+
+AliroError UltraWideBandImpl::_Init([[maybe_unused]] const Callbacks &)
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+AliroError UltraWideBandImpl::_Deinit()
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+void UltraWideBandImpl::_BleTimeSync()
+	const { /* No operation for dummy implementation; override in derived classes if needed. */ };
+
+AliroError UltraWideBandImpl::_HandleBleMessage([[maybe_unused]] const uint8_t *, [[maybe_unused]] size_t)
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+AliroError UltraWideBandImpl::_ConfigureRangingSession([[maybe_unused]] SessionIdentifier,
+						       [[maybe_unused]] const CryptoTypes::Ursk &,
+						       [[maybe_unused]] void *)
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+AliroError UltraWideBandImpl::_InitiateRangingSession()
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+AliroError UltraWideBandImpl::_TerminateRangingSession()
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+AliroError UltraWideBandImpl::_SuspendRangingSession()
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+AliroError UltraWideBandImpl::_ResumeRangingSession()
+{
+	return ALIRO_ERROR_NOT_IMPLEMENTED;
+}
+
+} // namespace Aliro::Uwb

app/src/platform/uwb_impl/uwb_dummy_impl/uwb_impl.h

@@ -33,28 +33,16 @@ class UltraWideBandImpl : public UltraWideBand<UltraWideBandImpl> {
 		return sInstance;
 	}
 
-	AliroError _Init([[maybe_unused]] const Callbacks &) const { return ALIRO_ERROR_NOT_IMPLEMENTED; }
-	AliroError _Deinit() const { return ALIRO_ERROR_NOT_IMPLEMENTED; }
-	void
-	_BleTimeSync() const { /* No operation for dummy implementation; override in derived classes if needed. */ };
-
-	AliroError _HandleBleMessage([[maybe_unused]] const uint8_t *, [[maybe_unused]] size_t) const
-	{
-		return ALIRO_ERROR_NOT_IMPLEMENTED;
-	}
-
+	AliroError _Init([[maybe_unused]] const Callbacks &);
+	AliroError _Deinit();
+	void _BleTimeSync() const;
+	AliroError _HandleBleMessage([[maybe_unused]] const uint8_t *, [[maybe_unused]] size_t);
 	AliroError _ConfigureRangingSession([[maybe_unused]] SessionIdentifier,
-					    [[maybe_unused]] const CryptoTypes::Ursk &,
-					    [[maybe_unused]] const void *) const
-	{
-		return ALIRO_ERROR_NOT_IMPLEMENTED;
-	}
-
-	AliroError _InitiateRangingSession() const { return ALIRO_ERROR_NOT_IMPLEMENTED; }
-
-	AliroError _TerminateRangingSession() const { return ALIRO_ERROR_NOT_IMPLEMENTED; }
-	AliroError _SuspendRangingSession() const { return ALIRO_ERROR_NOT_IMPLEMENTED; }
-	AliroError _ResumeRangingSession() const { return ALIRO_ERROR_NOT_IMPLEMENTED; }
+					    [[maybe_unused]] const CryptoTypes::Ursk &, [[maybe_unused]] void *);
+	AliroError _InitiateRangingSession();
+	AliroError _TerminateRangingSession();
+	AliroError _SuspendRangingSession();
+	AliroError _ResumeRangingSession();
 
 	// Delete copy and move constructors and assignment operators.
 	UltraWideBandImpl(const UltraWideBandImpl &) = delete;

docs/door_lock_app_arch.rst

@@ -7,7 +7,7 @@
    :local:
    :depth: 2
 
-The |APP_NAME| runs on the Nordic Semiconductor's :ref:`supported SoCs <hw_requirements>` and utilizes the Aliro stack for access protocol and communication with user device over Near Field Communication (NFC) or Bluetooth® LE.
+The |APP_NAME| runs on the Nordic Semiconductor's :ref:`supported SoCs <hw_requirements>` and utilizes the Aliro stack for access protocol and communication with a User Device over Near Field Communication (NFC) or Bluetooth® LE.
 See the following diagram for an architecture overview:
 
 .. _arch_overview:
@@ -20,7 +20,7 @@ See the following diagram for an architecture overview:
 
 The |APP_NAME| is build using the :ref:`nRF Connect SDK <sdk_set_up>`, which includes the Zephyr RTOS with all necessary modules.
 
-The Aliro stack implements the Access Protocol logic, Aliro-specific cryptographic primitives, and communication with the user device.
+The Aliro stack implements the Access Protocol logic, Aliro-specific cryptographic primitives, and communication with the User Device.
 The interfaces layer is a bridge connecting the Aliro stack to the Zephyr OS modules through specific backends that implement the following components required by the Aliro: crypto, NFC and, ultra wideband (UWB).
 This layer additionally allows to utilize other, custom backends for the crypto, NFC and UWB components by implementing the provided API.
 By default, the |APP_NAME| uses backends shown in the :ref:`architecture overview <arch_overview>`.

docs/index.rst

@@ -10,7 +10,7 @@ Aliro is the new industry-standard access control and communication protocol, of
 
 Aliro features several key features that distinguish it from existing access protocols:
 
-* Interoperability and compatibility - Ensures seamless interaction between access readers, such as electronic locks and access control readers, and user devices like smartphone and wearables.
+* Interoperability and compatibility - Ensures seamless interaction between access readers, such as electronic locks and access control readers, and User Devices like a smartphone and wearables.
   The standardized solution allows manufacturer-independent devices and readers to work together without compromising security.
 * Flexibility - Does not dictate how your digital door lock or access control reader connects to the rest of your ecosystem.
 * Protocol support - Supports various transport protocols, including mandatory Near Field Communication (NFC), Bluetooth® LE or Bluetooth LE with Ultra-Wideband (UWB).

docs/known_issues.rst

@@ -46,13 +46,13 @@ AL-335: Watchdog expires for an NFC session upon test execution
   When executing the RD-NFC-STDTXN-2.0 test, the ``Watchdog expired for NFC session`` event occasionally occurs.
   This issue is caused by missing AUTH1 response from the test harness, despite logs indicating that the AUTH1 response was sent.
 
-AL-239: Occasional timeout occurs in the reader when executing the RD-NFC-STDTXN-2.0 test from the test harness
-  When executing the RD-NFC-STDTXN-2.0 test case, the reader might report an RX timeout error code in the serial console.
+AL-239: Occasional timeout occurs in the Reader when executing the RD-NFC-STDTXN-2.0 test from the test harness
+  When executing the RD-NFC-STDTXN-2.0 test case, the Reader might report an RX timeout error code in the serial console.
   For more details, see `Test Harness issue #191`_.
 
 AL-282: An undefined access decision occurs when executing the RD-NFC-STDTXN-2.0 test harness case in a loop
-  When executing the RD-NFC-STDTXN-2.0 test case multiple times in a row (with valid credentials provisioned), the reader might not report the access decision.
-  As a result, the ``ACCESS GRANTED`` or ``ACCESS DENIED`` logs are not displayed in the serial output of the reader under test.
+  When executing the RD-NFC-STDTXN-2.0 test case multiple times in a row (with valid credentials provisioned), the Reader might not report the access decision.
+  As a result, the ``ACCESS GRANTED`` or ``ACCESS DENIED`` logs are not displayed in the serial output of the Reader under test.
 
 AL-148: The RD-NFC-STDTXN-1.0 test case fails when the NFC module ST X-NUCLEO-NFC05A1 is in use
   Testing RD-NFC-STDTXN-1.0 with the NFC module NFC05A1 results in failure.
@@ -61,22 +61,22 @@ AL-148: The RD-NFC-STDTXN-1.0 test case fails when the NFC module ST X-NUCLEO-NF
   **Workaround:** Switch to X-NUCLEO-NFC09A1, a newer, recommended revision of the NFC ST module.
   Attach X-NUCLEO-NFC09A1 shield to the nRF54L15 DK, rebuild the firmware with the ``CONFIG_ST25R200_DRV`` Kconfig option enabled, and re-flash the nRF54L15 DK.
 
-AL-159: Cannot provision multiple user devices
-  The system allows provisioning of only one user device to the reader device.
+AL-159: Cannot provision multiple User Devices
+  The system allows provisioning of only one User Device to the Reader device.
 
 AL-161: The RD-NFC-STDTXN-2.0 [X-NUCLEO-NFC08A1] test exhibits a delay in the transaction initiation step
   During the RD-NFC-STDTXN-2.0 test execution, there is a noticeable delay of a few seconds after the transaction initiation step.
 
 The |APP_NAME| v0.2.0
 *********************
 
-AL-239: Occasional timeout occurs in the reader when executing the RD-NFC-STDTXN-2.0 test from the test harness
-  When executing the RD-NFC-STDTXN-2.0 test case, the reader might report an RX timeout error code in the serial console.
+AL-239: Occasional timeout occurs in the Reader when executing the RD-NFC-STDTXN-2.0 test from the test harness
+  When executing the RD-NFC-STDTXN-2.0 test case, the Reader might report an RX timeout error code in the serial console.
   For more details, see `Test Harness issue #191`_.
 
 AL-282: An undefined access decision occurs when executing the RD-NFC-STDTXN-2.0 test harness case in a loop
-  When executing the RD-NFC-STDTXN-2.0 test case multiple times in a row (with valid credentials provisioned), the reader might not report the access decision.
-  As a result, the ``ACCESS GRANTED`` or ``ACCESS DENIED`` logs are not displayed in the serial output of the reader under test.
+  When executing the RD-NFC-STDTXN-2.0 test case multiple times in a row (with valid credentials provisioned), the Reader might not report the access decision.
+  As a result, the ``ACCESS GRANTED`` or ``ACCESS DENIED`` logs are not displayed in the serial output of the Reader under test.
 
 AL-148: The RD-NFC-STDTXN-1.0 test case fails when the NFC module ST X-NUCLEO-NFC05A1 is in use
   Testing RD-NFC-STDTXN-1.0 with the NFC module NFC05A1 results in failure.
@@ -86,11 +86,11 @@ AL-148: The RD-NFC-STDTXN-1.0 test case fails when the NFC module ST X-NUCLEO-NF
   Attach the X-NUCLEO-NFC09A1 shield to the supported Nordic development kit, rebuild the firmware with the ``CONFIG_ST25R200_DRV`` Kconfig option enabled, and reflash the DK.
 
 AL-158: Access control is insufficient due to relying only on signature verification
-  The reader device does not have the capability to configure additional access rules.
+  The Reader device does not have the capability to configure additional access rules.
   Access Manager is not implemented.
 
-AL-159: Cannot provision multiple user devices
-  The system allows provisioning of only one user device to the reader device.
+AL-159: Cannot provision multiple User Devices
+  The system allows provisioning of only one User Device to the Reader device.
 
 AL-161: The RD-NFC-STDTXN-2.0 [X-NUCLEO-NFC08A1] test exhibits a delay in the transaction initiation step
   During the RD-NFC-STDTXN-2.0 test execution, there is a noticeable delay of a few seconds after the transaction initiation step.
@@ -109,11 +109,11 @@ AL-148: The RD-NFC-STDTXN-1.0 test case fails when the NFC module ST X-NUCLEO-NF
   Attach X-NUCLEO-NFC09A1 shield to the nRF54L15 DK, rebuild the firmware with the ``CONFIG_ST25R200_DRV`` Kconfig option enabled, and re-flash the nRF54L15 DK.
 
 AL-158: Access control is insufficient due to relying only on signature verification
-  The reader device does not have the capability to configure additional access rules.
+  The Reader device does not have the capability to configure additional access rules.
   Access Manager is not implemented.
 
-AL-159: Cannot provision multiple user devices
-  The system allows provisioning of only one user device to the reader device.
+AL-159: Cannot provision multiple User Devices
+  The system allows provisioning of only one User Device to the Reader device.
 
 AL-161: The RD-NFC-STDTXN-2.0 [X-NUCLEO-NFC08A1] test exhibits a delay in the transaction initiation step
   During the RD-NFC-STDTXN-2.0 test execution, there is a noticeable delay of a few seconds after the transaction initiation step.

docs/release_notes.rst

@@ -72,7 +72,7 @@ See the following section for the list of implemented features.
   * Transport Protocol over Near Field Communication (NFC) transport.
   * Trusted Framework implementation with the |NCS| PSA API as a cryptography backend.
   * The nRF54L15 hardware platform.
-  * STM NFC Reader transceivers: ST25R200, ST25R3911, ST25R3916, ST25R3916B, ST25R200.
+  * STM NFC reader transceivers: ST25R200, ST25R3911, ST25R3916, ST25R3916B, ST25R200.
   * ST Microelectronics R/F Abstraction Layer driver with Zephyr Platform Abstraction Layer integration.
   * |APP_NAME| that leverages Aliro stack and supports CLI-based provisioning of the Access Credential public key, the reader's group identifier, and the group sub-identifier.
   * Sample applications that uses RFAL driver.

docs/testing.rst

@@ -18,7 +18,7 @@ Test environment consists of two major components:
 
 * The Nordic Semiconductor’s :ref:`development kit (DK) <hw_requirements>`, which serves as the Reader in the door lock component.
   It must be attached to an NFC card reader expansion board.
-* The Aliro Test Harness, which acts as the user device and simulates unlocking of the door lock.
+* The Aliro Test Harness, which acts as the User Device and simulates unlocking of the door lock.
 
 See the :ref:`hw_requirements` page for more details.
 
@@ -128,7 +128,7 @@ This will allow you to test the Bluetooth LE transport.
 
    Test suites list.
 
-Thanks to this, the Test Harness device will be operating as the Aliro user device and communicate with the Reader device.
+Thanks to this, the Test Harness device will be operating as the Aliro User Device and communicate with the Reader device.
 
 For verification, execute the following tests, based on the `Aliro Certification Test Tool for GTE#2`_ tag:
 
@@ -228,7 +228,7 @@ Complete the following steps for the required tests:
 
                Tests selection view.
 
-            The Reader device will select the Test Harness user device and initiate the Aliro Access Protocol commands exchange.
+            The Reader device will select the Test Harness User Device and initiate the Aliro Access Protocol commands exchange.
 
             In the DUT's serial console, you will see logs that indicate the state of the operation and the data payloads transmitted and received by the Reader.
             If the results show as ``passed``, you will see the following output in the Test Harness web interface: