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

This commit is contained in:
Timothy 2025-04-09 15:29:40 +02:00 committed by GitHub
parent a71c68de89
commit 95c0e63500
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
13 changed files with 23 additions and 23 deletions

View File

@ -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!

View File

@ -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.

View File

@ -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.

View File

@ -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.

View File

@ -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

View File

@ -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?

View File

@ -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

View File

@ -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

View File

@ -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).

View File

@ -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

View File

@ -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. Its better to design your code in a way that doesnt 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

View File

@ -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.

View File

@ -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