Forem: cat dog (running_in_the_storm)

Efficient Android Screen Recording Using MediaRecorder + MediaProjection

cat dog (running_in_the_storm) — Wed, 12 Nov 2025 14:56:24 +0000

Efficient Android Screen Recording Using MediaRecorder + MediaProjection

Preface

On the Android platform, there are two primary approaches to implement screen recording: the MediaCodec + MediaMuxer combination and MediaRecorder. The former offers high flexibility and customization but is relatively complex, requiring manual handling of video/audio encoding and muxing processes.

In contrast, MediaRecorder is a high-level API that encapsulates the underlying audio/video recording and encoding workflows, significantly reducing development effort while maintaining excellent performance and compatibility.

MediaProjection, introduced in Android 5.0 (API 21), is a system-level service that resolves the core challenge of screen recording—how to securely and efficiently capture screen content. It provides a standardized, app-oriented interface for screen capture.

This article explains how to efficiently implement Android screen recording using MediaRecorder + MediaProjection.

Core of MediaRecorder: Lifecycle State Machine

To use MediaRecorder effectively, you must understand its working principles and master its lifecycle states. The state transitions are strict—any incorrect operation may cause exceptions.

Initial State: The default state when MediaRecorder is first created. You can return to this state via new MediaRecorder() or reset().
Configuring State: In this state, you configure recording parameters using various set... methods, such as:
- setAudioSource(MediaRecorder.AudioSource.MIC): Set audio source.
- setVideoSource(MediaRecorder.VideoSource.SURFACE): Set video source to a Surface.
- setOutputFormat(MediaRecorder.OutputFormat.MPEG_4): Set output container format.
- setVideoEncoder(MediaRecorder.VideoEncoder.H264): Set video encoder.
- setOutputFile(filePath): Specify the output file path. After configuration, call prepare().
Prepared State: Entered after calling prepare(). MediaRecorder performs internal checks and resource allocation to ensure readiness for recording.
Recording State: Entered after calling start(). MediaRecorder begins capturing, encoding, and writing audio/video data to the file. This is the core phase of recording.
Stopped State: Entered after calling stop(). Recording halts, file finalization completes, and some resources are released. Note: You cannot resume recording into the same file once stopped.
Error State: Entered if an error occurs at any stage, triggering a RuntimeException.

reset(): Returns MediaRecorder to the Initial state for reconfiguration and new recording.
release(): Fully releases all resources held by MediaRecorder. The object becomes unusable afterward.

The design philosophy of MediaRecorder prioritizes ease of use, abstracting complex audio/video encoding and muxing behind a simple interface.

Core Features of MediaProjection

User Authorization Mechanism: Requires explicit user consent via a system dialog to ensure privacy.
Virtual Display Support: Creates a VirtualDisplay to redirect screen content to a Surface.
System-Level Integration: Interacts directly with the display system without requiring root access.

Compared to traditional root-based or ADB-based solutions, MediaProjection provides a legal, standardized, app-friendly interface, enabling screen recording apps to be published on official app stores.

Building Your Screen Recording App

Permission Requests and User Authorization

Screen recording is a long-running task. To prevent the app from being killed by the system, run the recording task in a foreground service and display recording status in the notification bar.

We create a foreground service RecordingService for screen recording. First, declare necessary permissions like RECORD_AUDIO and FOREGROUND_SERVICE in AndroidManifest.xml.

<manifest ...>

    <application
    ...
        <service
            android:name=".services.RecordingService"
            android:foregroundServiceType="mediaProjection"
            android:enabled="true"
            android:exported="false"></service>

    </application>
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PLAYBACK" />
    <uses-permission android:name="android.permission.FOREGROUND_SERVICE_MEDIA_PROJECTION" />
</manifest>

Then, in a Compose function, use MediaProjectionManager and rememberLauncherForActivityResult to request screen capture permission. This step triggers a system dialog asking for user authorization.

// 1. Define ActivityResultLauncher
//    It takes an Intent as input and returns an ActivityResult
val screenCaptureLauncher = rememberLauncherForActivityResult(
    contract = ActivityResultContracts.StartActivityForResult()
) { result ->
    val activity = context.findActivity()
    if (result.resultCode == Activity.RESULT_OK && result.data != null) {
        // User granted permission, start recording service
        viewModel.startRecordingService(activity, result.resultCode, result.data!!)
        Toast.makeText(activity, activity.getString(R.string.start), Toast.LENGTH_SHORT).show()
    } else {
        Toast.makeText(activity, activity.getString(R.string.rejected), Toast.LENGTH_SHORT).show()
    }
}

// 2. Function to launch screen capture request
val startScreenCaptureRequest = remember<(Context) -> Unit> {
    { ctx ->
        // Get MediaProjectionManager
        val projectionManager = ctx.getSystemService(Context.MEDIA_PROJECTION_SERVICE) as MediaProjectionManager

        // Create screen capture intent
        val intent = projectionManager.createScreenCaptureIntent()
        // Launch intent using Compose launcher
        screenCaptureLauncher.launch(intent)
    }
}

...
// Request screen recording
startScreenCaptureRequest(context)
...

The startRecordingService in the ViewModel starts a foreground recording service.

fun startRecordingService(context: Context, resultCode: Int, data: Intent) {
    val serviceIntent = Intent(context, RecordingService::class.java).apply {
        action = "ACTION_START"
        putExtra("resultCode", resultCode)
        putExtra("data", data)
    }
    ContextCompat.startForegroundService(context, serviceIntent)
    context.bindService(serviceIntent, connection, Context.BIND_AUTO_CREATE) // Bind to Service
    binder_flag = true
}

Core of Screen Recording: Foreground Service `RecordingService`

The core logic resides in RecordingService.

In onStartCommand, we handle the recording request, create a notification, register a callback for when recording ends, and finally start the recording task. This order is critical—otherwise, MediaProjection cannot properly capture screen data.

