Add customer package options#36
Conversation
|
Unable to trigger custom agent "Code Reviewer". You have run out of credits 😔 |
There was a problem hiding this comment.
Code Review
This pull request introduces customer package options and policies for ColorOS Themes Rock, adding several new targets, a colors.xml token template, and updating configurations, documentation, and the LSPosed helper app. The review feedback highlights several inconsistencies across configuration files, documentation, and Java source code, specifically regarding mismatched target IDs for oplus_eyeprotect and oplus_notificationmanager, as well as inconsistent status labels for com.oplus.ota.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7dfb3f6bd7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| version=v0.6.1 | ||
| versionCode=13 |
There was a problem hiding this comment.
Keep the APK and module versions in sync
When this module.prop change is pushed to main, the publish workflow is triggered, but without a tag/input it derives MODULE_VERSION from lsposed-helper/app/build.gradle (still 0.6.0 / versionCode 12) and scripts/package.sh then rewrites module.prop to that value before zipping. The result is a v0.6.1 commit publishing/clobbering v0.6.0 artifacts instead of releasing versionCode 13, so please bump the helper APK metadata or change the workflow to use this version source consistently.
Useful? React with 👍 / 👎.
| "package": "com.oplus.battery", | ||
| "customer_name": "OPlus Battery", | ||
| "area": "battery_cards_power_saver_labels_diagnostics", | ||
| "default_status": "Safe guidance", |
There was a problem hiding this comment.
Add the new statuses to the target label list
This target introduces Safe guidance, and other new targets use Template ready and Safe shortcut, but the top-level status_labels array still only contains the older labels. For the APK flow that reads assets/Overlays/targets.json to render customer status choices, these new default statuses are outside the declared label set and can be treated as unknown/missing; add the new labels there or reuse existing statuses.
Useful? React with 👍 / 👎.
| "android": "assets/Overlays/android", | ||
| "com.android.systemui": "assets/Overlays/systemui", | ||
| "com.android.settings": "assets/Overlays/settings", | ||
| "com.oplus.uxdesign": "assets/Overlays/oplus/uxdesign", |
There was a problem hiding this comment.
Create mapped overlay folders before advertising targets
This new folder mapping points customers at assets/Overlays/oplus/uxdesign, but that directory is not present in the repo tree (the new battery, notificationmanager, ota, and themeInner eyeprotect paths are also absent). Since the documented APK flow reads this map before letting customers select a target/layer, those options will resolve to missing asset locations instead of safe previews/status reports; add placeholder directories/assets or omit the mappings until they exist.
Useful? React with 👍 / 👎.
| "items": [ | ||
| {"id": "free_mode", "name": "Free Mode", "status": "enabled", "risk": "low"}, | ||
| {"id": "professional_modularity", "name": "Professional Modular Architecture", "status": "ready", "risk": "low"}, | ||
| {"id": "hook_overlay_architecture", "name": "Hook and Overlay Architecture", "status": "ready", "risk": "medium"}, | ||
| {"id": "device_profile", "name": "Device Profile Detection", "status": "ready", "risk": "low"}, | ||
| {"id": "android_15_support", "name": "Android 15 support label", "status": "supported_target", "risk": "low"}, | ||
| {"id": "android_16_support", "name": "Android 16 support label", "status": "forward_compatible_needs_device_test", "risk": "medium"}, | ||
| {"id": "android_17_support", "name": "Android 17 support label", "status": "preview_safe_needs_device_test", "risk": "medium"}, | ||
| {"id": "customer_package_options", "name": "Customer package options", "status": "ready", "risk": "medium"}, |
There was a problem hiding this comment.
Preserve existing customer option entries
This array is the customer option inventory, but the update replaces the previous safe entries such as safe-disable/OTA safe mode, wallpaper, performance tips, log export, backup/restore, and Android support labels with only the new package-target entries. Any customer UI or release tooling that renders items from this config will hide those existing free/safe tools, which also conflicts with the new package-options rule to keep normal customer tools visible; append the package options instead of dropping the old entries.
Useful? React with 👍 / 👎.
| "package": "com.oplus.ota", | ||
| "customer_name": "OPlus OTA", | ||
| "area": "ota_labels_update_warnings_safe_disable_guidance", | ||
| "default_status": "Safe guidance", |
There was a problem hiding this comment.
Keep OTA status warning-only in the target map
For the high-risk OTA target, this default status is less restrictive than the rest of the same change: customer-options/options.json, safe-defaults.conf, and the new docs all use safe_guidance_only / Safe guidance only to indicate no runtime modification. When customers select targets from assets/Overlays/targets.json, this entry can display OTA as ordinary guidance instead of the explicit warning-only mode, so align it with the stricter label.
Useful? React with 👍 / 👎.
| "apply_policy": "systemless_preview_only_until_device_tested" | ||
| }, | ||
| { | ||
| "id": "oplus_notification_manager", |
There was a problem hiding this comment.
Use the same notification manager id everywhere
This target id is oplus_notification_manager, but the matching entries added in customer-options/options.json and safe-defaults.conf use oplus_notificationmanager / TARGET_OPLUS_NOTIFICATIONMANAGER. Any tooling that joins the target map with the customer options by id will fail to find the status/actions for this package even though the package name matches, so normalize the id across the new config entries.
Useful? React with 👍 / 👎.
| "mount_targets": ["system_ext/media/themeInner"], | ||
| "overlay_targets": ["android", "com.android.systemui", "com.android.settings"] | ||
| "mount_targets": ["system_ext/media/themeInner", "system_ext/media/themeInner/com.oplus.eyeprotect"], | ||
| "overlay_targets": ["android", "com.android.systemui", "com.android.settings", "com.oplus.uxdesign", "com.oplus.battery", "com.android.launcher", "com.oplus.eyeprotect", "com.oplus.notificationmanager", "com.oplus.ota", "com.android.wallpaper.livepicker"] |
There was a problem hiding this comment.
Keep guidance-only packages out of overlay targets
This now classifies guidance/shortcut packages such as com.oplus.battery, com.oplus.notificationmanager, com.oplus.ota, and com.android.wallpaper.livepicker as rootd.overlay_targets, while the new customer options mark them as guidance or shortcut flows rather than overlay/apply targets. In configurations that use this list for overlay readiness scans or target selection, those packages can be presented as modifiable overlay targets despite the safety policy; keep only actual overlay candidates here and list guidance-only packages under customer_package_options.
Useful? React with 👍 / 👎.
Summary
com.oplus.uxdesigncom.oplus.batterycolors.xmlcom.android.launchercom.oplus.eyeprotectcom.oplus.notificationmanagercom.oplus.otacom.android.wallpaper.livepickerv0.6.1/ versionCode13.Safety
Needs testinguntil verified on the exact device and ROM.