I built and customized three instances of The Digital Picture Frame. It’s so simple yet such a great system setup that I fell in love.

Today I want to share a method to use USB Media Sticks to view our photos. This method uses Udiskie, while the traditional method (explained by Wolfgang Männel in Expand your digital picture frame use cases with Pi3D integrated USB media stick support) uses python scripts to achieve a very similar goal.

I recommend reading both articles and picking the method you feel more comfortable in. Both methods are mostly feature compatible in the end — having an auto-mounted USB device.

What This Setup Does

• Use Udiskie to manage USB auto-loading/reloading
• Modify Picture Frame’s configuration to read photos from the automount directory
• Prepare the system to have Udiskie running when the system boots

Installing Udiskie

udiskie is a udisks2 front-end that allows to manage removable media such as CDs or flash drives from userspace.

Let’s install udiskie by running one simple command:

sudo apt install udiskie udisks2

And although we won’t use it, udiskie has a cool UI!

Setup Udiskie Auto-Start

To setup udiskie to work without password prompt and on boot we must first install PolicyKit:

sudo apt-get install policykit-1

And then let’s create a policy configuration with required permissions. Let’s create the file with sudo nano /etc/polkit-1/rules.d/99-udisks2.rules and the following content:

polkit.addRule(function(action, subject) {
    if (action.id.indexOf("org.freedesktop.udisks2.filesystem-mount") === 0 &&
        subject.isInGroup("plugdev")) {
        return polkit.Result.YES;
    }
});

Finally, let’s create a udiskie.service file to ensure udiskie is working all the time. Let’s use sudo nano /etc/systemd/system/udiskie.service:

[Unit]
Description=Auto-mount USB drives with udiskie
After=graphical.target network-online.target

[Service]
User=pi
ExecStart=/usr/bin/udiskie --automount
Restart=on-failure

[Install]
WantedBy=default.target

Then let’s restart all services that are used:

sudo systemctl restart polkit
sudo systemctl restart udisks2
sudo systemctl restart udiskie

And we’re done with udiskie!

Modifying PicFrame Configuration

Configuration change to PicFrame is simple. We’re going to change the photo directory to /media, the location where drives are mounted (e.g. /media/pi/E342-JS2J)

nano picframe_data/config/configuration.yaml

And inside model, let’s change this line:

pic_dir: "/media" # default="/home/pi/Pictures", root folder for images

And we are done with PicFrame Configuration! With this we should be done! Reboot the system and insert a flash drive or two to see if pictures from all drives are coming to PicFrame.

Expand your digital picture frame use cases with Pi3D integrated USB media stick support using UDiskie – Original at https://dev.to/leocolman/expand-your-digital-picture-frame-use-cases-with-pi3d-integrated-usb-media-stick-support-using-2737 by Leonardo Colman Lopes

I built and customized 3 instances of The Digital Picture Frame. It’s so simple yet such a great system setup that I fell in love.

People have built such awesome setups for this small utility, and passion drove me to my calling: It’s my time to hack a device and turn it into a Picture Frame.

My chosen target? An old TV Box:

It has everything needed:

• A Hackable Android TV that I can turn into Linux
• A way to boot a custom system (i.e. an SD card)
• A way to mount different media for photo display (i.e. Flash Drives)

Let’s dive in this journey and perhaps you will have a TV Box-Frame too!

A Word of Warning First:
Not all TV Boxes will work. Some (if not most) are not able to host a custom system. Be wary when following this as a guide as your setup might vary.

Installing Armbian

Armbian is a “Minimal custom Debian or Ubuntu based Linux perfect for server and IOT”. We’re going to pick it as most TV Boxes are ARM-based, and Armbian is perfect for the job.

We are going to follow the guide CSC Armbian for RK322x TV box boards.

For this tutorial we’re going to use a RK3229 as our pilot chip. It’s available in many TV Boxes and is not hard to setup

Discovering the Chipset

If you’re not sure that your TV Box chip is supported, download and install through the TV Box the app Z-CPU or the FLOSS App CPU Info.

In the app we’re looking for information on the chipset. Chipsets of the format RK322X are supported.

Unbricking Instructions

Technically, rockchip devices cannot be bricked. In some cases a screw-up might require repairing of the original system, and the unbricking instructions from CSC Armbian for RK322x TV box boards can help.

Installing Using SD Card

We’re going to use an SDXC Card (Or most commonly an SD Card + Adapter). This card will hold our entire operating system*, and will be plugged in the machine 24/7. I recommend anything 8GB or bigger, but realistically 3GB is the entire system + files.

