NOTE: Depending on your platform you may need to change the way how the different parameters are escaped in the command.
## Logging
### Usage
...
...
@@ -87,7 +96,7 @@ DP-3T SDK uses its own Logger class for logs. Levels depend on the type of the b
## Dependencies
All external dependencies must be compliant with EUPL (https://tldrlegal.com/license/european-union-public-licence).
All dependencies used in this project must be listed in the [LIBRARIES](LIBRARIES.md) file together with their licence, version information and a changelog link.
All dependencies used in this project must be listed in the [LIBRARIES](LIBRARIES.md) file together with their license, version information and a changelog link.
Whenever someone adds a new dependency to the project it is their responsibility to make sure that its license is compliant and the information about the dependency is added to the [LIBRARIES](LIBRARIES.md).
### When building in TEHIK's GitLab CI
...
...
@@ -123,17 +132,24 @@ Steps to update the pins:
The application uses different build flavours to target different environments.
We currently have the following environments:
1. icefire
1. icefire - Used by Icefire for internal dev. Usually IP blocked.
2. tehikdev - Development enviroment. Used by app devs, designers and testers. Can be used with TARA test users, see the wiki for the list of users.
2. tehiktest - Test environment. More stable than tehikdev. Used for testing.
3. tehikprod - Live production environment. Requires logging to the live Patient Portal. Can't be used with test users.
There are 2 main configurations to define for a flavour:
1. Environment interface -> This holds application and SDK configuration variables, urls, etc
2. Network Security Configuration -> SSL pinning setup. See the previous section about this
1. Environment interface -> This holds application and SDK configuration variables, urls, etc. See:
1.`IcefireEnvironment.kt`
2.`TehikdevEnvironment.kt`
3.`TehiktestEnvironment.kt`
4.`TehikprodEnvironment.kt`
2. Network Security Configuration -> SSL pinning setup. See the previous section about this.
## Close contact configuration
As the app/user's device is the one that calculates the close contact risk and decides if a notification should be displayed we can configure the calculation values. Contact detection params are set via DP3T.setMatchingParameters() method.
As the app/user's device is the one that calculates the close contact risk and decides if a notification should be displayed we can configure the calculation values. Contact detection parameters are set via `DP3T.setMatchingParameters()` method.
`Environment` implementation optionally provides a `CloseContactConfiguration` class. If that value is `null` then the default SDK configuration is used.
...
...
@@ -143,8 +159,7 @@ The calculation is the following:
| 30.07.2020 | Harri Kirik | Updated as per review feedback. |
| 30.09.2020 | Harri Kirik | Added a note about the link to release build binaries. |
## Goal
...
...
@@ -95,12 +96,14 @@ This document contains the release procedure of the Hoia Android application. De
1. After the build navigate to the artifacts section at the CI and press the "Keep" button. This makes sure that release binaries are kept and not deleted after N days like develop ones. See https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-artifacts for more.
6. Download the public release APK from TEHIK along with the matching ProGuard mapping file. See https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-artifacts for more.
6. Add the link of the TEHIK CI `master` branch release build to the JIRA release task.
7. Download the public release APK from TEHIK along with the matching ProGuard mapping file. See https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-artifacts for more.
1. The release APK can be found from the `Artifacts/app/build/outputs/apk/tehikrelease/` folder
2. The release APK ProGuard mapping can be found from the `Artifacts/app/build/outputs/mapping/tehikreleaseRelease/` folder
7. Test the release binary that will be uploaded to Play Store. Including, but not limited to:
8. Test the release binary that will be uploaded to Play Store. Including, but not limited to:
1. New features that were added since the last release
...
...
@@ -154,7 +157,7 @@ This document contains the release procedure of the Hoia Android application. De
3. Clean install & onboarding with the new release
4. Infection Confirmation flow
4. Infection Confirmation flow (with the "not sick" result if non other is possible)
5. My Data delete data flow
...
...
@@ -162,11 +165,11 @@ This document contains the release procedure of the Hoia Android application. De
7. Turning off BLE from system settings and re-enabling it from app settings
8. Add a comment to the release JIRA task, write up all the tests you did and the results of these tests
9. Add a comment to the release JIRA task, write up all the tests you did and the results of these tests
1. If any of the tests fail then create fix tasks for these and discuss with the team on how to proceed
9. If everything is ready then upload the release APK, Proguard mapping and release notes to Play Store to the appropriate track (depending if this is a public or a private release) and submit these for a review
10. If everything is ready then upload the release APK, Proguard mapping and release notes to Play Store to the appropriate track (depending if this is a public or a private release) and submit these for a review
1. If you personally do not have access then delegate to TEHIK DevOps. Also forward them the JIRA release task with all the collected information.