Refactor activity caching logic to extend CustomActivityCachingLogic … by saulhdev · Pull Request #540 · NeoApplications/Neo-Launcher

saulhdev · 2026-02-22T00:49:09Z

…and update version code

Copilot

Pull request overview

This PR aims to make activity icon/label caching logic extendable (to support Neo’s custom app names), wire the custom caching logic into icon loading/updating, adjust first-screen installer broadcast behavior, and bump the app versionCode.

Changes:

Introduces CustomActivityCachingLogic to override activity labels based on NeoPrefs.customAppName.
Refactors LauncherActivityCachingLogic from a Kotlin object to an open class to allow inheritance.
Routes icon cache updates to use CustomActivityCachingLogic and increments versionCode.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
src/com/android/launcher3/model/LoaderTask.java	Updates first-screen broadcast gating and switches icon update caching logic to the custom implementation.
src/com/android/launcher3/icons/IconCache.java	Switches multiple icon-cache entry points to use the custom caching logic.
libs_systemui/iconloaderlib/src/com/android/launcher3/icons/cache/LauncherActivityCachingLogic.kt	Changes caching logic from singleton object to extendable class (behavioral/ABI change).
build.gradle.kts	Bumps `versionCode` from 1006 to 1007.
Omega/src/com/neoapps/neolauncher/util/CustomActivityCachingLogic.kt	Adds Neo-specific caching logic to return custom app labels from preferences.

Comments suppressed due to low confidence (2)

Omega/src/com/neoapps/neolauncher/util/CustomActivityCachingLogic.kt:25

Unused import SafeCloseable can be removed to keep the file clean and avoid lint/compiler warnings.

import com.android.launcher3.dagger.LauncherAppSingleton
import com.android.launcher3.icons.cache.LauncherActivityCachingLogic
import com.android.launcher3.util.ComponentKey
import com.android.launcher3.util.SafeCloseable
import com.neoapps.neolauncher.preferences.NeoPrefs

src/com/android/launcher3/icons/IconCache.java:244