* You could instead install the system directly to the machine. I couldn’t get that to work reliably and preferred the permanent SD approach.

Preparing the TV Box with Multitool

The Multitool is a small but powerful tool to make changes to our RK322X.

• Multitool – A small but powerful image for RK322x TV Box maintenance
  

Let’s flash the Multitool image onto the SD Card first. You can use any tool for it, but I like Balena Etcher.

Our goal with Multitool is straightforward:

1. Flash Multitool to the SD Card
2. Put the card in the TV Box and power on. After a few seconds Multitool should appear on the display
3. RECOMMENDED Make a backup of the current firmware with Backup Flash
4. Select Install Jump Start for Armbian

And we’re done with Multitool! Power the device down and retrieve the SD card. Store your backup and get ready to flash it again!

Choosing an Image

CSC Armbian for RK322x TV box boards explains how to make a build, but we are going to grab a pre-built binary from armbian/community.

Let’s take the image Rk322x-box_bookworm_current_6.12.15_minimal.img.xz

As we’ve done earlier, let’s flash it to our SD card using Balena Etcher.
After flashing, insert the SD with the new Armbian image on the device and power it on.

Welcome to Armbian

If everything worked correctly, you should now have a shell inside Armbian asking you for information.
The most important point here is that we’ll create a normal user account with the username pi. This will be important to follow The Digital Picture Frame without too many changes on the scripts.

To finish configuring Armbian, let’s run two commands:

• sudo rk322x-config and select your board characteristics to enable leds, wifi chips, etc.
• armbian-config to configure timezone, locales and other personal options

At this point you can also connect your device to your network and connect to it through ssh.

Install The Digital PictureFrame

From this point on we are done with the system and can start playing with PictureFrame itself. We are going to follow the guide for Raspberries as close as we can until we get it working.

Let’s first install necessary dependencies:

sudo apt update
sudo apt install build-essential pkg-config python3-dev python3-pip python3.11-venv libjpeg-dev libtiff-dev libfreetype6-dev zlib1g-dev liblcms2-dev libwebp-dev tcl-dev tk-dev libharfbuzz-dev libfribidi-dev libxcb1-dev libpng-dev cmake ninja-build git libgles2-mesa libegl1-mesa libgl1-mesa-dri libglapi-mesa libsdl2-2.0-0 libsdl2-dev

And compile + install HEIF, as the ones from Armbian aren’t updated enough:

cd ~
git clone https://github.com/strukturag/libheif.git
cd libheif

mkdir build && cd build
cmake ..
make -j$(nproc)
sudo make install

Then let’s prepare a Python VEnv to install picframe into:

mkdir venv_picframe

python -m venv /home/pi/venv_picframe

source venv_picframe/bin/activate

And finally, let’s install PicFrame!

pip install picframe

To know it worked, we should see after a long (maybe 30+ minutes) some positive messages:

Successfully installed IPTCInfo3-2.1.4 Pillow-11.1.0 PyYAML-6.0.2 defusedxml-0.7.1 ninepatch-0.2.0 numpy-2.2.3 paho-mqtt-2.1.0 pi-heif-0.21.0 pi3d-2.53 picframe-2024.11.1 pysdl2-0.9.17

Configuring PicFrame

On Configuring PicFrame we have clear instructions on how to configure picframe. Let’s do that now!

You will be asked three questions for the basic configuration settings. Just hit Enter to keep the default for now. You can always change these settings later.

mkdir {Pictures,DeletedPictures}

picframe -i /home/pi/

You don’t need to make changes in the configuration file at this point. But you probably want to customize it later. In that case, open it with

nano ~/picframe_data/config/configuration.yaml

Starting Picframe

Let’s create a script to start our Picframe:

nano start_picframe.sh

#!/bin/bash
source /home/pi/venv_picframe/bin/activate # activate phyton virtual env
picframe &  #start picframe

while true; do sleep 10; done # Keep the script running

Save and close and make the file executable with

chmod +x ./start_picframe.sh

And now, finally, let’s run our PicFrame

./start_picframe.sh

And if everything went through correctly, we’ll get a beautiful mug on the screen:

Auto Starting Picframe

This part will work a bit different from Autostarting PictureFrame, so pay close attention!

Let’s start by creating the file picframe.service with sudo nano /etc/systemd/system/picframe.service and pasting the following content inside:

