DEV Community: Rhony

Android NDK: Native Bitmap Compression

Rhony — Thu, 20 Mar 2025 08:34:10 +0000

Introduction

Previously we are working on implementing native android logging. In this series we will play with native bitmap compression. We already know that by using native code it will reduce the CPU overhead and make the performance faster.

If you are a skipper person 🤣 that just want to jumping into the code you can find the source code at the bottom.

Continue...

Continuing from our previous article, we now create:

bitmap folder inside our nativelib library.
create a new C++ file bitmap.cpp and check the header option to automatically create our bitmap.h file

Open the bitmap.h file then we need to add our new function:
jbyteArray compressBitmap(JNIEnv *env, jobject bitmap, jint format, jint quality);

Which remains our header file become like this:

#ifndef HI_NDK_BITMAP_H
#define HI_NDK_BITMAP_H

#include <jni.h>

jbyteArray compressBitmap(JNIEnv *env, jobject bitmap, jint format, jint quality);

#endif //HI_NDK_BITMAP_H

Now switching the into our bitmap.cpp file, we will do our actual implementation here. Looking at the official documentation there is a AndroidBitmap_compress function which requires a few parameters:

int AndroidBitmap_compress(
  const AndroidBitmapInfo *info,
  int32_t dataspace,
  const void *pixels,
  int32_t format,
  int32_t quality,
  void *userContext,
  AndroidBitmap_CompressWriteFunc fn
)

So how do we use supply all of the required parameters ? It seems weird that the official documentation doesn't provide the sample, that would be different if we are reading another part of the android development for ex: jetpack compose, we will find bunch of implementation example there.

Here for simplicity, this is the compressBitmap function:

// Struct to store compression data
struct CompressionContext {
    JNIEnv *env;
    std::vector<uint8_t> buffer;
};

// Write callback function for compressed data
bool writeCompressedData(void *userContext, const void *data, size_t size) {
    if (userContext == nullptr || data == nullptr || size == 0) {
        LogPrint(ANDROID_LOG_ERROR, LOG_TAG, "Invalid write callback parameters");
        return false;
    }
    auto *ctx = static_cast<CompressionContext *>(userContext);
    ctx->buffer.insert(ctx->buffer.end(), (uint8_t *) data, (uint8_t *) data + size);

    LogPrint(ANDROID_LOG_DEBUG, LOG_TAG, "Compressed Data Written");
    return true;
}

jbyteArray compressBitmap(JNIEnv *env, jobject bitmap, jint format, jint quality) {
    ..

    if (format != ANDROID_BITMAP_COMPRESS_FORMAT_JPEG &&
        format != ANDROID_BITMAP_COMPRESS_FORMAT_WEBP_LOSSY) {
        LogPrint(ANDROID_LOG_ERROR, LOG_TAG,
                 "Invalid format, use JPEG or WebP LOSSY for compression");
        return nullptr;
    }

    ...

    // Compress the Bitmap
    int result = AndroidBitmap_compress(&info, dataspace, pixels, format, quality, &ctx,
                                        writeCompressedData);

    ...

    return compressedData;
}

If we take a look on the format, the image compression should done only on jpeg and webp lossy, for the PNG version it wouldn't be supported. You can refer here for more details about the format.

Head to our CMakeList.txt file, we need to register our bitmap class and folder so our nativelib.cpp will be able to call the compressBitmap function similiarly like we are doing before on native android logging.

target_link_libraries(${CMAKE_PROJECT_NAME}
        # List libraries link to the target library
          android
        log
        jnigraphics
)

Set the target sources

target_sources(
        ${CMAKE_PROJECT_NAME}
        PRIVATE
        ${NATIVE_SRC_DIR}/nativelib.cpp
        ${NATIVE_SRC_DIR}/logging/logging.cpp
        ${NATIVE_SRC_DIR}/bitmap/bitmap.cpp
)

Then register the folder

target_include_directories(
        ${CMAKE_PROJECT_NAME}
        PRIVATE
        ${NATIVE_SRC_DIR}/logging
        ${NATIVE_SRC_DIR}/bitmap
)

