Use full path for link within the documentation (#2636)

docs/android.md

@@ -34,7 +34,7 @@ We welcome contributions of all kinds! Here are some ways you can get involved:
 
 ## Ready to get started?
 
-1. **[Check out our get started guide](android/get_started)** for step-by-step instructions.
+1. **[Check out our get started guide](/docs/android/get_started)** for step-by-step instructions.
 2. **[Join our Discord community](https://discord.gg/c5DvZ4e)**, make sure you select the developer role and head to the **[Android](https://discord.com/channels/330944238910963714/1346948551892009101)** project thread to connect with other contributors.
 
 Together, we can create something extraordinary. Let's build the future of smart homes, one contribution at a time!

docs/android/architecture.md

@@ -85,4 +85,4 @@ The automotive application reuses the sources of the `:app` module, simplifying
 
 ### Wear OS
 
-The Wear OS app communicates with the mobile app to retrieve credentials for the Home Assistant server and other configurations using the [Messaging API](https://developer.android.com/training/wearables/data/messages). It only works with the `full` flavor, as it requires Google Play Services. Once the initial setup is complete, all further communication is handled directly with Home Assistant through the WebSocket and the [webhook](../api/native-app-integration/sending-data) that is created for the app.
+The Wear OS app communicates with the mobile app to retrieve credentials for the Home Assistant server and other configurations using the [Messaging API](https://developer.android.com/training/wearables/data/messages). It only works with the `full` flavor, as it requires Google Play Services. Once the initial setup is complete, all further communication is handled directly with Home Assistant through the WebSocket and the [webhook](/docs/api/native-app-integration/sending-data) that is created for the app.

docs/android/best_practices.md

@@ -111,9 +111,9 @@ Naming is hard, but smaller functions make it easier to choose meaningful names.
 - **Why?** Smaller PRs are easier to review, reduce delays, and minimize frustration.
 - **How?** Break down large changes into smaller, logical chunks.
 
-For more details, see [submit](submit).
+For more details, see [submit](/docs/android/submit).
 
 ## Additional notes
 
-- **Testing**: Write [unit tests](testing/unit_testing) for critical functionality to ensure reliability.
+- **Testing**: Write [unit tests](/docs/android/testing/unit_testing) for critical functionality to ensure reliability.
 - **Code reviews**: Always review code for adherence to these best practices.

docs/android/ci.md

@@ -26,7 +26,7 @@ We follow the same versioning convention as the core project, using [CalVer] (Ca
 
 When a pull request (PR) is opened or updated, the `pr.yml` workflow is triggered. Its goals are:
 
-- 🧹 Validate code compliance with our [linters](linter).
+- 🧹 Validate code compliance with our [linters](/docs/android/linter).
 - 🔨 Ensure the code builds successfully.
 - ✅ Run all tests to verify correctness.
 - 📦 Persist generated APKs in the GitHub Actions tab for review.
@@ -49,7 +49,7 @@ To build the application in debug on CI, we use a mock Google services file loca
 
 When a commit is pushed to the `main` branch, the `onPush.yml` workflow is triggered. Its goals are:
 
-- 🌐 Download translations from [Lokalise](../translations).
+- 🌐 Download translations from [Lokalise](/docs/translations).
 - 📝 Generate release notes.
 - 🔧 Build release variants of all applications.
 - 📤 Deploy applications to Firebase.

docs/android/codestyle.md

@@ -43,7 +43,7 @@ You can use KTLint through Gradle to automatically reformat your code:
 
 ### CI integration
 
-If a KTLint error is detected, the CI will fail, and GitHub will report it as a comment in the PR using the generated [SARIF](tips/sarif_reports.md) report.
+If a KTLint error is detected, the CI will fail, and GitHub will report it as a comment in the PR using the generated [SARIF](/docs/android/tips/sarif_reports.md) report.
 
 ## Yamllint
 

docs/android/get_started.md

@@ -95,11 +95,11 @@ If you don't need real Firebase functionality, you can use the mock configuratio
 
 ### Setting up a real Firebase project
 
-Follow our [Push notification guide](tips/fcm_push_notification) for additional setup instructions.
+Follow our [Push notification guide](/docs/android/tips/fcm_push_notification) for additional setup instructions.
 
 ## What's next?
 
-Now that you've built the app, explore the rest of the documentation to deepen your understanding of the project. A good starting point is the [Architecture guide](architecture), which explains the general structure of the codebase.
+Now that you've built the app, explore the rest of the documentation to deepen your understanding of the project. A good starting point is the [Architecture guide](/docs/android/architecture), which explains the general structure of the codebase.
 
 ## Need help?
 

docs/android/linter.md

@@ -15,7 +15,7 @@ Having no complaints from a linter doesn't mean everything is perfect. A review
 
 Using a linter ensures:
 
-- **Consistency**: Enforces a standard code style, similar to our [codestyle](codestyle).
+- **Consistency**: Enforces a standard code style, similar to our [codestyle](/docs/android/codestyle).
 - **Focus**: Allows reviewers to focus on logic rather than formatting or trivial issues.
 - **Prevention**: Helps avoid crashes and bugs by catching common mistakes, such as using APIs not supported by the target Android API level.
 
@@ -25,7 +25,7 @@ For example, failing to check the Android API version before using an unsupporte
 
 ### KTLint
 
-We use [KTLint](https://pinterest.github.io/ktlint) as our Kotlin linter, integrated via [Gradle plugin](https://github.com/JLLeitschuh/ktlint-gradle). The configuration is located in the main `build.gradle.kts` file. We mostly use the default configuration but enable [SARIF](tips/sarif_reports) reports for GitHub Actions to annotate issues in pull requests.
+We use [KTLint](https://pinterest.github.io/ktlint) as our Kotlin linter, integrated via [Gradle plugin](https://github.com/JLLeitschuh/ktlint-gradle). The configuration is located in the main `build.gradle.kts` file. We mostly use the default configuration but enable [SARIF](/docs/android/tips/sarif_reports) reports for GitHub Actions to annotate issues in pull requests.
 
 #### Ignoring an issue
 

docs/android/submit.md

@@ -12,15 +12,15 @@ First of all, thank you for your contribution! Now it's time to get feedback and
 When creating a PR, GitHub pre-fills the description with a checklist. Ensure you follow all the steps. Here's an extended checklist to help you:
 
 - **PR description**: Provide a clear and complete description of your changes.
-- **Tests**: Add all necessary tests following our [testing guidelines](testing/introduction).
+- **Tests**: Add all necessary tests following our [testing guidelines](/docs/android/testing/introduction).
 - **Documentation**: Ensure your code is properly documented.
 - **UI changes**: Include screenshots if the UI is modified.
 - **User documentation**: If user documentation needs updates, open a PR on [GitHub](https://github.com/home-assistant/companion.home-assistant).
 - **Developer documentation**: If this documentation needs updates, open a PR on [GitHub](https://github.com/home-assistant/developers.home-assistant/).
 - **Builds**: Verify that everything builds properly (app, automotive, wear) locally.
-- **Best practices**: Follow the [best practices](best_practices).
-- **Code style**: Adhere to the [code style](codestyle).
-- **Linting**: Ensure no lint issues are introduced ([linter](linter)).
+- **Best practices**: Follow the [best practices](/docs/android/best_practices).
+- **Code style**: Adhere to the [code style](/docs/android/codestyle).
+- **Linting**: Ensure no lint issues are introduced ([linter](/docs/android/linter)).
 
 ### Opening a draft PR
 

docs/android/testing/integration_testing.md

@@ -5,7 +5,7 @@ sidebar_label: "Integration testing"
 
 ## Why perform integration testing?
 
-[Unit tests](unit_testing) are great and should be your primary choice when writing tests. However, integration testing ensures that the behavior of the application in a real Android environment is validated. Integration tests run on a real Android OS through an emulator, using the same JVM that will be used by end users.
+[Unit tests](/docs/android/testing/unit_testing) are great and should be your primary choice when writing tests. However, integration testing ensures that the behavior of the application in a real Android environment is validated. Integration tests run on a real Android OS through an emulator, using the same JVM that will be used by end users.
 
 ### Testing on a real JVM
 
@@ -42,4 +42,4 @@ Android emulators are notoriously unreliable. Occasionally, a platform may fail
 
 ## Testing on Android 5 (API 21)
 
-If your tests require the WebView, you may need to follow these [tips for the Lollipop emulator](../tips/lollipop_emulator.md).
+If your tests require the WebView, you may need to follow these [tips for the Lollipop emulator](/docs/android/tips/lollipop_emulator.md).

docs/android/testing/screenshot_testing.md

@@ -25,7 +25,7 @@ We use the [Compose Preview Screenshot Testing](https://developer.android.com/st
 
 ### Advantages of compose screenshot testing
 
-- **No emulator required**: These tests do not require an emulator, making them less resource-intensive and significantly faster than [integration tests](integration_testing).
+- **No emulator required**: These tests do not require an emulator, making them less resource-intensive and significantly faster than [integration tests](/docs/android/testing/integration_testing).
 - **Fast feedback**: Developers can quickly verify UI changes without waiting for emulator boot times.
 
 ### Reference screenshots
@@ -38,7 +38,7 @@ The reference screenshots are stored under `src/debug/screenshotTest/reference`
 
 ### CI integration
 
-Our [CI pipeline](../ci) verifies the test reports for any errors. If discrepancies are found, the CI blocks the pull request until the issues are resolved.
+Our [CI pipeline](/docs/android/ci) verifies the test reports for any errors. If discrepancies are found, the CI blocks the pull request until the issues are resolved.
 
 ## Avoiding duplication in Compose previews
 

docs/android/testing/unit_testing.md

@@ -21,7 +21,7 @@ There are exceptions to this rule. Sometimes, we add tests to ensure that the be
 
 Focus on testing the **public API** of your classes rather than every single function. Writing tests for all functions, especially small ones, can lead to an overwhelming number of tests that are difficult to maintain. By concentrating on the public interface, you ensure that your tests remain relevant and resilient to internal changes.
 
-When you need to access private parts of a class for testing, consider using the [VisibleForTesting](https://developer.android.com/reference/kotlin/androidx/annotation/VisibleForTesting) annotation. This annotation allows you to expose private methods or properties for testing purposes only. The [linter](../linter) ensures that this exposure is limited to the test scope.
+When you need to access private parts of a class for testing, consider using the [VisibleForTesting](https://developer.android.com/reference/kotlin/androidx/annotation/VisibleForTesting) annotation. This annotation allows you to expose private methods or properties for testing purposes only. The [linter](/docs/android/linter) ensures that this exposure is limited to the test scope.
 
 :::note
 Avoid using `VisibleForTesting` unless absolutely necessary. It’s better to design your code in a way that doesn’t require exposing private members.
@@ -47,7 +47,7 @@ For cases where your code interacts with Android APIs that cannot be mocked or f
 ### Caveats
 
 - Robolectric does not work with JUnit 5 (follow the [issue](https://github.com/robolectric/robolectric/issues/3477)). To address this, the project includes a dependency on JUnit 4 for tests that require Robolectric.
-- Ensure that the code you are testing does not depend on the state of the Android API, as this can lead to unreliable tests. If that is the case, consider writing an [instrumented test](integration_testing).
+- Ensure that the code you are testing does not depend on the state of the Android API, as this can lead to unreliable tests. If that is the case, consider writing an [instrumented test](/docs/android/testing/integration_testing).
 
 ## Best practices for unit testing
 

docs/android/tips/compose_101.md

@@ -8,7 +8,7 @@ sidebar_label: "Jetpack Compose 101"
 To create a new screen in the app and iterate quickly, follow these steps:
 
 1. **Extract the Compose UI screen**:  
-   Create a dedicated Kotlin file for your Compose UI screen. Use the `@Preview` annotation to enable preview capabilities within the IDE. This also makes the screen compatible with [screenshot testing](../testing/screenshot_testing).
+   Create a dedicated Kotlin file for your Compose UI screen. Use the `@Preview` annotation to enable preview capabilities within the IDE. This also makes the screen compatible with [screenshot testing](/docs/android/testing/screenshot_testing).
 
 2. **Leverage hot reload**:  
    After the first build of the app, navigate to your screen. Jetpack Compose provides hot reload capabilities out of the box, allowing you to see changes in real-time. However, note that there are some limitations, such as not being able to reload changes to certain structural elements.

docs/android/tips/leak_canary.md

@@ -28,7 +28,7 @@ noLeakCanary=true
 ::::warning
 If you disable LeakCanary, you need to update the lockfile; otherwise, Gradle will complain about an issue with the dependencies.
 
-[How to update lockfiles](dependencies#updating-dependencies-and-lockfiles).
+[How to update lockfiles](/docs/android/tips/dependencies#updating-dependencies-and-lockfiles).
 ::::
 
 ## Best practices for using LeakCanary