[Unit]
Description=PictureFrame Startup
After=multi-user.target

[Service]
Type=simple
ExecStart=/bin/bash /home/pi/start_picframe.sh
Restart=on-failure  # Only restart if it fails
RestartSec=10       # Wait 10 seconds before restarting
User=pi
WorkingDirectory=/home/pi
Environment=DISPLAY=:0
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Then reload systemd and enable the brand new service:

sudo systemctl daemon-reload
sudo systemctl enable picframe.service
sudo systemctl start picframe.service

We can check the service status by running

systemctl status picframe.service

Enable Autologin on tty1

The pi user doesn’t have auto-login enabled, and we must have it if we don’t want to stare at a login screen. Let’s change that by creating an override for getty@tty1:

sudo mkdir -p /etc/systemd/system/getty@tty1.service.d
sudo nano /etc/systemd/system/getty@tty1.service.d/override.conf

And paste this inside to enable auto-login:

[Service]
ExecStart=
ExecStart=-/sbin/agetty --autologin pi --noclear %I $TERM

PictureFrame should now start on boot!

Converting an old TV Box into an epic Picture Frame – Original at https://dev.to/leocolman/converting-an-old-tv-box-into-an-epic-picture-frame-3iob by Leonardo Colman Lopes

1. Introduction

Automated screenshot testing is essential in Android development for ensuring UI consistency across updates and devices. Manually verifying UI changes is time-consuming and error-prone, making automation a vital practice.

In this guide, we’ll show how to use Kotest for capturing screenshots and Ktor for uploading them to a local server. This setup streamlines UI validation, improves efficiency, and centralizes screenshot storage for better collaboration and quality assurance.

2. Setup

To get started with automated screenshot testing using Kotest and Ktor, we’ll need to prepare our project by configuring the necessary tools and libraries.

Update our project’s build.gradle.kts file to include the required libraries for testing and screenshot uploads. Below are the key dependencies:

dependencies {
    // Kotest for writing tests
    androidTestImplementation("br.com.colman:kotest-runner-android:${version}")

    // Fuel library for uploading screenshots
    androidTestImplementation("com.github.kittinunf.fuel:fuel:${version}")
}

Here:

• Kotest provides the framework for writing and running tests.
• Kotest-Android provides specific bindings for running Android tests.
• Fuel simplifies HTTP requests for uploading screenshots during tests.

3. Preparing a Local Server to Receive Screenshots

A critical component of automated screenshot testing is a server to store the captured images for validation or archival purposes. We’ll use Ktor, a lightweight Kotlin-based framework, to set up a local server capable of handling screenshot uploads.

Create a Kotlin script file named refresh_screenshots.main.kts. This script will configure and launch a local server using Ktor.

3.1. Disabling Animations

Animations in the Android emulator can affect screenshot consistency. The script disables them using ADB commands:

fun disableAnimations() {
    listOf(
        "adb shell settings put global window_animation_scale 0",
        "adb shell settings put global transition_animation_scale 0",
        "adb shell settings put global animator_duration_scale 0"
    ).forEach { command ->
        try {
            val process = Runtime.getRuntime().exec(command)
            process.waitFor()
        } catch (e: Exception) {
            println("Error while trying to disable animations via ADB: ${e.localizedMessage}")
        }
    }
    println("Animations in the emulator have been disabled")
}

3.2. Starting the Ktor Server

The server listens on port 8081 and handles file uploads. Uploaded screenshots are stored in language-specific directories based on parameters (lang and country) in the request:

fun startServer(): NettyApplicationEngine {
    return embeddedServer(Netty, port = 8081) {
        install(ContentNegotiation) {
            json()
        }
        routing {
            post("/upload") {
                val multipart = call.receiveMultipart()
                val lang = call.parameters["lang"] ?: "unknown"
                val country = call.parameters["country"] ?: "unknown"

                multipart.forEachPart { part ->
                    if (part is PartData.FileItem) {
                        val countryHyphen = if (country.isNotBlank()) "-$country" else ""
                        val dir = File("../fastlane/metadata/android/${lang}${countryHyphen}/images/phoneScreenshots")
                        if (!dir.exists()) {
                            dir.mkdirs()
                        }
                        val file = File(dir, part.originalFileName ?: "screenshot.png")
                        part.streamProvider().use { input -> file.outputStream().buffered().use { input.copyTo(it) } }
                    }
                    part.dispose()
                }
                call.respondText("File uploaded successfully", status = HttpStatusCode.OK)
            }
        }
    }.start(wait = false)
}