Moving to our NativeLib class then we register the function:
external fun compressBitmap(bitmap: Bitmap, format: Int, quality: Int): ByteArray?

Here we can make some optimization by encapsulating the NativeLib this is to avoid that our single library exposing all of our native functions. In this case we can create a new interface BitmapUtils

interface BitmapUtils {
    fun compressBitmap(bitmap: Bitmap, format: Int, quality: Int): ByteArray?

    companion object {
        val instance: BitmapUtils by lazy { NativeLib }
    }
}

Then implement the interface into our NativeLib class:

internal object NativeLib : BitmapUtils {

    init {
        System.loadLibrary("nativelib")
    }

    ...

    external override fun compressBitmap(bitmap: Bitmap, format: Int, quality: Int): ByteArray?
}

See that we are now locking the access into internal scope then calling our bitmap function as simply just by calling BitmapUtils.instance. You can found the project repository below, the project is already migrated to using Dependency Injection and there is a new ImageProcessor class to separate the our kotlin image compression logic

For the quality parameter, the maximum value is 100 the highest value is set, the image compression will almost didn't do anything. Meaning, if we want to see a contrast effect between the original image and the compressed we can use lowest quality

On the video above, i already made a TextField so than we can set the quality as we want.

Let's play with the quality parameter.

Quality Comparison Table

Quality 0	Quality 40	Original Size

Looking at the `quality` 40 below

From the above screenshoot data, the image still in good condition altought we put the quality below < 50. So what is the quality here ? Does it represented as percent ?
The answer is NO

The quality parameter in AndroidBitmap_compress does not directly correspond to file size percentage reduction. Instead, it represents the compression level for lossy formats (such as JPEG and WebP Lossy)

What Does the quality Parameter Mean?

The value ranges from 0 to 100:
- 0 → Maximum compression (smallest file size, lowest quality)
- 100 → No compression (largest file size, highest quality)
It does NOT guarantee exact file size reduction.
- Example: If an image is 100KB, setting quality = 50 does not mean it will become 50KB.
- The actual file size depends on the image content, resolution, and format.

How Quality Affects Compression ?
We can say that using some of the number between the below range will produce certain compression.

Quality (%)	Effect on Image	Effect on File Size
`100`	No compression, max quality	Largest file size (almost original)
`90`	High quality, minor loss	Slightly reduced file size
`75`	Medium compression, minor artifacts	Noticeable reduction (~30-50%)
`50`	High compression, visible quality loss	Strong reduction (~50-70%)
`25`	Very compressed, blocky artifacts	Significant size reduction (~70-90%)
`0`	Maximum compression, poor quality	Smallest file size, heavy artifacts

Final Thoughts

For most cases, a quality setting of 70-80% offers a great balance between file size and image clarity, but the optimal value will always depend on your specific use case. If performance is critical, leveraging NDK-based compression can provide significant speed and memory advantages.

If you’re working with large images or performance-intensive applications, it’s always a good idea to experiment with different quality values and measure their impact on file size and visual fidelity.

Optimize wisely, and happy coding!

Source code: ndk-playground

Android NDK: Implementing Logging with JNI & C++

Rhony — Sat, 15 Mar 2025 06:20:44 +0000

Introduction

As android app developers, we know that Android NDK has been around for a long time, with its first release, NDK r1 in June 2009. The Android Native Development Kit (NDK) allows developers to write native code using C and C++, improving performance in critical areas like multimedia processing and computational tasks. One essential feature when working with the NDK is logging, which helps in debugging and monitoring native code execution.

In this article, we’ll explore how to integrate and use the NDK logging library (android/log.h) to log messages from native code into Logcat, the standard Android logging system. And we will be calling the function from our kotlin code.

Prerequisites

Before we dive in, ensure you have the following set up:

Android Studio installed
NDK and CMake installed
Basic knowledge of JNI (Java Native Interface). Don't worry we didn't need that much knowledge for now.

Setting Up Your Project for NDK

To enable NDK support in your Android project:

