Add support for hooking all methods of a class

[cpholguera]

Summary

Closes #22

This PR adds the ability to hook all methods of a class by specifying only the class field in the hook configuration, eliminating the need to enumerate individual methods.

Problem

Previously, when users wanted to comprehensively monitor a class, they had to either:

• Manually list all methods using the methods array
• Hook specific methods individually

This was tedious, error-prone, and difficult to maintain when classes had many methods or when exploring unfamiliar codebases.

Solution

Enhanced the buildHookOperations() function in frooky/android/base_script.js to automatically hook all methods when only class is specified:

1. Detects when no method or methods field is present
2. Uses Java reflection (getDeclaredMethods()) to enumerate all methods
3. Hooks all overloads of each discovered method
4. Gracefully skips methods that cannot be hooked (synthetic methods, constructors)

Usage Example

Before (had to enumerate methods):

{
  "class": "android.app.SharedPreferencesImpl$EditorImpl",
  "methods": ["putString", "putInt", "putBoolean", "apply", "commit", ...]
}

After (just specify the class):

{
  "class": "android.app.SharedPreferencesImpl$EditorImpl"
}

This automatically hooks all 13 methods: putString, putInt, putBoolean, putLong, putFloat, putStringSet, remove, clear, commit, apply, commitToMemory, notifyListeners, and lambda$notifyListeners$0.

Testing

Verified with android.app.SharedPreferencesImpl$EditorImpl:

• Summary correctly lists all 13 hooked methods
• All method calls are captured successfully
• No errors during hook registration

Documentation

Updated docs/usage.md with a new "Hook All Methods of a Class" section explaining the feature with examples.

Benefits

✅ Comprehensive coverage - Capture all method calls on a class
✅ Less maintenance - No need to update hook files when methods are added
✅ Discovery - Helps identify which methods are actually being called
✅ Convenience - Simpler hook configurations for exploratory analysis

[Copilot]

Pull request overview

This PR adds the ability to hook all methods of a class by specifying only the class field in the hook configuration, which eliminates the need to manually enumerate individual methods. This is useful for comprehensive monitoring and exploratory analysis of unfamiliar codebases.

Changes:

• Enhanced buildHookOperations() function to detect when no method or methods field is present and automatically enumerate and hook all methods using Java reflection
• Updated function documentation to describe the new scenario
• Added documentation section in docs/usage.md explaining the new feature with examples

Reviewed changes

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

File	Description
frooky/android/base_script.js	Added logic to enumerate and hook all methods of a class when only the class field is specified, with appropriate error handling
docs/usage.md	Added documentation section explaining how to hook all methods of a class

---

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

[Copilot]

The condition will trigger the "hook all methods" behavior when methods is explicitly set to an empty array. This may be unexpected behavior - if a user explicitly specifies methods: [], they likely intend to hook zero methods, not all methods. Consider checking if the methods property exists in the hook object (using !('methods' in hook)) rather than checking if it's falsy or empty. This would distinguish between "methods not specified" (hook all) and "methods specified as empty array" (hook none).

Suggested change

	if (!hook.method && (!hook.methods || hook.methods.length === 0)) {
	if (!hook.method && !("methods" in hook)) {

[Copilot]

When only class and overloads are specified (without method or methods), the new logic will hook all methods of the class and silently ignore the overloads field. This could be confusing for users who mistakenly specify overloads without a method name. Consider adding validation to detect this case and emit a warning or error, similar to how the invalid combination of methods + overloads is handled at line 381.

Suggested change

	// If only class is specified (no method/methods), hook all methods
	if (!hook.method && (!hook.methods || hook.methods.length === 0)) {
	// Invalid configuration: overloads without method/methods
	if (!hook.method && (!hook.methods || hook.methods.length === 0) &&
	hook.overloads && hook.overloads.length > 0) {
	let errInvalidOverloads = "Invalid hook configuration for " + hook.class + ": 'overloads' requires a singular 'method' name, not only 'class'.";
	console.error(errInvalidOverloads);
	errors.push(errInvalidOverloads);
	return {operations: operations, count: 0, errors: errors, errorCount: errors.length};
	}
	// If only class is specified (no method/methods/overloads), hook all methods
	if (!hook.method && (!hook.methods || hook.methods.length === 0) &&
	(!hook.overloads || hook.overloads.length === 0)) {

[Diolor]

fyi I have cleaned up and optimised this method in this PR. So we might have conflicts
https://github.com/cpholguera/frooky/pull/11/changes#diff-b86f398903cad8f58ed73e2143f1c7f5d043c6a83d25f1a51e529e87fdae9091R373-R488

[cpholguera]

Thanks and no worries, if necessary we can close mine in favor of yours after we clarify all API changes we want to do and how (hook all methods from class, add overloads for multiple methods, etc.). For now, I'll stop working on this one until TypeScript is ready.

[cpholguera]

We may need some fixes, because currently it's not fully intuitive:

• if a user explicitly specifies methods: [] this must produce an error, if the user wants to hoook all methods they must enter the class but no methods/method.
• if a user specifies only class and overloads (without method or methods) this is also an error.

This makes me realize that we need to update the hooks definitions. overloads are tied to a specific method. Now having the individual definition of method and having overloads for that method works but if we have methods we currently don't have a way to associate the overloads to each method. I think we should only allow methods in plural and have something like:

[
    {
        "class": "android.app.SharedPreferencesImpl$EditorImpl",
        "methods": [
            {
                "name": "putString",
                "overloads": [
                    {
                        "args": [
                            "java.lang.String",
                            "java.lang.String"
                        ]
                    }
                ]
            },
            {
                "name": "putStringSet",
                "overloads": [
                    {
                        "args": [
                            "java.lang.String",
                            "java.util.Set"
                        ]
                    }
                ]
            }
        ]
    },
    {
        "class": "android.app.SharedPreferencesImpl$EditorImpl",
        "methods": [
            {
                "name": "putString"
            },
            {
                "name": "putStringSet"
            }
        ]
    }
]

We could keep the method+overloads option for simplicity and backward compatibility and have this new approach for more advanced hooks. It's all about balance.