override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int {
    if (intent != null) {
        when (intent.action) {
            "ACTION_START" -> {
                if (isRecording) return START_NOT_STICKY
                val resultCode = intent.getIntExtra("resultCode", Activity.RESULT_CANCELED)
                // Use the new, type-safe getParcelableExtra method
                val data = if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
                    intent.getParcelableExtra("data", Intent::class.java)
                } else {
                    @Suppress("DEPRECATION")
                    intent.getParcelableExtra("data")
                }

                if (resultCode != Activity.RESULT_OK || data == null) {
                    Toast.makeText(this, "Screen recording permission denied, cannot start service", Toast.LENGTH_SHORT).show()
                    stopSelf()
                    return START_NOT_STICKY
                }
                // Ensure notification channel exists before creating notification
                createNotificationChannel()
                val notification = createRecordingNotification(this)
                startForeground(notificationId, notification)
                // 2. Register anonymous callback object (more concise!)
                val recordingCallback = object : MediaProjection.Callback() {
                    override fun onStop() {
                        super.onStop()
                        // Perform cleanup when user/system revokes permission
                        // Note: We must manually unregister it. Although stop() releases resources,
                        // it's best to clean up immediately after onStop() is called.
                        mediaProjection?.unregisterCallback(this)
                    }
                }
                mediaProjection = mediaProjectionManager.getMediaProjection(resultCode, data)
                // Register callback using current thread's Handler (null)
                mediaProjection?.registerCallback(recordingCallback, null)
                startRecording()
            }
            "ACTION_STOP" -> {
                stopRecording()
            }
        }
    }
    return START_NOT_STICKY
}

In startRecording(), we configure MediaRecorder, set video/audio sources, output format, encoder, resolution, etc., and pass the screen data captured by MediaProjection to MediaRecorder via a Surface.

fun startRecording() {
    try {
        // Configure MediaRecorder
        mediaRecorder =
            if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
                MediaRecorder(this)
            } else {
                MediaRecorder()
            }
            .apply {
                if (recordAudioType == 1) {
                    setAudioSource(MediaRecorder.AudioSource.MIC)
                    setAudioEncoder(MediaRecorder.AudioEncoder.AAC)
                }

                setVideoSource(MediaRecorder.VideoSource.SURFACE)
                setOutputFormat(MediaRecorder.OutputFormat.MPEG_4)

                if (mediaUri != null) {
                    pfd = contentResolver.openFileDescriptor(mediaUri!!, "w")
                    if (pfd != null) {
                        setOutputFile(pfd!!.fileDescriptor)
                    }
                } else {
                    setOutputFile(filePath)
                }

                // Video configuration
                setVideoSize(VIDEO_WIDTH, VIDEO_HEIGHT) // Example resolution
                setVideoEncoder(MediaRecorder.VideoEncoder.H264)
                setVideoEncodingBitRate(VIDEO_BIT_RATE) // 5 Mbps
                setVideoFrameRate(VIDEO_FRAME_RATE)
                prepare()
            }

        // Create virtual display
        val displayMetrics = resources.displayMetrics
        val densityDpi = displayMetrics.densityDpi
        virtualDisplay = mediaProjection?.createVirtualDisplay(
            "RecordingDisplay",
            VIDEO_WIDTH, VIDEO_HEIGHT, // Must match MediaRecorder video size
            densityDpi,
            DisplayManager.VIRTUAL_DISPLAY_FLAG_AUTO_MIRROR,
            mediaRecorder?.surface,
            null,
            null
        )

        mediaRecorder?.start()
        Log.d("RecordingService", "Recording started!")
        isRecording = true
    } catch (e: IOException) {
        Log.e("RecordingService", "startRecording failed", e)
        stopRecording()
    }
}

Finally, do not forget to release resources properly.

private fun stopRecording() {
    isRecording = false
    mediaRecorder?.apply {
        stop()
        reset()
        release()
    }
    pfd?.close()
    pfd = null
    mediaRecorder = null

    virtualDisplay?.release()
    virtualDisplay = null

    mediaProjection?.stop()
    mediaProjection = null

    // 1. Remove foreground state
    // Use STOP_FOREGROUND_REMOVE flag to remove both foreground state and notification.
    // This is the most common and complete way to stop foreground service.
    ServiceCompat.stopForeground(
        /* service = */ this,
        /* flags = */ ServiceCompat.STOP_FOREGROUND_REMOVE
    )
    stopSelf()
    Log.d("RecordingService", "Recording stopped.")
}

override fun onDestroy() {
    super.onDestroy()
    stopRecording()
}

With the above steps, we have completed a fully functional screen recording feature.

Summary

The combination of MediaRecorder + MediaProjection is a powerful tool for implementing screen recording on Android. By encapsulating complex underlying implementations, it allows developers to achieve high-quality recording with minimal code.

The complete sample code can be found in the screen recording section of the Audio and Video Editor project (note: the code is somewhat rough).

References

Efficiently Building App Permission Flows with the Compose Permission Request Template

cat dog (running_in_the_storm) — Sun, 26 Oct 2025 07:29:39 +0000

Efficiently Building App Permission Flows with the Compose Permission Request Template

Foreword

In traditional Android development, permission requests rely on requestPermissions() and onRequestPermissionsResult() methods within the Activity. Permission request logic is often concentrated in the Activity, and the callback-based pattern results in fragmented code structures.

With the rise of Jetpack Compose, we need a permission handling method that is more aligned with the declarative UI paradigm. The officially recommended Activity Result API (via rememberLauncherForActivityResult) decouples the request from the result, allowing our Compose functions to handle permissions in a state-driven manner.

While permission handling in Jetpack Compose follows declarative principles, writing the full sequence of Permission Check → Launcher Registration → Rationale Determination → Permanent Denial Handling for every new permission remains time-consuming and repetitive.

For efficient development, the goal of this article is to templatize and encapsulate this flow. This article will provide a highly reusable, officially recommended Compose permission request general template, helping developers quickly and elegantly set up permission request flows in any application.

Article Objectives

Objective	Key Content	Problem Solved
General Templatization	Encapsulate permission request, state, rationale display, and permanent denial handling into one reusable Composable.	Avoid repetitive writing of large amounts of permission check and callback logic.
High Reusability	Design functions with flexible parameters, requiring only the permission name and the granted callback to be used.	Applicable to all dangerous permission request scenarios in the app.
State-Driven Design	The internal implementation follows Compose `State` principles, ensuring responsive UI and accurate state.	Guarantees that the permission UI and app state are always synchronized, preventing bugs.
Official Recommended Core	The template is based on `Activity Result API` and `shouldShowRationale` best practices.	Ensures code robustness and future-proofing.

Basic Setup: Manifest Declaration and Dependency Inclusion

Regardless of the approach, all required permissions (Dangerous Permissions) must first be declared in the AndroidManifest.xml file.

<manifest ...>
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission
        android:name="android.permission.MANAGE_EXTERNAL_STORAGE"
        tools:ignore="ScopedStorage" />
    <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
</manifest>

Introduce Compose Activity Dependency

Ensure your project includes the Activity Result API dependency for Compose:

// build.gradle (app level)
dependencies {
    // Must include; provides core APIs like rememberLauncherForActivityResult
    implementation("androidx.activity:activity-compose:1.9.0") // Please use the latest version

    // If you need to handle multiple permissions, you can use this Contract
    // implementation("androidx.activity:activity-ktx:1.9.0")
}