Open your Android Studio project.
Create a new project, in this case we will be using a default jetpack compose project
Now, add a new Native module, simply right click to open the menu
Select Android Native Library then finish

Project Structure

Inspect the project, now we are having a CMakeLists.txt file inside our nativelib library. There is a log library declared on the target_link_libraries block which is the NDK android log.

Notice that we also has NativeLib class which will bridge between our kotlin code with the JNI. And the JNI will directly call our native C++ function.

Implementing Native Logging Function

We already finish with native library setup. As we know on Android there is common logging function Log.v for Verbose logging, Log.d for Debug and etc. Complete Android Log. In NDK there is also similar logging name but this time it is defined with enum instead of functions:

ANDROID_LOG_VERBOSE
ANDROID_LOG_DEBUG
ANDROID_LOG_INFO
ANDROID_LOG_WARN
ANDROID_LOG_ERROR

This enum will supplied into a single function __android_log_print from the NDK. So how do we make it ?

The C++ Class

Move to our nativelib library folder then:

Create a new folder: logging
Select C/C++ Source File
Name the file as logging and check the Create an associated header option
Open the logging header file logging.h then we need to register our c++ function, which will be shown like this:

// logging.h 
#ifndef NDK_PLAYGROUND_LOGGING_H
#define NDK_PLAYGROUND_LOGGING_H

#include <jni.h>

void log_print(JNIEnv* env, jint priority, jstring tag, jstring message);

#endif //NDK_PLAYGROUND_LOGGING_H

We can threat this class similarly like interface on highlevel programming language

Open the logging.cpp class then we declare our real function implementation, since the difference of the log is only the enum value (aka: priority) it is enough to just declare a single function.

#include "logging.h"
#include <android/log.h>
#include <jni.h>

void log_print(JNIEnv* env, jint priority, jstring tag, jstring message) {
    const char* tagStr = env->GetStringUTFChars(tag, nullptr);
    const char* msgStr = env->GetStringUTFChars(message, nullptr);

    if (tagStr && msgStr) {
        __android_log_print(priority, tagStr, "%s", msgStr);
    }

    env->ReleaseStringUTFChars(tag, tagStr);
    env->ReleaseStringUTFChars(message, msgStr);
}

Great! Until this steps you see a warning logging.cpp and logging.h file which tells that this file is not part of the project bla bla bla

Moving back to our CMakeList.txt file we should register both of the classes so later on our nativelib.cpp classs will be able to import our logging classes.

First, we need to set our source dir set(NATIVE_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR})
Set the target_sources
Then target_include_directories

Put those below our target_link_libraries block which remains like this:

add_library(${CMAKE_PROJECT_NAME} SHARED
        # List C/C++ source files with relative paths to this CMakeLists.txt.
        nativelib.cpp
)

# Specifies libraries CMake should link to your target library. You
# can link libraries from various origins, such as libraries defined in this
# build script, prebuilt third-party libraries, or Android system libraries.
target_link_libraries(${CMAKE_PROJECT_NAME}
        # List libraries link to the target library
        android
        log)

set(NATIVE_SRC_DIR ${CMAKE_CURRENT_SOURCE_DIR})

target_sources(
        ${CMAKE_PROJECT_NAME}
        PRIVATE
        ${NATIVE_SRC_DIR}/nativelib.cpp
        ${NATIVE_SRC_DIR}/logging/logging.cpp
)

target_include_directories(
        ${CMAKE_PROJECT_NAME}
        PRIVATE
        ${NATIVE_SRC_DIR}/logging
)

Then sync the project

The JNI, `nativelib.cpp` class

We are done with writing our logging c++ class, now it's time to work on JNI part. The class extension remains the same .cpp but this class we use it to register our native cpp function to JNI so then we can expose it to our kotlin code. Don't worry, let's code !

Since we want to log in verbose, debug, info, warn and error we can declare it to each functions

#include <jni.h>
#include <string>
#include <logging.h>
#include <android/log.h>

extern "C" JNIEXPORT void JNICALL
Java_com_ndk_nativelib_NativeLib_logV(
        JNIEnv *env,
        jobject /* this */,
        jstring tag,
        jstring message) {
    log_print(env, ANDROID_LOG_VERBOSE, tag, message);
}

