[![JDK 8 CI](https://github.com/vorpal-research/kex/actions/workflows/jdk8-ci.yml/badge.svg)](https://github.com/vorpal-research/kex/actions/workflows/jdk8-ci.yml)
[![JDK 11 CI](https://github.com/vorpal-research/kex/actions/workflows/jdk11-ci.yml/badge.svg)](https://github.com/vorpal-research/kex/actions/workflows/jdk11-ci.yml)
[![JDK 17 CI](https://github.com/vorpal-research/kex/actions/workflows/jdk17-ci.yml/badge.svg)](https://github.com/vorpal-research/kex/actions/workflows/jdk17-ci.yml)

# Kex

Kex is a platform for analysis of Java bytecode.

# Build

## Prerequisits

* JDK 8, 11 or 17 (other versions are not tested)
* OS: Linux, Windows or Mac
* Arch: amd64, x86_64, ARM (Mac only)

## Build

* build jar with all the dependencies:
    ```
    mvn clean package
    ```

* build with specific SMT solver support:
    ```
    mvn clean package -Psolver
    ```
  where `solver` can be:
    * `z3`
    * `boolector` (supported only on linux)
    * `ksmt` — used by default
    * `full-smt` — build with z3, boolector and KSMT

Run all the tests:

```
mvn clean verify [-Psolver]
```

# Usage

```
Usage: kex
    --config <arg>                  configuration file
 -cp,--classpath <arg[:arg]>        classpath for analysis, jar files and
                                    directories separated by `:`
    --depth <arg>                   depth with which to analyze the crash,
                                    required for the crash mode
 -h,--help                          print this help and quit
    --libraryTarget <arg>           package where to analyze library usages,
                                    required for the libchecker mode
 -m,--mode <arg>                    run mode: crash, symbolic, concolic,
                                    libchecker, defectchecker
    --option <section:name:value>   set kex option through command line
    --output <arg>                  directory for all temporary output
 -t,--target <arg>                  target to analyze: package, class or method;
                                    required for symbolic, concolic and defect
                                    modes
    --trace <arg>                   path to a trace file with a crash, required
                                    for the crash mode
```

# Docker

If you want to try out Kex you can use [these](https://github.com/vorpal-research/kex-dockerfile)
Docker images with the latest version installed. Example:

```bash
docker run -v ~/myproject:/home/myproject -v ~/kex-output:/home/kex-output \
 abdullin/kex-standalone:0.0.7 --classpath /home/myproject/target/myproject.jar \
 --target myproject.\* --output /home/kex-output --mode concolic
```

# Example

Consider an example class:

```kotlin
class TestClass {
    class Point(val x: Int, val y: Int)

    fun test(a: Array<Point>) {
        if (a.size == 2) {
            if (a[0].x == 10) {
                if (a[1].y == 11) {
                    error("a")
                }
            }
        }
    }
}
```

Compile that class into the jar file and run Kex on it using following command:

```bash
python ./kex.py --classpath test.jar --target TestClass --output test --mode concolic
```

Kex will produce directory `test` with all the results and logs. `test/tests`
directory will contain tests generated by Kex:

```kotlin
fun <T> unknown(): T {
  TODO()
}

fun test() {
  val generatedTerm1197 = TestClass()
  val generatedTerm1198 = arrayOfNulls<Point>(2)
  val generatedTerm1503 = Test.Point(10, 0)
  generatedTerm1198[0] = generatedTerm1503
  val generatedTerm1279 = Test.Point(0, 11)
  generatedTerm1198[1] = generatedTerm1279
  generatedTerm1197.test(generatedTerm1198)
}
```


[![Translation status](https://hosted.weblate.org/widgets/uhuruphotos/-/app-translations/svg-badge.svg)](https://hosted.weblate.org/engage/uhuruphotos/)
[![Lines of code](https://tokei.rs/b1/github/savvasdalkitsis/uhuruphotos-android)](https://github.com/savvasdalkitsis/uhuruphotos-android)
[![Join the chat at https://app.gitter.im/#/room/#uhuruphotos:gitter.im](https://badges.gitter.im/uhuruphotos/community.svg)](https://app.gitter.im/#/room/#uhuruphotos:gitter.im)
[![CodeFactor](https://www.codefactor.io/repository/github/savvasdalkitsis/uhuruphotos-android/badge/main)](https://www.codefactor.io/repository/github/savvasdalkitsis/uhuruphotos-android/overview/main)
[![GitHub Sponsor](https://img.shields.io/github/sponsors/savvasdalkitsis?label=Sponsor&logo=GitHub)](https://github.com/sponsors/savvasdalkitsis)

#  UhuruPhotos. A modern media gallery.

Welcome to UhuruPhotos. A modern media gallery, with features like backup/sync, semantic search, media map, face recognition, memories and much more*

It is built using the latest Android technologies, like Jetpack Compose, SQLDelight, Coroutines etc using an MVI architecture.

Own your memories. UhuruPhotos and LibrePhotos are both non commercial, open source projects. No user tracking, data training or advertising ever.

(* advanced features require a [LibrePhotos](https://github.com/LibrePhotos/librephotos) server)

### Note that most of development is currently happening on a [multiplatform](https://github.com/savvasdalkitsis/uhuruphotos-android/tree/multiplatform) branch which will make UhuruPhotos work across all platforms

||||

Features include:

* Photo feed with multiple views which can be changed by pinch to zoom gestures
* Multiple select in feed to share/delete multiple items at once
* Periodic background synchronization with LibrePhotos server
* Photo details view with information like date, location, gps map, people view, sharing,
  adding/removing from favourites (synced with LibrePhotos server)
* Video details view with all the above features and video playback
* Search your photos using LibrePhotos' search engine. Get search suggestions based on your photos.
* People view and suggestions for people with most photos.
* Photo map. See a heatmap of your photos. Navigate around the globe with the interactive map and
  see photos taken in the location currently viewed.
* User created and auto generated albums from LibrePhotos
* Dark/Light mode (manual and auto)
* Local photo support. This makes UhuruPhotos a viable Google Photos alternative which can be
  used as your primary camera roll viewer.
* Tablet support
* A lot of settings to help you control the app storage and memory requirements along with how
  frequently to perform synchronization with the LibrePhotos server.
* Backup/Sync local images with LibrePhotos server. Take control of your data by never having to
  worry about photo backups.
* Basic photo editing capabilities.
* Foldables support.
* ...and more

# Installation

## Play store

The app is currently in public beta on the Google Play store. You can join and try out the app

[](https://play.google.com/apps/testing/com.savvasdalkitsis.uhuruphotos)

## Manual

Both the apk and aab binaries can be found on the [latest release](https://github.com/savvasdalkitsis/uhuruphotos-android/releases/latest) page

# Sponsorship

You can sponsor the development of UhuruPhotos here

[](https://github.com/sponsors/savvasdalkitsis)

# Feedback

[![Join the chat at https://app.gitter.im/#/room/#uhuruphotos:gitter.im](https://badges.gitter.im/uhuruphotos/community.svg)](https://app.gitter.im/#/room/#uhuruphotos:gitter.im)

# Contributions

* Translation: UhuruPhotos uses Weblate for its translations. Feel free to contribute or view
existing translations at [weblate](https://hosted.weblate.org/engage/uhuruphotos/)

## Star History

  <picture>
    <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=savvasdalkitsis/uhuruphotos-android&type=Date&theme=dark" />
    <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=savvasdalkitsis/uhuruphotos-android&type=Date" />

  </picture>

This project is tested with BrowserStack.


![Now in Android](docs/images/nia-splash.jpg "Now in Android")

Now in Android App
==================

**Learn how this app was designed and built in the [design case study](https://goo.gle/nia-figma), [architecture learning journey](docs/ArchitectureLearningJourney.md) and [modularization learning journey](docs/ModularizationLearningJourney.md).**

This is the repository for the [Now in Android](https://developer.android.com/series/now-in-android)
app. It is a **work in progress** 🚧.

**Now in Android** is a fully functional Android app built entirely with Kotlin and Jetpack Compose. It
follows Android design and development best practices and is intended to be a useful reference
for developers. As a running app, it's intended to help developers keep up-to-date with the world
of Android development by providing regular news updates.

The app is currently in development. The `prodRelease` variant is [available on the Play Store](https://play.google.com/store/apps/details?id=com.google.samples.apps.nowinandroid).

# Features

**Now in Android** displays content from the
[Now in Android](https://developer.android.com/series/now-in-android) series. Users can browse for
links to recent videos, articles and other content. Users can also follow topics they are interested
in, and be notified when new content is published which matches interests they are following.

## Screenshots

![Screenshot showing For You screen, Interests screen and Topic detail screen](docs/images/screenshots.png "Screenshot showing For You screen, Interests screen and Topic detail screen")

# Development Environment

**Now in Android** uses the Gradle build system and can be imported directly into Android Studio (make sure you are using the latest stable version available [here](https://developer.android.com/studio)).

Change the run configuration to `app`.

![image](https://user-images.githubusercontent.com/873212/210559920-ef4a40c5-c8e0-478b-bb00-4879a8cf184a.png)

The `demoDebug` and `demoRelease` build variants can be built and run (the `prod` variants use a backend server which is not currently publicly available).

![image](https://user-images.githubusercontent.com/873212/210560507-44045dc5-b6d5-41ca-9746-f0f7acf22f8e.png)

Once you're up and running, you can refer to the learning journeys below to get a better
understanding of which libraries and tools are being used, the reasoning behind the approaches to
UI, testing, architecture and more, and how all of these different pieces of the project fit
together to create a complete app.

# Architecture

The **Now in Android** app follows the
[official architecture guidance](https://developer.android.com/topic/architecture)
and is described in detail in the
[architecture learning journey](docs/ArchitectureLearningJourney.md).

# Modularization

The **Now in Android** app has been fully modularized and you can find the detailed guidance and
description of the modularization strategy used in
[modularization learning journey](docs/ModularizationLearningJourney.md).

# Build

The app contains the usual `debug` and `release` build variants.

In addition, the `benchmark` variant of `app` is used to test startup performance and generate a
baseline profile (see below for more information).

`app-nia-catalog` is a standalone app that displays the list of components that are stylized for
**Now in Android**.

The app also uses
[product flavors](https://developer.android.com/studio/build/build-variants#product-flavors) to
control where content for the app should be loaded from.

The `demo` flavor uses static local data to allow immediate building and exploring of the UI.

The `prod` flavor makes real network calls to a backend server, providing up-to-date content. At
this time, there is not a public backend available.

For normal development use the `demoDebug` variant. For UI performance testing use the
`demoRelease` variant.

# Testing

To facilitate testing of components, **Now in Android** uses dependency injection with
[Hilt](https://developer.android.com/training/dependency-injection/hilt-android).

Most data layer components are defined as interfaces.
Then, concrete implementations (with various dependencies) are bound to provide those interfaces to
other components in the app.
In tests, **Now in Android** notably does _not_ use any mocking libraries.
Instead, the production implementations can be replaced with test doubles using Hilt's testing APIs
(or via manual constructor injection for `ViewModel` tests).

These test doubles implement the same interface as the production implementations and generally
provide a simplified (but still realistic) implementation with additional testing hooks.
This results in less brittle tests that may exercise more production code, instead of just verifying
specific calls against mocks.

Examples:
- In instrumentation tests, a temporary folder is used to store the user's preferences, which is
  wiped after each test.
  This allows using the real `DataStore` and exercising all related code, instead of mocking the
  flow of data updates.

- There are `Test` implementations of each repository, which implement the normal, full repository
  interface and also provide test-only hooks.
  `ViewModel` tests use these `Test` repositories, and thus can use the test-only hooks to
  manipulate the state of the `Test` repository and verify the resulting behavior, instead of
  checking that specific repository methods were called.

To run the tests execute the following gradle tasks:

- `testDemoDebug` run all local tests against the `demoDebug` variant.
- `connectedDemoDebugAndroidTest` run all instrumented tests against the `demoDebug` variant.

**Note:** You should not run `./gradlew test` or `./gradlew connectedAndroidTest` as this will execute
tests against _all_ build variants which is both unecessary and will result in failures as only the
`demoDebug` variant is supported. No other variants have any tests (although this might change in future).

## Screenshot tests
A screenshot test takes a screenshot of a screen or a UI component within the app, and compares it
with a previously recorded screenshot which is known to be rendered correctly.

For example, Now in Android has [screenshot tests](https://github.com/android/nowinandroid/blob/main/app/src/testDemo/kotlin/com/google/samples/apps/nowinandroid/ui/NiaAppScreenSizesScreenshotTests.kt)
to verify that the navigation is displayed correctly on different screen sizes
([known correct screenshots](https://github.com/android/nowinandroid/tree/main/app/src/testDemo/screenshots)).

Now In Android uses [Roborazzi](https://github.com/takahirom/roborazzi) to run screenshot tests
of certain screens and UI components. When working with screenshot tests the following gradle tasks are useful:

- `verifyRoborazziDemoDebug` run all screenshot tests, verifying the screenshots against the known
correct screenshots.
- `recordRoborazziDemoDebug` record new "known correct" screenshots. Use this command when you have
made changes to the UI and manually verified that they are rendered correctly. Screenshots will be
stored in `modulename/src/test/screenshots`.
- `compareRoborazziDemoDebug` create comparison images between failed tests and the known correct
images. These can also be found in `modulename/src/test/screenshots`.

**Note:** The known correct screenshots stored in this repository are recorded on CI using Linux. Other
platforms may (and probably will) generate slightly different images, making the screenshot tests fail.
When working on a non-Linux platform, a workaround to this is to run `recordRoborazziDemoDebug` on the
`main` branch before starting work. After making changes, `verifyRoborazziDemoDebug` will identify only
legitimate changes.

For more information about screenshot testing
[check out this talk](https://www.droidcon.com/2023/11/15/easy-screenshot-testing-with-compose/).

# UI
The app was designed using [Material 3 guidelines](https://m3.material.io/). Learn more about the design process and
obtain the design files in the [Now in Android Material 3 Case Study](https://goo.gle/nia-figma) (design assets [also available as a PDF](docs/Now-In-Android-Design-File.pdf)).

The Screens and UI elements are built entirely using [Jetpack Compose](https://developer.android.com/jetpack/compose).

The app has two themes:

- Dynamic color - uses colors based on the [user's current color theme](https://material.io/blog/announcing-material-you) (if supported)
- Default theme - uses predefined colors when dynamic color is not supported

Each theme also supports dark mode.

The app uses adaptive layouts to
[support different screen sizes](https://developer.android.com/guide/topics/large-screens/support-different-screen-sizes).

Find out more about the [UI architecture here](docs/ArchitectureLearningJourney.md#ui-layer).

# Performance

## Benchmarks

Find all tests written using [`Macrobenchmark`](https://developer.android.com/topic/performance/benchmarking/macrobenchmark-overview)
in the `benchmarks` module. This module also contains the test to generate the Baseline profile.

## Baseline profiles

The baseline profile for this app is located at [`app/src/main/baseline-prof.txt`](app/src/main/baseline-prof.txt).
It contains rules that enable AOT compilation of the critical user path taken during app launch.
For more information on baseline profiles, read [this document](https://developer.android.com/studio/profile/baselineprofiles).

> [!NOTE]
> The baseline profile needs to be re-generated for release builds that touch code which changes app startup.

To generate the baseline profile, select the `benchmark` build variant and run the
`BaselineProfileGenerator` benchmark test on an AOSP Android Emulator.
Then copy the resulting baseline profile from the emulator to [`app/src/main/baseline-prof.txt`](app/src/main/baseline-prof.txt).

## Compose compiler metrics

Run the following command to get and analyse compose compiler metrics:

```bash
./gradlew assembleRelease -PenableComposeCompilerMetrics=true -PenableComposeCompilerReports=true
```

The reports files will be added to [build/compose-reports](build/compose-reports). The metrics files will also be
added to [build/compose-metrics](build/compose-metrics).

For more information on Compose compiler metrics, see [this blog post](https://medium.com/androiddevelopers/jetpack-compose-stability-explained-79c10db270c8).

# License

**Now in Android** is distributed under the terms of the Apache License (Version 2.0). See the
[license](LICENSE) for more information.


[![](https://img.shields.io/badge/Lifecycle-Stable-brightgreen)](https://github.com/Camunda-Community-Hub/community/blob/main/extension-lifecycle.md#stable-)
[![](https://img.shields.io/badge/Community%20Extension-An%20open%20source%20community%20maintained%20project-FF4700)](https://github.com/camunda-community-hub/community)
![Compatible with: Camunda Platform 7](https://img.shields.io/badge/Compatible%20with-Camunda%20Platform%207-26d07c)
![Compatible with: Camunda Platform 8](https://img.shields.io/badge/Compatible%20with-Camunda%20Platform%208-26d07c)
![Supported Camunda versions](https://img.shields.io/badge/Camunda%20Version-%207.17%20to%207.20%20and%208-orange.svg)

![Camunda Logo](docs/assets/img/Favicons-Circle-Colour.png)

# Camunda Process Test Coverage

This Camunda Platform 7 and Platform 8 community extension **visualises** test process **paths** and **checks** your process model **coverage** ratio. Running  typical JUnit tests now leaves **html** files in your build output. Just open one and check yourself what your test did:

![Coverage report](docs/assets/img/flowcov_coverage_report.png)

## Highlights

* **Visually verify** the paths covered by individual tests **methods** and whole test **classes**
* Visually check gateway **expressions** and transaction borders (**save points**) used by your process
* Calculate and **verify** the nodes (_and_ sequence flow) **coverage** ratio reached by tests methods and classes.

## Just use it

* Integrates with all versions of Camunda Platform 7 starting with 7.17.0 and upwards as well as Camunda Platform 8
* Is continuously checked against the latest Camunda Platform 7 releases (check out our compatibility CI/CD pipeline)
* Tested with JDKs 11 and 17
* Works with Java starting with 1.8 and following (depending on support by version of used Camunda Platform)
* Supports **JUnit 4.13.1+** (4.11 does not work) or **JUnit 5**
* Can be used inside Spring Tests

## Documentation

If you are interested in further documentation, please check our [Documentation Page](https://camunda-community-hub.github.io/camunda-process-test-coverage/snapshot/index.html)

## Installation

 Add a **Maven test dependency** to your project
0
### JUnit5 (Platform 7 or Platform 8)

```xml
<dependency>
  <groupId>org.camunda.community.process_test_coverage</groupId>
  <artifactId>camunda-process-test-coverage-junit5-platform-7</artifactId>
  <!-- <artifactId>camunda-process-test-coverage-junit5-platform-8</artifactId> -->
  <version>${camunda-process-test-coverage.version}</version>
  <scope>test</scope>
</dependency>
```

## Configuration

Use the **ProcessCoverageInMemProcessEngineConfiguration**, e.g. in your `camunda.cfg.xml` (only needed for Platform 7)

```xml
<bean id="processEngineConfiguration"
   class="org.camunda.community.process_test_coverage.engine.platform7.ProcessCoverageInMemProcessEngineConfiguration">
   ...
</bean>
```

Use the **ProcessEngineCoverageExtension** as your process engine JUnit extension (available for Platform 7 and Platform 8)

Either use `@ExtendWith`

Java
```java
@ExtendWith(ProcessEngineCoverageExtension.class)
public class MyProcessTest
```

Kotlin
```kotlin
@ExtendWith(ProcessEngineCoverageExtension::class)
class MyProcessTest
```
or `@RegisterExtension`

If you register the extension on a non-static field, no class coverage and therefore no report will be generated. This is due to the fact, that an instance of the extension will be created per test method.

The extension provides a Builder for programmatic creation, which takes either a path to a configuration resource, a process engine configuration or if nothing is passed uses the default configuration resources path (`camunda.cfg.xml`).

The process engine configuration needs to be configured for test coverage. So use **either** the provided `ProcessCoverageInMemProcessEngineConfiguration`, `SpringProcessWithCoverageEngineConfiguration` or initialize the configuration with `ProcessCoverageConfigurator.initializeProcessCoverageExtensions(configuration)`.

If you use Java:
```java
@RegisterExtension
static ProcessEngineCoverageExtension extension = ProcessEngineCoverageExtension
        .builder().assertClassCoverageAtLeast(0.9).build();
```

If you prefer Kotlin:
```kotlin
companion object {
    @JvmField
    @RegisterExtension
    var extension: ProcessEngineCoverageExtension = ProcessEngineCoverageExtension
            .builder(ProcessCoverageInMemProcessEngineConfiguration())
            .assertClassCoverageAtLeast(1.0).build()
}
```

## Running the tests

Running your JUnit tests now leaves **html** files for individual test methods as well as whole test classes in your project's `target/process-test-coverage` folder. Just open one, check yourself - and have fun with your process tests! :smile:

## News and Noteworthy & Contributors

There are plenty of contributors to this project. Its initial design has been created by the WDW eLab GmbH and some others,
but then the project has been abandoned for some time and received a full rewrite including the new architecture by members
of flowcov.io squad and BPM craftsmen from Holisticon AG. We appreciate any help and effort you put into maintenance
discussion and further development.

Please check the release notes of [individual releases](https://github.com/camunda-community-hub/camunda-process-test-coverage/releases) for the changes and involved contributors.

## License
[Apache License, Version 2.0](https://www.apache.org/licenses/LICENSE-2.0). See [LICENSE](LICENSE.md) file.