Core Practice: Building the Permission Request Template with `rememberLauncherForActivityResult`

The core of requesting permissions in Compose is using rememberLauncherForActivityResult. This is a Composable function responsible for registering an ActivityResultLauncher and automatically unregistering it when the component is removed. We build our permission request template based on this API.

Activity Context Retrieval Utility

Since the critical shouldShowRationale API in permission requests relies on an Activity, we first define a useful Context extension function to retrieve it.

// Place this in your utility class for global access
fun Context.findActivity(): Activity {
    var context = this
    while (context is ContextWrapper) {
        if (context is Activity) return context
        context = context.baseContext
    }
    // Permission requests must be made within an Activity Context
    throw IllegalStateException("Permissions must be requested within an Activity Context.")
}

Template Code Implementation

We encapsulate all permission handling logic into a Composable function named PermissionRequestTemplate. It requires three core parameters:

permission: The string name of the permission to request.
content: The core feature UI to display after the permission is granted.
rationaleContent: The UI to display when explaining the permission rationale.

@Composable
fun PermissionRequestTemplate(
    permission: String,
    text:String= stringResource(id = R.string.request_permission),
   // content: @Composable () -> Unit, // Content to show after permission is granted
    rationaleContent: @Composable (
        // Action to re-request after rationale explanation
        onRequestPermission: () -> Unit,
        // Action to navigate to settings after permanent denial
        onOpenSettings: () -> Unit
    ) -> Unit,
   // Action to navigate to settings after permanent denial
    onOpenSettings: () -> Unit
) {
    val context = LocalContext.current
    val lifecycleOwner = LocalLifecycleOwner.current

    // ① Core State: Tracks whether the permission has been granted
    var isPermissionGranted by remember {
        mutableStateOf(ContextCompat.checkSelfPermission(context, permission) == PackageManager.PERMISSION_GRANTED)
    }
    // Core State: Tracks whether the "Rationale Explanation" UI needs to be shown
    var showRationaleDialog by remember { mutableStateOf(false) }
    var showPermissionPromptDialog by remember { mutableStateOf(true) }
    // ② Register the permission request launcher
    val permissionLauncher = rememberLauncherForActivityResult(
        contract = ActivityResultContracts.RequestPermission(),
        onResult = { isGranted ->
            isPermissionGranted = isGranted // Update state
            // If denied, check if Rationale should be shown (state needs update even if system dialog is closed)
            if (!isGranted) {
                val activity = context.findActivity()
                showRationaleDialog = ActivityCompat.shouldShowRequestPermissionRationale(activity, permission)
            }
        }
    )

    // ③ Permission Status Check and UI Rendering
    when {
        // Status 1: Permission is granted -> Show core feature
        isPermissionGranted -> {
            //content()
        }

        // Status 2: Rationale needs to be shown -> Display Rationale Explanation UI
        showRationaleDialog -> {
            RationaleDisplay(
                rationaleContent = rationaleContent,
                onDismiss = { showRationaleDialog = false },
                onRequest = {
                    // Re-launch the request
                    permissionLauncher.launch(permission)
                    showRationaleDialog = false // Hide dialog after request is launched
                },
                onOpenSettings=onOpenSettings
            )
        }

        // Status 3: Initial or Denied state -> Show request button/prompt
        else -> {
            // First request, or user has permanently denied (shouldShowRationale = false)
            if(showPermissionPromptDialog){
                AlertDialog(
                    onDismissRequest = {showPermissionPromptDialog=false},
                    title = {
                        Text(text)
                    },
                    text = {

                    },
                    confirmButton = {
                        TextButton(onClick = {
                            val activity = context.findActivity()
                            // Re-check if Rationale needs to be shown
                            if (ActivityCompat.shouldShowRequestPermissionRationale(
                                    activity,
                                    permission
                                )
                            ) {
                                showRationaleDialog = true
                            } else {
                                // First request, or user has permanently denied, launch request directly
                                permissionLauncher.launch(permission)
                            }
                        }) {
                            Text(stringResource(id = R.string.ok))
                        }
                    },
                    dismissButton = {
                        TextButton(onClick = {
                            showPermissionPromptDialog=false
                        }) {
                            Text(stringResource(id = R.string.cancel))
                        }
                    }
                )
            }
        }
    }
}

Auxiliary Composable Encapsulation (Button and Rationale)

To keep PermissionRequestTemplate concise, the request button and rationale display are encapsulated.


@Composable
fun RationaleDisplay(
    rationaleContent: @Composable (onRequestPermission: () -> Unit, onOpenSettings: () -> Unit) -> Unit,
    onDismiss: () -> Unit,
    onRequest: () -> Unit,
    onOpenSettings: () -> Unit
) {
    val context = LocalContext.current

    AlertDialog(
        onDismissRequest = onDismiss,
        title = {

        },
        text = {
            rationaleContent(
                onRequestPermission = onRequest, // Action to re-request
                onOpenSettings = onOpenSettings // Action to navigate to settings
            )
        },
        confirmButton = {
        },
        dismissButton = {
              TextButton(onClick = {onDismiss()}) {
                  Text(text = stringResource(id = R.string.cancel))
              }
        }
    )
}

Template Usage: Concise and Efficient Call Example

Using this template makes the business Composable simpler and more aligned with the declarative style.

        PermissionRequestTemplate(
            permission = Manifest.permission.WRITE_EXTERNAL_STORAGE,
            text= stringResource(id = R.string.request_write_permission),
            rationaleContent = { onRequest, onOpenSettings ->
                Column {
                    Text(text = stringResource(id = R.string.read_and_write_permissions), fontWeight = FontWeight.Bold)
                    Spacer(modifier = Modifier.height(8.dp))
                    Row {
                        // Guide user to request again
                        Button(onClick = onRequest) { Text(stringResource(id = R.string.reauthorization)) }
                        Spacer(modifier = Modifier.width(8.dp))
                        // Guide user to settings page (handles permanent denial scenario)
                        Button(onClick = onOpenSettings) { Text(stringResource(id = R.string.go_to_settings)) }
                    }
                }

            },
            onOpenSettings = {
                val packageName = context.packageName
                val intent = Intent()
                intent.action = Settings.ACTION_APPLICATION_DETAILS_SETTINGS
                intent.data = Uri.fromParts("package", packageName, null)
                startActivity(context, intent, null)
            }
        )

Through PermissionRequestTemplate and its auxiliary Composable, we achieve the goals for Compose permission requests: standardized flow, centralized logic, and minimized code.