CustomActivityCachingLogic is instantiated in multiple hot paths (e.g., per icon cache update). Consider reusing a single instance (or injecting a singleton) to avoid repeated allocations and to align with the @LauncherAppSingleton intent.

    public synchronized void updateTitleAndIcon(AppInfo application) {
        CacheEntry entry = cacheLocked(application.componentName,
                application.user, () -> null, new CustomActivityCachingLogic(),
                application.getMatchingLookupFlag());

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-02-22T00:55:24Z

src/com/android/launcher3/model/LoaderTask.java

        updateHandler.updateIcons(allActivityList,
-                LauncherActivityCachingLogic.INSTANCE,
+                new CustomActivityCachingLogic(),
                mModel::onPackageIconsUpdated);


After switching to CustomActivityCachingLogic, this file no longer references LauncherActivityCachingLogic, so the existing import com.android.launcher3.icons.cache.LauncherActivityCachingLogic; becomes unused and will fail Java compilation. Please remove the unused import (or reintroduce a reference if still needed).

Copilot · 2026-02-22T00:55:24Z

src/com/android/launcher3/icons/IconCache.java

        for (LauncherActivityInfo app : apps) {
-            addIconToDBAndMemCache(app, LauncherActivityCachingLogic.INSTANCE, userSerial);
+            addIconToDBAndMemCache(app, new CustomActivityCachingLogic(), userSerial);
        }


All usages of LauncherActivityCachingLogic were replaced, so import com.android.launcher3.icons.cache.LauncherActivityCachingLogic; is now unused in this Java file and will fail compilation. Remove the unused import (or keep using the base logic where appropriate).

Copilot · 2026-02-22T00:55:24Z

src/com/android/launcher3/model/LoaderTask.java

+        if (shouldAttachArchivingExtras) {
+            List<FirstScreenBroadcastModel> broadcastModels =
+                    mFirstScreenBroadcastHelper.createModelsForFirstScreenBroadcast(
+                            firstScreenItems,
+                            mInstallingPkgsCached,
+                            mBgDataModel.itemsIdMap.stream().filter(WIDGET_FILTER).collect(Collectors.toList()),
+                            shouldAttachArchivingExtras
+                    );
+            logASplit("Sending first screen broadcast with shouldAttachArchivingExtras="
+                    + shouldAttachArchivingExtras);
            broadcastModels.forEach(bm -> bm.sentBroadcast(mContext));
+        } else {
+            logASplit("Sending first screen broadcast");
+            //mFirstScreenBroadcastHelper.sendBroadcasts(mContext, firstScreenItems);
        }


The else-branch no longer sends any first-screen broadcast (the call is commented out), so pending installs won’t be reported unless shouldAttachArchivingExtras is true. Previously the broadcast was still sent with shouldAttachArchivingExtras=false to report pending items only. Consider always creating/sending the FirstScreenBroadcastModels and using shouldAttachArchivingExtras only to control which extras are attached, and remove the dead commented-out call.

Suggested change

if (shouldAttachArchivingExtras) {

List<FirstScreenBroadcastModel> broadcastModels =

mFirstScreenBroadcastHelper.createModelsForFirstScreenBroadcast(

firstScreenItems,

mInstallingPkgsCached,

mBgDataModel.itemsIdMap.stream().filter(WIDGET_FILTER).collect(Collectors.toList()),

shouldAttachArchivingExtras

);

logASplit("Sending first screen broadcast with shouldAttachArchivingExtras="

+ shouldAttachArchivingExtras);

broadcastModels.forEach(bm -> bm.sentBroadcast(mContext));

} else {

logASplit("Sending first screen broadcast");

//mFirstScreenBroadcastHelper.sendBroadcasts(mContext, firstScreenItems);

}

List<FirstScreenBroadcastModel> broadcastModels =

mFirstScreenBroadcastHelper.createModelsForFirstScreenBroadcast(

firstScreenItems,

mInstallingPkgsCached,

mBgDataModel.itemsIdMap.stream()

.filter(WIDGET_FILTER)

.collect(Collectors.toList()),

shouldAttachArchivingExtras

);

if (shouldAttachArchivingExtras) {

logASplit("Sending first screen broadcast with shouldAttachArchivingExtras=true");

} else {

logASplit("Sending first screen broadcast with shouldAttachArchivingExtras=false");

}

broadcastModels.forEach(bm -> bm.sentBroadcast(mContext));

Copilot · 2026-02-22T00:55:25Z

src/com/android/launcher3/model/LoaderTask.java

        updateHandler.updateIcons(allActivityList,
-                LauncherActivityCachingLogic.INSTANCE,
+                new CustomActivityCachingLogic(),
                mModel::onPackageIconsUpdated);


CustomActivityCachingLogic lives under the omega flavor source set (Omega/src), but LoaderTask.java is in the main source set. This import/usage will break compilation for the aosp variant. Either move the caching-logic implementation into main, or keep main using the base LauncherActivityCachingLogic and override the behavior from the omega source set (e.g., via a flavor-specific subclass/factory/DI binding).

Copilot · 2026-02-22T00:55:25Z

src/com/android/launcher3/icons/IconCache.java

        removeIconsForPkg(packageName, user);
        long userSerial = mUserManager.getSerialNumberForUser(user);
        for (LauncherActivityInfo app : apps) {
-            addIconToDBAndMemCache(app, LauncherActivityCachingLogic.INSTANCE, userSerial);
+            addIconToDBAndMemCache(app, new CustomActivityCachingLogic(), userSerial);
        }


IconCache is in the main source set, but it now depends on com.neoapps.neolauncher.util.CustomActivityCachingLogic which is only present in the omega flavor (Omega/src). This will fail to compile for the aosp variant. Please keep main flavor-agnostic (use the base caching logic there) and apply the Neo-specific logic via omega-only sources or an injected/factory-provided CachingLogic implementation.

Copilot · 2026-02-22T00:55:25Z

...systemui/iconloaderlib/src/com/android/launcher3/icons/cache/LauncherActivityCachingLogic.kt

+open class LauncherActivityCachingLogic : CachingLogic<LauncherActivityInfo> {



This refactor changes LauncherActivityCachingLogic from a Kotlin object to a class, which removes the singleton value that existing call sites rely on (e.g., Java .INSTANCE and Kotlin usages that pass LauncherActivityCachingLogic as a CachingLogic). To avoid widespread breakage, consider keeping a singleton object LauncherActivityCachingLogic for the default behavior and introducing a separate open base class for extension (or update all call sites/tests to instantiate/pass a shared instance explicitly).

Refactor activity caching logic to extend CustomActivityCachingLogic …

0aefb10

…and update version code

Copilot AI review requested due to automatic review settings February 22, 2026 00:49

Copilot started reviewing on behalf of saulhdev February 22, 2026 00:49 View session

saulhdev merged commit 303d149 into main Feb 22, 2026
3 checks passed

Copilot AI reviewed Feb 22, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor activity caching logic to extend CustomActivityCachingLogic …#540

Refactor activity caching logic to extend CustomActivityCachingLogic …#540
saulhdev merged 1 commit intomainfrom
A16

saulhdev commented Feb 22, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Feb 22, 2026

Uh oh!

Copilot AI Feb 22, 2026

Uh oh!

Copilot AI Feb 22, 2026

Uh oh!

Copilot AI Feb 22, 2026

Uh oh!

Copilot AI Feb 22, 2026

Uh oh!

Copilot AI Feb 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

		open class LauncherActivityCachingLogic : CachingLogic<LauncherActivityInfo> {

Conversation

saulhdev commented Feb 22, 2026

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Feb 22, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants