feat: Add `--options-file` json patch/option configuration by prateek-who · Pull Request #53 · MorpheApp/morphe-cli

prateek-who · 2026-02-16T14:08:32Z

Allows users to export a patch.mpp file's patches and its options to a json file. What's new:

New options-create subcommand:
Exports all patches from the patch.mpp file into a json file with:
java -jar morphe-cli-all.jar options-create --patches patches.mpp --output options.json
this exports all patches, use -f flag for filtering the patches for the app you need.
New --options-file flag on the patch command:
Allow users to use the json file to suggest what patches they want/ don't want to the cli.
java -jar morphe-cli-all.jar patch --patches patches-1.13.0.mpp --options-file options.json --output patched.apk input.apk
New --skip-options-update flag on the patch command
By default, after patching, the JSON file is auto-updated to stay in sync with the patch.mpp:
- New patches added to .mpp get appended with defaults
- Patches removed from .mpp get dropped
- New option keys get added, stale ones removed
- Your existing enabled values and option edits are preserved
  
  If you don't want to update the options.json file, add --skip-options-update argument.

allows users to export a patch.mpp file's patches and its options to a json file.

prateek-who · 2026-02-16T14:16:24Z

Please check this thoroughly once. I used a lot of claude to write this. Even though it seems to work in my testing, check the code quality once and if it is following your standards of the project.

Create the options.json file by default when not present and start patching using default options. Says it in the logs too

prateek-who · 2026-02-17T14:11:27Z

try this once

LisoUseInAIKyrios · 2026-02-17T15:32:37Z

Everything seems to be working. This is a big improvement from the old xargs nonsense that was previously required.

LisoUseInAIKyrios · 2026-02-17T16:46:45Z

When patching with the option-file argument, can the updated options.json be wrote to disk earlier? Right now it waits until all patching is done, but it would be more convenient if it updated the file immediately.

But if this behavior is difficult to add or adds to much complexity to the code then we should not make this change.

wchill · 2026-02-17T17:16:46Z

New --skip-options-update flag on the patch command
By default, after patching, the JSON file is auto-updated to stay in sync with the patch.mpp:

I think the behavior of this flag should be reversed, for safety reasons. It's not hard to envision situations where this might result in data loss. It should either be an explicit opt-in, or the CLI should generate a new timestamped JSON that the user can load next time if it notices that the patch options have changed.

LisoUseInAIKyrios · 2026-02-17T17:38:14Z

New --skip-options-update flag on the patch command
By default, after patching, the JSON file is auto-updated to stay in sync with the patch.mpp:

I think the behavior of this flag should be reversed, for safety reasons. It's not hard to envision situations where this might result in data loss. It should either be an explicit opt-in, or the CLI should generate a new timestamped JSON that the user can load next time if it notices that the patch options have changed.

That makes sense. Can invert the logic and change it to --options-update

prateek-who · 2026-02-17T17:41:53Z

Will make it so that it adds the timestamp too like: options_{timestamp}.json

Also, should we generate 2 files like options.json and patches.json as the issue author suggested? Does it have more benefits than our current system?

LisoUseInAIKyrios · 2026-02-17T17:52:20Z

I think a timestamp in the file name makes it slightly less convenient because it's a weird file name and not the name the CLI command specified. At least for me I would immediately rename it to what I wanted so it's a second step.

How about timestamps inside the json?

It can be the first fields. Stuff like "created_at" : "18 February 2026, whatever time"
Another field for update date. Another field for input jar. Can add any other useful meta data if any exists.

LisoUseInAIKyrios · 2026-02-17T17:53:08Z

I think a single JSON is ok. I'm not sure what useful situation two files would provide, especially since options are rarely the same between different patch repos.

prateek-who · 2026-02-17T19:04:10Z

Now if we reverse that flag, when the user doesn't use the flag the updation doesn't happen right? But if they do use that flag, do we overwrite the file?

LisoUseInAIKyrios · 2026-02-17T19:17:26Z

If they use --options-update when patching then the the json file is updated (same behavior as before, remove unused patches/options and add missing patches/options).

If they don't use --options-update then the json file is never changed (even if it has outdated patches/JSON).

prateek-who · 2026-02-17T19:22:21Z

See if this does the trick. Also currently the json updates once the apk is patched and written to disk. Should we maybe update the json file before the patching process begins?

LisoUseInAIKyrios · 2026-02-17T19:23:54Z

Yes, I think that's the last change.

wchill · 2026-02-17T19:32:40Z

Now if we reverse that flag, when the user doesn't use the flag the updation doesn't happen right? But if they do use that flag, do we overwrite the file?

Give them a warning that their options JSON is out of date if (a) they don't provide the flag, and (b) the available options really did change.

That way, they know to use the flag and don't forget.

src/main/kotlin/app/morphe/cli/command/PatchCommand.kt

prateek-who · 2026-02-17T19:38:50Z

Once issue we have right now is:
options-create: Nukes everything, fresh defaults. User loses all their choices.
--options-update (during patch): Merges and preserves user choices, adds new patches with defaults, drops removed ones.

What we don't have is, there's no way to do a merge without patching. If the user gets a new .mpp and just wants to see "what's new?", they either nuke their file with options-create or they have to run a full patch with --options-update.

So to solve this, we could simple let options-create do a merge too instead of remove and recreate the file? Add a --force flag to nuke and recreate the json file if they want to. And then ofc move the joson updation of --options-update to happen before the patching starts. This will cover almost all edge cases but is it even necessary is the question? What do you think of this?

wchill · 2026-02-17T19:43:54Z

I think having options-create and --options-update might be a bit too extra. Maybe instead of options-create, add a new flag --dry-run which does the options merging and shows what patch options would have been selected (and exports the file), but doesn't actually patch/sign/install.

LisoUseInAIKyrios · 2026-02-17T19:45:05Z

To prevent nuking, the existing options-create can update an existing json if the specified file exists. Otherwise it creates from new. So if they use the command with an existing options.json then the behavior is identical to using an option JSON during patching with the update option. I think this behavior is the most consistent and also will prevent data loss of the still relevant data.

So if the user wants to completely reset their options.json file, they would manually need to delete it before they run options-create. This command should be verbose in what's happening ("created new file", "updated file", etc).

LisoUseInAIKyrios · 2026-02-17T19:48:45Z

I think having options-create and --options-update might be a bit too extra. Maybe instead of options-create, add a new flag --dry-run which does the options merging and shows what patch options would have been selected (and exports the file), but doesn't actually patch/sign/install.

I'm thinking do both operations in a single command. Create if the file isn't present, and update if it is.

Then there will be just 3 JSON CLI commands/arguments, and it handles all use cases. If a user wants to nuke their options and start over then they can manually delete it and create again.

wchill · 2026-02-17T19:49:06Z

Name it dump-options instead of options-create, maybe?

LisoUseInAIKyrios · 2026-02-17T19:50:37Z

Name it dump-options instead of options-create, maybe?

Hmm, if it's updating then dump isn't quite right. But the existing options-create isn't right either because it can also update.

prateek-who · 2026-02-17T19:51:21Z

To prevent nuking, the existing options-create can update an existing json if the specified file exists. Otherwise it creates from new. So if they use the command with an existing options.json then the behavior is identical to using an option JSON during patching with the update option. I think this behavior is the most consistent and also will prevent data loss of the still relevant data.

So if the user wants to completely reset their options.json file, they would manually need to delete it before they run options-create. This command should be verbose in what's happening ("created new file", "updated file", etc).

This feels like the best option.

Users now get a warning if their optisn.json file has differences with the patch.mpp file when using --options-file without --options-update. CLI flags overriding JSON values now logs the information. options-create now merges instead of deleting the entire file. Users can still create a completely new file by deleteing or renaming the old or the new file. Potential memory leak fix by moving heavy patches (Set<Patch<*>> with DEX classloaders) inside the try block. The finally block now uses a lightweight patchesSnapshot (PatchOptionsFile) instead.

prateek-who · 2026-02-17T20:41:29Z

Name it dump-options instead of options-create, maybe?

Hmm, if it's updating then dump isn't quite right. But the existing options-create isn't right either because it can also update.

I've left it as options-create as of right now, but will change it once somebody comes up with a better name

LisoUseInAIKyrios · 2026-02-17T20:46:23Z

I think options-create is ok.

Updating is technically creation for most cases, and it accurately conveys the command as the starting point of JSON usage which is important.

Now the patches are checked against the target app making sure no extra patch throws new update warning

src/main/kotlin/app/morphe/cli/command/PatchCommand.kt

# [1.4.0-dev.6](v1.4.0-dev.5...v1.4.0-dev.6) (2026-02-19) ### Features * Add `--options-file` json patch/option configuration ([#53](#53)) ([44943da](44943da))