Differences in Different Versions

Unfortunately, permission checking and requesting methods in Android vary across different system versions. This means developers cannot exclusively rely on the rememberLauncherForActivityResult code for all permission request logic; code implementation differs between versions.

Taking storage permission as an example (Google officially discourages apps from obtaining full storage access, recommending their file picker instead): Before Android 11, storage permission was divided into Manifest.permission.WRITE_EXTERNAL_STORAGE (write) and Manifest.permission.READ_EXTERNAL_STORAGE (read), and could be checked directly using checkSelfPermission and rememberLauncherForActivityResult.

// Check permission
if((ContextCompat.checkSelfPermission(context, permission) == PackageManager.PERMISSION_GRANTED)){
    //...
}

// Register permission request launcher
val permissionLauncher = rememberLauncherForActivityResult(
    contract = ActivityResultContracts.RequestPermission(),
    onResult = { isGranted ->
        isPermissionGranted = isGranted // Update state
        // If denied, check if Rationale should be shown (state needs update even if system dialog is closed)
        if (!isGranted) {
            val activity = context.findActivity()
            showRationaleDialog = ActivityCompat.shouldShowRequestPermissionRationale(activity, permission)
        }
    }
)

// Request
permissionLauncher.launch(permission)

Starting with Android 11, the applicable method for checking and requesting changes, requiring navigation to the settings screen for authorization instead of using the launcher.

// Check storage permission
if(Environment.isExternalStorageManager()){
    //...
}

// Navigate to settings screen for authorization
val packageName = activity.packageName
val intent = Intent()
intent.action = Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION
intent.data = Uri.fromParts("package", packageName, null)
startActivity(activity, intent, null)

Summary

The details of permission management on Android can be quite complex. We hope the template provided in this article is helpful to everyone.

References

Tired of complicated compilation?Integrate AeroFFmpeg with one click to make Android audio and video development easier!

cat dog (running_in_the_storm) — Sat, 20 Sep 2025 06:27:17 +0000

Tired of complicated compilation？Integrate AeroFFmpeg with one click to make Android audio and video development easier!

Preface

As an Android developer, have you ever needed to implement audio and video features in your project, but been put off by FFmpeg's complex compilation process? To use FFmpeg on Android, you need to:

Download the FFmpeg source code, possibly including various dependent libraries.
Configure a complex cross-compilation environment, such as the NDK and compiler.
Write lengthy compilation scripts to handle compatibility issues with different CPU architectures and operating systems.
Have to start all over again with every FFmpeg version update.
This process can be a nightmare, time-consuming and labor-intensive, and prone to errors if you're not careful!

This article introduces AeroFFmpeg, the open-source FFmpeg Android SDK project. It compiles FFmpeg into a simple, easy-to-use AAR (Android Archive) file, providing an out-of-the-box solution for Android developers. With just a few lines of code, Android developers can integrate powerful FFmpeg features into their Android projects.

Minimalistic AeroFFmpeg Integration

Currently, AeroFFmpeg has a minSdk of 24 and a targetSdk of 34. It is compiled based on FFmpeg 4.2.9 and supports MP3, H.264, and H.265. Currently, AeroFFmpeg only supports the arm64-v8a and x86 architectures and does not yet support 16KB page sizes. Once AeroFFmpeg is integrated into your project, you can immediately use the FFmpeg command line. The following describes how to integrate and use AeroFFmpeg.

Importing the AeroFFmpeg AAR File

Since AeroFFmpeg has not yet been released to the Maven repository, you will need to integrate the AAR file directly by importing it. The AAR file address is as follows:

https://github.com/Ilovecat1949/AeroFFmpeg/releases/tag/v1.0.0

Copy the AAR file to the libs folder under the app module in your Android project. If the libs folder does not exist, create one manually.

Configure the build.gradle file Open the app module's build.gradle file. You need to configure two sections: repositories and dependencies.

repositories {
    flatDir {
        dirs("libs")
    }
}

implementation(files("libs/AeroFFmpeglib-release.aar"))

The declaration repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) in the settings.gradle.kts file will prevent the module from being added locally. If present, replace this declaration with repositoriesMode.set(RepositoriesMode.PREFER_SETTINGS).

Sync the Project Click Sync Now. Gradle will automatically download the .aar file and all its dependencies from the specified Maven repository and add it to your project.

With these steps, you've integrated AeroFFmpeg into your project.

AeroFFmpeg Usage and Scenarios

AeroFFmpeg uses a singleton model and supports the FFmpeg command line, which executes asynchronously in a child thread. Note that AeroFFmpeg does not support multi-threaded concurrent execution of the FFmpeg command line; a new command line task cannot be started before the previous one has completed. If you need to support concurrent audio and video tasks, consider using Android multi-process programming to call different AeroFFmpeg instances.

//Start an FFmpeg command line task
//Returns a result: 0 for success, -1 for failure
val result = AeroFFmpeg.start("ffmpeg -i input.mp4 output.mp4")

//Get the current task status: 0: Executing the task or not executing at all; 1: Task completed without error; -1: Task completed with error
AeroFFmpeg.getTaskState()

//Cancel the task
AeroFFmpeg.cancelTask()

//Get the current task progress. Returns a Double value in milliseconds.
AeroFFmpeg.getProgressTime()

//Process log information through the log callback function
AeroFFmpeg.setLogListener (
object: OnLogListener {
override fun onLog(level: Int, message: String) {
Log.d("AeroFFmpeg.setLogListener","$level,$message")

}
}
)

Completing Background Audio and Video Tasks with AeroFFmpeg and WorkManager

Next, we'll develop an application that performs background audio and video tasks based on AeroFFmpeg and WorkManager. WorkManager, as the officially recommended background task API, offers advantages such as high reliability, persistent execution, and high energy efficiency. For detailed usage of WorkManager, please refer to my previous article.
First, define a Worker class that executes the FFmpeg command line.

class FFmpegTaskWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    // 重写 getForegroundInfo() 以提供前台服务通知信息
    override suspend fun getForegroundInfo(): ForegroundInfo {
        return ForegroundInfo(
            FFMPEG_CMD_ID,
            notificationBuilder.setContentText("开始执行任务...").build()
        )
    }

    override suspend fun doWork(): Result {
        setForeground(getForegroundInfo())
        val cmd = inputData.getString(FFMPEG_CMD)
        return withContext(Dispatchers.IO) {
            try {
            try {
                if(AeroFFmpeg.start(cmd!!)<0){
                    return@withContext Result.failure()
                }
                AeroFFmpeg.start(cmd)
                while(AeroFFmpeg.getTaskState()==0){
                    notificationBuilder.setContentText("任务进度：${formatTimeFromMillis(AeroFFmpeg.getProgressTime())}")
                    setProgress(AeroFFmpeg.getProgressTime())
                    if (ActivityCompat.checkSelfPermission(
                            applicationContext,
                            Manifest.permission.POST_NOTIFICATIONS
                        ) == PackageManager.PERMISSION_GRANTED
                    ) {
                        notificationManager.notify(FFMPEG_CMD_ID, notificationBuilder.build())
                    }
                    delay(100)
                }
                if(AeroFFmpeg.getTaskState()==1){
                    notificationBuilder.setContentText("执行成功")
                    if (ActivityCompat.checkSelfPermission(
                            applicationContext,
                            Manifest.permission.POST_NOTIFICATIONS
                        ) == PackageManager.PERMISSION_GRANTED
                    ) {
                        notificationManager.notify(FFMPEG_CMD_ID, notificationBuilder.build())
                    }
                    return@withContext Result.success()
                }
                else{
                    notificationBuilder.setContentText("执行失败")
                    if (ActivityCompat.checkSelfPermission(
                            applicationContext,
                            Manifest.permission.POST_NOTIFICATIONS
                        ) == PackageManager.PERMISSION_GRANTED
                    ) {
                        notificationManager.notify(FFMPEG_CMD_ID, notificationBuilder.build())
                    }
                    return@withContext Result.failure()
                }
            } catch (e: Exception) {
                e.printStackTrace()
                // Task failed, update notification
                notificationBuilder.setContentText("执行失败").setProgress(0, 0, false)
                return@withContext Result.failure()
            } finally {
                // Ensure notification is cancelled
                if (ActivityCompat.checkSelfPermission(
                        applicationContext,
                        Manifest.permission.POST_NOTIFICATIONS
                    ) == PackageManager.PERMISSION_GRANTED
                ) {
                    notificationManager.cancel(FFMPEG_CMD_ID)
                }
            }
        }
    }
}

Define a method to start the task and encapsulate the process of submitting the task to WorkManager.

fun startFFmpegTask(context: Context, cmd: String) {

    val data = workDataOf(FFMPEG_CMD to cmd)
    // Set constraints to only download when connected to a network
    val constraints = Constraints.Builder()
        //.setRequiredNetworkType(NetworkType.CONNECTED)
        .build()

    // Create a OneTimeWorkRequest for the download
    val ffmpegTaskRequest = OneTimeWorkRequestBuilder<FFmpegTaskWorker>()
        .setConstraints(constraints)
        .setInputData(data)
        .addTag(FFMPEG_TASK_TAG)
        .build()
    // Enqueue the work request
    WorkManager.getInstance(context).enqueue(ffmpegTaskRequest)
}

Through the LiveData class, the status and progress of tasks can be observed and displayed in real time, achieving synchronization between background task information and UI display information.

    val context = LocalContext.current
    val workManager = WorkManager.getInstance(context)
    var cmd by remember { mutableStateOf("") }
    val workInfos: LiveData<List<WorkInfo>> = remember {
        workManager.getWorkInfosByTagLiveData(FFMPEG_TASK_TAG)
    }
    val ffmpegTasks by workInfos.observeAsState(initial = emptyList())
    ...

        LazyColumn(
            modifier = Modifier.fillMaxSize()
        ) {
            items(ffmpegTasks) { workInfo ->
                FFmpegTaskItem(workInfo)
            }
        }

The resulting application is shown below.

Thus, using AeroFFmpeg, we can easily implement audio and video features in Android apps.

Summary

FFmpeg is a powerful open-source audio and video processing tool that supports transcoding, editing, recording, streaming, filtering, and more. With AeroFFmpeg, you can bring FFmpeg's audio and video capabilities to your Android app without complex NDK configuration or lengthy compilation scripts. I will continue to update and improve AeroFFmpeg.
The AeroFFmpeg repository is as follows:

https://github.com/Ilovecat1949/AeroFFmpeg

The AeroFFmpeg+WorkManager sample code is in the WorkDownloader project in the following repository:

https://github.com/Ilovecat1949/AndroidApps

References

Say goodbye to tedious work and use WorkManager to solve the problem of background work

cat dog (running_in_the_storm) — Sat, 13 Sep 2025 05:40:26 +0000

Say goodbye to tedious work and use WorkManager to solve the problem of background work

Preface

Executing background tasks is a complex part of Android development, requiring numerous considerations. First and foremost is battery life. Frequent background tasks consume a significant amount of battery life, a problem unbearable for both users and the system. To combat the rampant and surreptitious background work of Android apps, Google has introduced various background restriction mechanisms (Doze Mode, App Standby, and Background Execution Limits). Newer versions of Android have tightened background management, creating compatibility challenges for developers. Most importantly, developers struggle to ensure the reliability of their apps' background tasks, as the system often pauses or kills them for various reasons.

WorkManager, a background task manager within the Android Jetpack family, is the officially recommended API for persistent work and general background processing. This article will demonstrate the use of WorkManager using the example of developing a downloader. The downloader code can be found in the following repository: https://github.com/Ilovecat1949/AndroidApps.

You are also welcome to check out my audio and video development project: https://github.com/Ilovecat1949/AudioAndVideoEditor. This is an open source Android audio and video editor that supports ffmpeg command line, video encoding compression and format conversion, video cropping and speed change, and other audio and video functions.

Why WorkManager is the best choice

Officially Endorsed and Reliable: As Google's officially recommended background task solution, WorkManager continues to receive support and optimization, with a simple and consistent API.
Persistent and Reliable Execution: This is WorkManager's greatest strength. Work execution is maintained even if the user navigates away from the screen, exits the app, or reboots the device. For failed tasks, WorkManager provides flexible retry policies, including a configurable exponential backoff policy.
Energy Efficiency: WorkManager adheres to power-saving features and best practices like Doze and offers powerful scheduling capabilities.
Flexible Constraints: Developers can set various constraints for tasks, allowing them to execute at the most appropriate time, saving battery and data usage.

For example:

Network Status: Execute only when connected to Wi-Fi.

Charging Status: Execute only when the device is charging.

Storage Space: Execute only when sufficient storage space is available.

Diverse Task Types: Supports one-time, periodic, and chained tasks to meet the diverse needs of developers.

Core Concepts and Practices: How does WorkManager work?

WorkManager's design philosophy is very clear, breaking down background tasks into three core components:
Worker: Unit of Work

Concept: WorkManager abstracts background tasks into independent Workers. Each Worker is responsible for performing a specific task, such as uploading logs, synchronizing data, or downloading files.