3.3. Running Tests and Handling the Server

The script runs Android tests using Gradle and stops the server once the tests are completed:

val server = startServer()

disableAnimations()

// Run Android tests
val process = ProcessBuilder(
    "../gradlew",
    "connectedFdroidDebugAndroidTest",
    "-Pandroid.testInstrumentationRunnerArguments.class=br.com.colman.petals.ScreenshotTakerTest"
).inheritIO().start()
val exitCode = process.waitFor()

server.stop(1000, 10000)

3.4. Full Script

Let’s take a look at the final result by merging all the scripts and adding relevant imports:

#!/usr/bin/env kotlin

@file:DependsOn("org.jetbrains.kotlinx:kotlinx-coroutines-core-jvm:1.10.1")
@file:DependsOn("io.ktor:ktor-server-core-jvm:2.3.13")
@file:DependsOn("io.ktor:ktor-server-netty-jvm:2.3.13")
@file:DependsOn("io.ktor:ktor-server-content-negotiation-jvm:2.3.13")
@file:DependsOn("io.ktor:ktor-serialization-kotlinx-json-jvm:2.3.13")
@file:DependsOn("io.ktor:ktor-server-host-common-jvm:2.3.13")

import io.ktor.http.*
import io.ktor.http.content.*
import io.ktor.serialization.kotlinx.json.*
import io.ktor.server.application.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*
import io.ktor.server.plugins.contentnegotiation.*
import io.ktor.server.request.*
import io.ktor.server.response.*
import io.ktor.server.routing.*
import java.io.File

// Function to disable animations via ADB
fun disableAnimations() {
  listOf(
    "adb shell settings put global window_animation_scale 0",
    "adb shell settings put global transition_animation_scale 0",
    "adb shell settings put global animator_duration_scale 0"
  ).forEach { command ->
    try {
      val process = Runtime.getRuntime().exec(command)
      process.waitFor()
    } catch (e: Exception) {
      println("Error while trying to disable animations via ADB: ${e.localizedMessage}")
    }
  }
  println("Animations in the emulator have been disabled")
}

fun startServer(): NettyApplicationEngine {
  return embeddedServer(Netty, port = 8081) {
    install(ContentNegotiation) {
      json()
    }
    routing {
      post("/upload") {
        val multipart = call.receiveMultipart()
        val lang = call.parameters["lang"] ?: "unknown"
        val country = call.parameters["country"] ?: "unknown"

        multipart.forEachPart { part ->
          if (part is PartData.FileItem) {
            val countryHyphen = if (country.isNotBlank()) "-$country" else ""
            val dir = File("../fastlane/metadata/android/${lang}${countryHyphen}/images/phoneScreenshots")
            if (!dir.exists()) {
              dir.mkdirs()
            }
            val file = File(dir, part.originalFileName ?: "screenshot.png")
            part.streamProvider().use { input -> file.outputStream().buffered().use { input.copyTo(it) } }
          }
          part.dispose()
        }
        call.respondText("File uploaded successfully", status = HttpStatusCode.OK)
      }
    }
  }.start(wait = false)
}


// Start the server
val server = startServer()

// Disable animations
disableAnimations()

// Run Android tests
val process = ProcessBuilder(
  "../gradlew",
  "connectedFdroidDebugAndroidTest",
  "-Pandroid.testInstrumentationRunnerArguments.class=br.com.colman.petals.ScreenshotTakerTest"
).inheritIO().start()
val exitCode = process.waitFor()

// Stop the server
server.stop(1000, 10000)

4. Writing a Screenshot Test in Kotest

This section demonstrates how to create comprehensive screenshot tests using Kotest in an Android project. The provided code integrates Jetpack Compose testing with screenshot capture and upload functionality, supporting multiple locales and organized storage on a local server.

4.1. Key Features of the Screenshot Tests

1. Multi-Locale Testing
The tests iterate over a list of language (lang) and country (country) codes, ensuring the UI is tested across different locales.

2. Screenshot Capture
Screenshots are taken directly from the UI during tests using Jetpack Compose’s testing utilities.

3. Automated Uploads
Screenshots are uploaded to a local server via HTTP, organized into directories by language and country.

4.2. Multi-Locale Screenshot Tests

Below is the main test class, which runs multiple tests and captures screenshots at different points:

