analytics-android-integrations

Monorepo storing Segment's analytics Android integrations. You can find additional documentation for this repo in the guides directory.

Usage

You can open the root project on Android Studio. All integrations are included by default.

Linter and formatter

We use Spotless and Android's linter to format our code, run:

$ ./gradlew lint spotlessCheck // Linter
$ ./gradlew lintFix spotlessApply // Formatter

Tests

You can run all the tests using:

$ ./gradlew test [--rerun-tasks]

Build

You are required to sign your builds. To set up the signature, you need to export the following environment variables:

SIGNATURE_KEY_ID=<Key id>
SIGNATURE_SECRET_FILE=<Path where the key lives>
SIGNATURE_PASSWORD=<Password>

You can add these to the Android Studio configuration, or in the terminal. For more information see here.

When that's ready, you can run the build command:

$ ./gradlew build jarRelease

Release

You can release SNAPSHOTS (with your own credentials) running:

$ ./gradlew uploadArchives

For releasing production versions, please check our Segment's internal documentation.

Migrating Destinations to the Monorepo

You can find more information on migrating a destination here.

Setup Android local environment 📝

1. Requirements:

Android Studio version 3+ Gradle version 6+

2. Clone the repo

git clone https://github.com/segmentio/analytics-android-integrations.git

3. Open the project with Android Studio

Click on File => Open on the toolbar menu, then select the project and Open

4. Run the test

Click Terminal on the bottom tab to open the terminal

./gradlew test

5. Run the sample app

Select sample module on the top toolbar menu drop-down: and click run

Semantic Versioning

Version X.Y.Z

1 Pre-release versions

Version 1.0.0-alpha.1: is the pre-official release of the integration SDK. Here the SDK is still being test run

2 Initial Release

Version 1.0.0: is initial official stable release of the integration SDK going into production

3 Patch Release

Version 1.0.Z: is the release when a bug is fixed in the integration SDK, Z must be incremented. i.e 1.0.1

4 Minor Version

Version 1.Y.0: is the release when a backwards compatible feature is introduced to the integration SDK. Y must be incremented and patch version number must be reset to 0. i.e 1.1.0

5 Major Version

Version X.0.0: is the release when a backwards incompatible change is introduced to the integration SDK. X must be incremented while the minor and patch version numbers must be reset to 0. i.e 2.0.0

Before Submitting a PR

Important PRs from non-Segment employees that change circleci or buildkite configuration (CI) will be rejected automatically. Do not change the CI configuration.

• Run linter and formatter

$ ./gradle lint spotlessCheck
$ ./gradle lintFix spotlessApply

• Check if all tests pass

$ ./gradlew test

• Check if implementation works according to the PR descriptions
• Check if there are breaking changes in this PR
• Check if the new changes could potentially break anything in the future.
• Check if there are any structural or architectural changes
• Check for overall best practices

How to submit a PR

Commit Process

1 Branches should include ticket number e.g DAND-6-TASK-NAME

2 Commits should include ticket number and a verb for action e.g DAND-6-Fix - or DAND-6-Add or DAND-6-Update

---

Before Submitting PR Requirements

1 You must run spotless for code formatting before committing

./gradlew lintFix spotlessApply

2 You must run the tests, ensuring they all pass

./gradlew test

3 Include a well detailed title and description

Ready to go 🚀

How to review a PR

Here's a checklist of what to look for when reviewing a PR:

• No changes have been made to .circleci.
• No changes have been made to .buildkite.
• CircleCI SaaS has completed successfully.
• Buildkite CI has completed successfully (only for non-forked repos).
• There is enough testing coverage for the changes.
• If the change is updating an integration's SDK, the Changelog link is included in the description of the PR.
• Big changes are split on multiple commits.
• The version has changed following SemVer for functional changes.

If any of this checks fail, the PR will be rejected.