Implementation: Inherit the Worker class and override the doWork() method. Implement your background task logic in this method.

Task Request: WorkRequest

Concept: A WorkRequest describes how a task should be executed, including constraints, execution delay, and other information.

Practice: Create a task request using OneTimeWorkRequest (for one-time tasks) or PeriodicWorkRequest (for periodic tasks) and set constraints using the Constraints builder.

Task Scheduling: WorkManager

Concept: WorkManager is the scheduling center for background tasks. It receives WorkRequests and decides when to execute a Worker based on constraints and system status.

Practice: Submit tasks to the WorkManager using WorkManager.getInstance(context).enqueue(workRequest) .

Talking with code: Developing a downloader using WorkManager

design

Before developing, we need to first consider the nature of our application.

Develop it in Kotlin and develop the UI using Jetpack Compose.
Be able to request the necessary permissions for downloads, such as network permissions and file read/write permissions.
The interface should allow users to enter a download link and initiate the download.
Provide a download task list to display download progress and status.
Support download progress notifications. The importance of notifications is crucial. Long-running tasks that require continuous network or CPU access require a "pass" to inform the system of their importance. To address this, we need to upgrade the download task to a "foreground service." A foreground service notifies the system that the task is in progress and is visible to the user (via notifications), preventing the system from easily terminating it. ### Code Implementation We first need to declare the required permissions in AndroidManifest.xml. For Android 13 and later Android versions, we need to explicitly declare the notification permission.

    <uses-permission android:name="android.permission.POST_NOTIFICATIONS" />
    <!-- 声明网络权限，这是下载功能所必需的 -->
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />

We also need to check and request permissions at runtime, and create a notification channel.

    private val requestPermissionLauncher =
        registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted: Boolean ->
            if (isGranted) {
                // Permission granted. Continue with the app flow.
            } else {
                Toast.makeText(this, "需要通知权限才能显示下载进度", Toast.LENGTH_LONG).show()
            }
        }
    private fun createNotificationChannel() {
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) {
            val name = "下载通知"
            val descriptionText = "显示下载文件的进度和状态"
            val importance = NotificationManagerCompat.IMPORTANCE_LOW
            val channel = android.app.NotificationChannel(DOWNLOAD_NOTIFICATION_CHANNEL_ID, name, importance).apply {
                description = descriptionText
            }
            val notificationManager: android.app.NotificationManager =
                getSystemService(Context.NOTIFICATION_SERVICE) as android.app.NotificationManager
            notificationManager.createNotificationChannel(channel)
        }
    }
    override fun onCreate(savedInstanceState: Bundle?) {
    ...
        if (Build.VERSION.SDK_INT < Build.VERSION_CODES.R){
            val permission = arrayOf(
                Manifest.permission.WRITE_EXTERNAL_STORAGE,
                Manifest.permission.READ_EXTERNAL_STORAGE
            )
            val requestPermissionLauncher =
                this.registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted: Boolean ->

                }
            permission.forEach {
                if(! (this.checkSelfPermission(it) == PackageManager.PERMISSION_GRANTED)){
                    requestPermissionLauncher.launch(it)
                }
            }
        }
        else{
            if(!Environment.isExternalStorageManager()){
                val builder = android.app.AlertDialog.Builder(this)
                    .setMessage("需要获取文件读写权限")
                    .setPositiveButton("ok") { _, _ ->
                        val packageName = this.packageName
                        val intent = Intent()
                        intent.action = Settings.ACTION_MANAGE_APP_ALL_FILES_ACCESS_PERMISSION
                        intent.data = Uri.fromParts("package", packageName, null)
                        ContextCompat.startActivity( this, intent, null)
                    }
                    .setNeutralButton("稍后再问"){ _, _ ->

                    }
                builder.show()
            }
        }


        // 请求通知权限 (适用于 Android 13 及以上版本)
        if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.TIRAMISU) {
            if (ActivityCompat.checkSelfPermission(
                    this,
                    Manifest.permission.POST_NOTIFICATIONS
                ) != PackageManager.PERMISSION_GRANTED
            ) {
                requestPermissionLauncher.launch(Manifest.permission.POST_NOTIFICATIONS)
            }
        }

        // 创建通知渠道
        createNotificationChannel()    
    ...    
    }

Define a work class based on your own needs, and write the specific logic of executing the task in this work class.