# [1.4.0](v1.3.0...v1.4.0) (2026-02-21) ### Bug Fixes * Allow enabling/disabling patches using case insensitive patch names ([#48](#48)) ([03a280a](03a280a)) * Do not log patch name more than once if disabled ([#49](#49)) ([b980bb8](b980bb8)) ### Features * Add `--continue-on-error` argument, return non zero exit code if patching fails ([#47](#47)) ([255646b](255646b)) * Add `--options-file` json patch/option configuration ([#53](#53)) ([44943da](44943da)) * Add `--striplibs` argument to strip unwanted architectures ([#46](#46)) ([7442d94](7442d94)) * Support patching APKM bundles ([#40](#40)) ([bfe43d0](bfe43d0))

prateek-who added 2 commits February 16, 2026 19:08

json update

8ce2423

allows users to export a patch.mpp file's patches and its options to a json file.

Update PatchCommand.kt

7126071

create default options.json

8140fc1

Create the options.json file by default when not present and start patching using default options. Says it in the logs too

LisoUseInAIKyrios changed the title ~~feat: patch-json update~~ feat: Add --options-file json patch/option configuration Feb 17, 2026

Adjust CLI argument names, update documentation

f667c5f

LisoUseInAIKyrios force-pushed the export-json branch from 0d76eab to f667c5f Compare February 17, 2026 15:55

LisoUseInAIKyrios requested a review from wchill February 17, 2026 16:46

LisoUseInAIKyrios linked an issue Feb 17, 2026 that may be closed by this pull request

feat: Create cli options to export both patches and options to JSON and set options from JSON during pathing #44

Closed

2 tasks

reverse flag update

aa27ef4

wchill reviewed Feb 17, 2026

View reviewed changes

src/main/kotlin/app/morphe/cli/command/PatchCommand.kt Outdated Show resolved Hide resolved

src/main/kotlin/app/morphe/cli/command/PatchCommand.kt Outdated Show resolved Hide resolved

src/main/kotlin/app/morphe/cli/command/PatchCommand.kt Show resolved Hide resolved

prateek-who added 2 commits February 18, 2026 02:30

Fixed targeted app options

72db909

Now the patches are checked against the target app making sure no extra patch throws new update warning

Another round of potential fixes

a48af1a

LisoUseInAIKyrios reviewed Feb 18, 2026

View reviewed changes

src/main/kotlin/app/morphe/cli/command/PatchCommand.kt Outdated Show resolved Hide resolved

LisoUseInAIKyrios and others added 2 commits February 18, 2026 09:54

Update documentation, adjust logging output

1ef92ae

Update PatchCommand.kt

61071fa

LisoUseInAIKyrios mentioned this pull request Feb 18, 2026

feat: Create cli options to export both patches and options to JSON and set options from JSON during pathing #44

Closed

2 tasks

LisoUseInAIKyrios merged commit 44943da into MorpheApp:dev Feb 19, 2026
1 check passed

github-actions bot pushed a commit that referenced this pull request Feb 19, 2026

chore: Release v1.4.0-dev.6 [skip ci]

47d74c7

# [1.4.0-dev.6](v1.4.0-dev.5...v1.4.0-dev.6) (2026-02-19) ### Features * Add `--options-file` json patch/option configuration ([#53](#53)) ([44943da](44943da))

Uh oh!

Comments

Conversation

prateek-who commented Feb 16, 2026 • edited by LisoUseInAIKyrios Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

prateek-who commented Feb 16, 2026

Uh oh!

prateek-who commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

wchill commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

prateek-who commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

prateek-who commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

prateek-who commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

wchill commented Feb 17, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

prateek-who commented Feb 17, 2026

Uh oh!

wchill commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wchill commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

prateek-who commented Feb 17, 2026

Uh oh!

prateek-who commented Feb 17, 2026

Uh oh!

LisoUseInAIKyrios commented Feb 17, 2026

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

prateek-who commented Feb 16, 2026 •

edited by LisoUseInAIKyrios

Loading

LisoUseInAIKyrios commented Feb 17, 2026 •

edited

Loading

prateek-who commented Feb 17, 2026 •

edited

Loading

LisoUseInAIKyrios commented Feb 17, 2026 •

edited

Loading

LisoUseInAIKyrios commented Feb 17, 2026 •

edited

Loading

LisoUseInAIKyrios commented Feb 17, 2026 •

edited

Loading