class ScreenshotTakerTest : FunSpec({

    val locales = listOf(
        "de" to "DE",
        "en" to "US",
        "es" to "ES",
        "fr" to "FR",
        "it" to "IT",
        "pt" to "BR",
        "ru" to "RU",
        "tr" to "TR",
        "uk" to ""
    )

    test("Screenshot for Main Page") {
        runAndroidComposeUiTest {
            locales.forEach { (lang, country) ->
                activity?.setLocale(Locale(lang, country))
                waitForIdle()

                // Interact with UI
                onNodeWithTag("UsageMainColumn").performTouchInput { swipeUp() }
                waitForIdle()

                // Capture and upload screenshot
                takeScreenshot("main_page.png", lang, country)
            }
        }
    }
})

4.3. Helper Functions

The implementation relies on utility functions for common operations.

Setting the App Locale Updates the app’s locale dynamically during tests:

private fun MainActivity.setLocale(locale: Locale) {
    val resources = baseContext.resources
    Locale.setDefault(locale)
    val config = resources.configuration
    config.setLocale(locale)
    resources.updateConfiguration(config, resources.displayMetrics)
    runOnUiThread { recreate() }
}

Capturing a Screenshot Uses Jetpack Compose’s captureToImage() to capture the current UI state:

private fun AndroidComposeUiTest<*>.takeScreenshot(file: String, lang: String, country: String) {
    sleep(3000) // Wait for animations to settle
    val bitmap = onRoot().captureToImage().asAndroidBitmap()
    uploadScreenshot(bitmap, file, lang, country)
}

Uploading the Screenshot Sends the captured screenshot to the local server:

private fun uploadScreenshot(bitmap: Bitmap, fileName: String, lang: String, country: String) {
    val tempFile = File.createTempFile(fileName, null).apply {
        outputStream().use { bitmap.compress(Bitmap.CompressFormat.PNG, 100, it) }
    }
    Fuel.upload("http://10.0.2.2:8081/upload?lang=$lang&country=$country")
        .add(FileDataPart(tempFile, name = "file", filename = fileName))
        .response()
}

Note: 10.0.2.2 is the ip address of the computer running the emulator. It’s an special address

5. Conclusion

Automating screenshot testing in Android using Kotest and Ktor streamlines the UI validation process and ensures consistency across multiple locales. By combining Jetpack Compose testing utilities with an efficient local server, developers can easily capture, organize, and analyze screenshots during automated tests.

This approach offers several benefits:

• Improved Efficiency: Automates tedious manual testing tasks.
• Comprehensive Coverage: Validates UI behavior across different languages, countries, and configurations.
• Centralized Storage: Screenshots are uploaded to a server and organized systematically for future analysis.

By adopting this solution, teams can reduce testing overhead, improve collaboration, and ensure a polished, reliable user interface. This setup can further be extended with CI/CD pipelines, enabling seamless integration into modern development workflows.

Start implementing automated screenshot testing today to enhance your app’s quality and streamline your development process.

Automated Screenshot Taking in Android using Kotest and Ktor – Original at https://dev.to/leocolman/automated-screenshot-taking-in-android-using-kotest-and-ktor-o71 by Leonardo Colman Lopes

Learn to check if a Mono is empty in Kotlin and define static and dynamic fallback values to create robust reactive flows.

Check if Mono is Empty with Kotlin – Original at https://www.baeldung.com/kotlin/mono-empty-check by @baeldung

Learn how to exclude a library or a transitive dependency using the Kotlin DSL syntax in a Gradle.

Excluding a Library from All Dependencies in Kotlin DSL in Gradle – Original at https://www.baeldung.com/kotlin/gradle-exclude-library-all-dependencies by @baeldung

A quick tutorial on building a library in Kotlin with Gradle.

Building a Kotlin Library Using Gradle – Original at https://www.baeldung.com/kotlin/gradle-library by @baeldung

A quick tutorial on using named injection with Dagger 2 in Kotlin.

Dagger 2 Constructor Injection with Named Arguments in Kotlin – Original at https://www.baeldung.com/kotlin/dagger-named-constructor-injection by @baeldung

A quick tutorial on migrating a Kotlin application from Dagger to Koin for dependency injection.

Migration from Dagger to Koin – Original at https://www.baeldung.com/kotlin/dagger-to-koin-migrate by @baeldung

A quick tutorial on creating timers and schedulers with Kotlin coroutines.

Implement Scheduler/Timer with Kotlin Coroutine – Original at https://www.baeldung.com/kotlin/coroutine-timer-scheduler by @baeldung