extern "C" JNIEXPORT void JNICALL
Java_com_ndk_nativelib_NativeLib_logD(
        JNIEnv *env,
        jobject /* this */,
        jstring tag,
        jstring message) {
    log_print(env, ANDROID_LOG_DEBUG, tag, message);
}

extern "C" JNIEXPORT void JNICALL
Java_com_ndk_nativelib_NativeLib_logI(
        JNIEnv *env,
        jobject /* this */,
        jstring tag,
        jstring message) {
    log_print(env, ANDROID_LOG_INFO, tag, message);
}

extern "C" JNIEXPORT void JNICALL
Java_com_ndk_nativelib_NativeLib_logW(
        JNIEnv *env,
        jobject /* this */,
        jstring tag,
        jstring message) {
    log_print(env, ANDROID_LOG_WARN, tag, message);
}

extern "C" JNIEXPORT void JNICALL
Java_com_ndk_nativelib_NativeLib_logE(
        JNIEnv *env,
        jobject /* this */,
        jstring tag,
        jstring message) {
    log_print(env, ANDROID_LOG_ERROR, tag, message);
}

Awesome! But we still not finished yet, let's open up NativeLib we have to bind the nativelib into our kotlin code which is our upper layer:

internal object NativeLib {

    init {
        System.loadLibrary("nativelib")
    }

    external fun logV(tag: String, message: String)
    external fun logD(tag: String, message: String)
    external fun logI(tag: String, message: String)
    external fun logW(tag: String, message: String)
    external fun logE(tag: String, message: String)
}

Notice that we load the library on the init block System.loadLibrary("nativelib")

Implementation

Open up our MainAcvitiy class then we can directly call the native function anywhere. For example:

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        //some initialization
        NativeLib.logV("MainActivity", "Hello from MainActivity")
    }
 }

If we run the project we will see that the log is printed:

Bonus 🎁

Event better, we can provide a public function so than we don't have to call the NativeLib class. Create a new file NativeLog.kt on the same folder inside our nativelib package

Then we declare our public function, we can provide a function with tag and also using the class name itself as the log tag:

package com.ndk.nativelib

@Suppress("FunctionName")
fun LOG_V(tag: String, message: String) = NativeLib.logV(tag, message)

@Suppress("FunctionName")
fun<T : Any> T.LOG_V(message: String) = NativeLib.logV(this::class.java.simpleName, message)

@Suppress("FunctionName")
fun<T : Any> T.LOG_D(message: String) = NativeLib.logD(this::class.java.simpleName, message)

@Suppress("FunctionName")
fun<T : Any> T.LOG_I(message: String) = NativeLib.logI(this::class.java.simpleName, message)

@Suppress("FunctionName")
fun<T : Any> T.LOG_W(message: String) = NativeLib.logW(this::class.java.simpleName, message)

@Suppress("FunctionName")
fun<T : Any> T.LOG_E(message: String) = NativeLib.logE(this::class.java.simpleName, message)

Trying to call those function will produce this colorfull log messages

Conclusion

I hope by integrating the NDK logging library this gives us (yeah, us since I'm always be a newbie 😀) clear understanding how we can use NDK. While NDK is the SDK for native development the JNI itself play a role as the bridge of our native cpp class. The Native API is available on the official android documentation.
Be Aware, that touching native codebases will require deep understanding on C++ language meanwhile we know that C++ is a complex language and isn't simple as high level language like java and kotlin.

Source code: ndk-playground

DEV Community: Rhony

Android NDK: Native Bitmap Compression

Introduction

Continue...

Quality Comparison Table

Looking at the quality 40 below

Final Thoughts

Android NDK: Implementing Logging with JNI & C++

Introduction

Prerequisites

Setting Up Your Project for NDK

Project Structure

Implementing Native Logging Function

The C++ Class

The JNI, nativelib.cpp class

Implementation

Bonus 🎁

Conclusion

Looking at the `quality` 40 below

The JNI, `nativelib.cpp` class