class DownloadWorker(
    appContext: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(appContext, workerParams) {

    private val notificationManager = NotificationManagerCompat.from(appContext)
    private val notificationBuilder = NotificationCompat.Builder(applicationContext, DOWNLOAD_NOTIFICATION_CHANNEL_ID)
        .setContentTitle("下载中")
        .setSmallIcon(android.R.drawable.stat_sys_download)
        .setPriority(NotificationCompat.PRIORITY_LOW)
        .setOngoing(true)

    // 最大文件名长度
    private val MAX_FILENAME_LENGTH = 50

    // 重写 getForegroundInfo() 以提供前台服务通知信息
    override suspend fun getForegroundInfo(): ForegroundInfo {
        return ForegroundInfo(
            DOWNLOAD_NOTIFICATION_ID,
            notificationBuilder.setContentText("开始下载...").build()
        )
    }

    override suspend fun doWork(): Result {
     //文件下载的具体逻辑写在这里面 
     ...
    }

    // Helper function to set progress for the UI
    private fun setProgress(progress: Int) {
        val progressData = workDataOf("progress" to progress)
        setProgressAsync(progressData)
    }
}

We obtain a WorkManager instance through the context, which directly handles all tasks related to the task database and scheduling system. WorkManager uses a Room database (an abstraction layer for SQLite databases) in the application's private storage space to achieve task persistence and state management. We can directly access all task information from the WorkManager instance. Combined with LiveData, the application interface can observe and display task status and progress in real time, achieving synchronization between background tasks and the UI.

    val workManager = WorkManager.getInstance(context)
    ...
    val workInfos: LiveData<List<WorkInfo>> = remember {
        workManager.getWorkInfosByTagLiveData(DOWNLOAD_WORK_TAG)
    }
    val downloadTasks by workInfos.observeAsState(initial = emptyList())
    ...
    LazyColumn(
        modifier = Modifier.fillMaxSize()
    ) {
        items(downloadTasks) { workInfo ->
            DownloadTaskItem(workInfo)
        }
    }

Define a download start method to encapsulate the process of submitting tasks to WorkManager.

fun startDownload(context: Context, url: String) {
    // 1. 创建 WorkRequest，指定要执行的 Worker
    val downloadRequest = OneTimeWorkRequestBuilder<DownloadWorker>()
        .setInputData(workDataOf(DOWNLOAD_WORK_URL to url)) // 2. 传递输入数据
        .addTag(DOWNLOAD_WORK_TAG) // 3. 添加标签以便跟踪
        .build()

    // 4. 将任务加入队列
    WorkManager.getInstance(context).enqueue(downloadRequest)
}

The above is the idea of using WorkManager to develop a downloader.

Looking ahead: New trends in Android background tasks and Google policies

Google has been tightening the permissions for background tasks to protect user privacy and device battery life. Future Android versions may introduce even stricter background execution restrictions, making traditional approaches like Services and BroadcastReceivers increasingly difficult to use.
Against this backdrop, WorkManager, as the officially recommended solution, will become increasingly important. It helps us comply with Google's policies while ensuring reliable task execution.

Summarize

Let's review the advantages of WorkManager: reliability, compatibility, durability, and flexibility. It frees developers to focus on business logic without having to worry about complex background task adaptation and compatibility issues.

If you're still struggling with background tasks, it's time to embrace WorkManager. It will not only make your app more stable but also your development more efficient.

The downloader code can be found in the following repository: https://github.com/Ilovecat1949/AndroidApps.

Please check out my audio and video development project: https://ilovecat1949.github.io/AudioAndVideoEditor/. This is an open-source Android audio and video editor that supports various audio and video functions, including ffmpeg command-line functionality, video encoding and compression, format conversion, video cropping, and speed changes.

References

Create your own personal website for free — A guide to using GitHub Pages

cat dog (running_in_the_storm) — Sat, 30 Aug 2025 00:28:12 +0000

Preface

I've been wanting to create a website for my independently developed app, AudioAndVideoEditor. Setting up a server, domain name, and developing the website from scratch is obviously expensive. GitHub offers free static web hosting, allowing you to launch your website in just a few steps (compared to developing a website from scratch). This article will explain how to use GitHub Pages, drawing on my own experience.

You're welcome to follow my GitHub Pages: https://ilovecat1949.github.io/AudioAndVideoEditor/ .It's an open-source Android audio and video editor that supports various audio and video features, including ffmpeg command-line functionality, video encoding and compression, format conversion, video cropping, and speed changes.

GitHub Pages advantages and limitations

Everyone knows that GitHub offers free code hosting, but not many people know that you can use GitHub Pages to build a personal website. Let me briefly explain the advantages and limitations of GitHub Pages.

Zero cost. This is the most obvious advantage. No server, domain, or hosting fees are required.
Easy to use. No development knowledge is required; you can build a website using ready-made templates. Especially with the addition of AI programming, it's even easier to customize your desired interface.
Stability and reliability. GitHub is reliable. Once you build your website, you don't have to worry about security issues like website takedowns or hacker attacks. GitHub's global CDN acceleration ensures lightning-fast page loads and supports HTTPS for secure encryption.
GitHub integration: Websites are directly hosted on GitHub repositories, making version control, collaboration, and sharing easy.
With a GitHub Pages website, you can create an online resume for job hunting. According to the GitHub Terms of Service, our use of GitHub Pages is subject to the following restrictions:
Each GitHub account can only create one user or organization site.

A GitHub Pages page has a URL formatted as username.github.io/projectname or organization.github.io/projectname. This restriction means that an account can only have one GitHub Pages site with username.github.io or organization.github.io. You can create different GitHub Pages for multiple projects, but they all have the same prefix: username.github.io or organization.github.io.
The recommended size limit for source code repositories is 1 GB, and published sites cannot exceed 1 GB.
Deployment timeout is 10 minutes.
There is a soft limit of 100 GB of monthly bandwidth.
A maximum of 10 builds per hour is allowed (sites published using custom GitHub Actions workflows are exempt from this limit).

Using GitHub Pages' default build method (for example, through the Publish Source option in GitHub Pages settings), your site can only trigger a maximum of 10 builds per hour.

However, if you use a custom GitHub Actions workflow to build and publish your site, this limit does not apply. In other words, custom GitHub Actions workflows can bypass the 10 builds per hour limit, allowing you to build and release your site more frequently as needed.
Rate limiting may apply to ensure quality of service, and triggering a rate limit will result in an HTTP status code 429 response.
Additionally, GitHub Pages is not intended for commercial transactions, SaaS services, or other sensitive transactions (such as sending passwords or credit card information).

GitHub Pages Setup Guide

GitHub Pages relies on a public GitHub repository. Therefore, before building GitHub Pages, you'll need to register for a GitHub account and create a GitHub repository. I'll be building on my open-source project, AudioAndVideoEditor. Once you have a repository, follow the steps below to activate GitHub Pages.

Go to your repository and click the "Settings" tab.
Find the "Pages" option in the left menu.
Under "Source," select "Deploy from a branch," then select the "main" branch (the default), and click "Save."
After a few minutes, refresh the page. You'll see the generated website URL: https://username.github.io/projectname. For example, mine is https://ilovecat1949.github.io/AudioAndVideoEditor/.

GitHub repositories typically have a README file. If no other webpage files are present, GitHub Pages will display your README file. To build a fancy and attractive interface, we usually need to create or upload a webpage file. Here's how.

In the repository (root directory), click "Add file" > "Create new file."
Name the file "index.html" and enter the following simple code:

<!DOCTYPE html>
<html>
<head>
    <title>我的个人网页</title>
</head>
<body>
    <h1>欢迎来到我的世界！</h1>
    <p>这里是我的介绍：热爱编程、旅行和咖啡。</p>
</body>
</html>

Commit your code, and refresh the site after a few seconds to see the updated content. This time, the contents of index.html are displayed.

Okay, that's the general idea and steps for using GitHub Pages. But it's obviously not enough to create a polished interface. Next, let's explore building a blog using a Jekyll template.

Branch Build and Actions Build

Before using Jekyll, we need to understand some basics about GitHub Pages builds. In the steps above, we can either choose a code branch as the source for the build or use GitHub Actions.
Building from a branch is the most traditional and simplest method. It works by specifying a branch (usually gh-pages or main), and GitHub Pages automatically uses the content from that branch as your website. Its advantages are simplicity and zero configuration. You simply push your static website files (HTML, CSS, and JS) directly to that branch (usually in the root directory). Its disadvantage is that there's no automated build process. If you use Jekyll, you'll need to first run jekyll build locally to generate a _site directory, then push all the files in _site to the GitHub Pages branch (usually in the root directory). This is tedious and prone to errors.
Building with Actions (GitHub Actions) is a more modern and powerful method. How it works is that you create a GitHub Actions workflow. When code is pushed to a specified branch, this workflow automatically runs, completes the Jekyll build for you in the cloud, and publishes the generated website files to GitHub Pages. Its advantage is that it is fully automated. You only need to push your Jekyll source code (such as .md files and layout files) to the repository, and all the rest of the work (building and deploying) is automatically completed by GitHub Actions. You don't need to run jekyll build locally. The disadvantage is that it requires writing and configuring a YAML workflow file, which may be a bit complicated for beginners. However, when you choose GitHub Actions to build, GitHub will prompt you to select Jekyll Workflow for the build. Just follow GitHub's prompts and it will automatically generate a .github/workflows/jekyll-gh-pages.yml workflow file for you.

Building with a branch is like manually uploading your project. You prepare the final product and then submit it to GitHub. The HTML, Markdown, and other files in the project's root directory serve as the source code for the webpage.
Building with Actions is like hiring a full-time automated worker. You provide the raw material (the Jekyll source code) and it completes all the work for you and delivers the final product. The code generated by the build is stored in the _site directory, and the files in the _site directory serve as the source code for the webpage.
I personally chose to build with Actions. I built the webpage locally using Jekyll build for debugging, then uploaded it to GitHub, triggering the workflow to build and publish it again.

GitHub Pages+Jekyll

First, let's talk about Jekyll. Jekyll is a powerful static website generator. It automatically generates a complete static website from your Markdown articles, combined with beautifully designed themes and templates. You focus on creating your content, while Jekyll handles the rest of the polish and layout. We no longer need to fiddle with Markdown to generate web pages; powerful AI programming can now directly generate web files that meet our needs. What we really need are Jekyll's themes, templates, local preview, and real-time debugging features.

Installing Jekyll

It's best to develop and test locally before uploading. To use Jekyll locally, you need to install some dependencies.
Jekyll is developed in Ruby, so you need to install Ruby and Bundler first.
Installing Ruby:
Windows users: We recommend using RubyInstaller for Windows. During installation, select the "Add Ruby executables to your PATH" option.
macOS users: Ruby is usually pre-installed. You can check the version by typing "ruby -v" in the terminal.
Linux users: Use a package manager (e.g., "sudo apt-get install ruby-full").
Installing Bundler:
Bundler is a Ruby package manager that manages and installs the dependencies required for Jekyll projects. In a terminal or command prompt, run the following Bash command:

gem install bundler jekyll

This command will install both Bundler and Jekyll.
The above installation is expected to take up 1GB of disk space.

Clone your repository locally

Now, you'll need to clone the website repository you created on GitHub to your local computer.
Install Git: If you don't have Git installed on your computer, you'll need to install it first.
Clone the repository: Open a terminal or Git Bash, navigate to the folder where you want to store your project, and run the following command:

git clone https://github.com/YourGitHubusername/projectname.git
cd projectname

Once you're in your project folder, you can start your website locally.
Install dependencies: Run the following command to install the project's required dependencies (including Jekyll and the theme plugin):

bundle install

The first run may take some time.
Starting a local server: Now, run the following command to start a local server:

bundle exec jekyll serve

After the command completes, you'll see a local URL in your terminal, typically http://127.0.0.1:4000. Open this URL in your browser and you'll see your website.
Now, navigate to your repository directory and you'll notice a number of new files and directories. In the root directory, there's a file called index_markdown.md, which serves as the default entry point for the entire website. As mentioned above, we won't bother with generating Markdown pages. Instead, we'll change index_markdown.md to index_markdown.txt, which will disable it. Then, add an index.html file (if one isn't already there) so that Jekyll uses it as the entry point for the website.

Then, you just need to let AI write web page code based on Jekyll to meet your needs.

After writing the code, you can preview the effect locally and submit the code if it is OK.

git add .
git commit -m "Your submission information"
git push origin main

After submitting, GitHub Pages will automatically deploy the website for you again (selecting Actions Build will rebuild and then deploy it), so that your online website is completely synchronized with the local one.

Summarize

Using GitHub Pages, you can create a free website to promote yourself, your projects, and your products, creating a personal "digital business card" that might even add a splash to your resume. Paired with the ever-popular AI programming, creating a satisfying static webpage is easy. Open GitHub now and start your creative journey!

Finally, I welcome everyone to follow my GitHub Pages: https://ilovecat1949.github.io/AudioAndVideoEditor/ It's an open-source audio and video editor for Android, supporting various audio and video features, such as the ffmpeg command line, video encoding and compression, format conversion, video cropping, and speed changes.

Forem: cat dog (running_in_the_storm)

Efficient Android Screen Recording Using MediaRecorder + MediaProjection

Efficient Android Screen Recording Using MediaRecorder + MediaProjection

Preface

Core of MediaRecorder: Lifecycle State Machine

Core Features of MediaProjection

Building Your Screen Recording App

Permission Requests and User Authorization

Core of Screen Recording: Foreground Service RecordingService

Summary

References

Efficiently Building App Permission Flows with the Compose Permission Request Template

Efficiently Building App Permission Flows with the Compose Permission Request Template

Foreword

Article Objectives

Basic Setup: Manifest Declaration and Dependency Inclusion

Introduce Compose Activity Dependency

Core Practice: Building the Permission Request Template with rememberLauncherForActivityResult

Activity Context Retrieval Utility

Template Code Implementation

Auxiliary Composable Encapsulation (Button and Rationale)

Template Usage: Concise and Efficient Call Example

Differences in Different Versions

Summary

References

Tired of complicated compilation?Integrate AeroFFmpeg with one click to make Android audio and video development easier!

Tired of complicated compilation？Integrate AeroFFmpeg with one click to make Android audio and video development easier!

Preface

Minimalistic AeroFFmpeg Integration

Importing the AeroFFmpeg AAR File

AeroFFmpeg Usage and Scenarios

Completing Background Audio and Video Tasks with AeroFFmpeg and WorkManager

Summary

References

Say goodbye to tedious work and use WorkManager to solve the problem of background work

Say goodbye to tedious work and use WorkManager to solve the problem of background work

Preface

Why WorkManager is the best choice

Core Concepts and Practices: How does WorkManager work?

Talking with code: Developing a downloader using WorkManager

design

Looking ahead: New trends in Android background tasks and Google policies

Summarize

References

Create your own personal website for free — A guide to using GitHub Pages

Preface

GitHub Pages advantages and limitations

GitHub Pages Setup Guide

Branch Build and Actions Build

GitHub Pages+Jekyll

Installing Jekyll

Clone your repository locally

Summarize

reference

Core of Screen Recording: Foreground Service `RecordingService`

Core Practice: Building the Permission Request Template with `rememberLauncherForActivityResult`