var Android = newAndroidEvents()

type androidEvents struct {
    ActivityCreated             ApplicationEventType
    ActivityStarted             ApplicationEventType
    ActivityResumed             ApplicationEventType
    ActivityPaused              ApplicationEventType
    ActivityStopped             ApplicationEventType
    ActivityDestroyed           ApplicationEventType
    ApplicationLowMemory        ApplicationEventType
    ApplicationConfigChanged    ApplicationEventType
    WebViewDidStartNavigation   WindowEventType
    WebViewDidFinishNavigation  WindowEventType
    WebViewDidFailNavigation    WindowEventType
    WebViewReceivedError        WindowEventType
}

func newAndroidEvents() androidEvents {
    return androidEvents{
        ActivityCreated:             1259,
        ActivityStarted:             1260,
        ActivityResumed:             1261,
        ActivityPaused:              1262,
        ActivityStopped:             1263,
        ActivityDestroyed:           1264,
        ApplicationLowMemory:        1265,
        ApplicationConfigChanged:    1266,
        WebViewDidStartNavigation:   1267,
        WebViewDidFinishNavigation:  1268,
        WebViewDidFailNavigation:    1269,
        WebViewReceivedError:        1270,
    }
}

Also added JavaScript event mappings (lines 800-811 in events.go).

---
2. Build Failure: runtime.Core() Missing Arguments

File: pkg/application/application_android.go:436

Error:
not enough arguments in call to runtime.Core
have ()
want (map[string]any)

Root Cause: The runtime.Core() API was changed to require a flags parameter, but the Android implementation wasn't updated.

Fix Applied:
// Before:
runtimeJS := runtime.Core()

// After:
runtimeJS := runtime.Core(app.impl.GetFlags(app.options))

---
3. Build Failure: iosMethodNames Undefined

File: pkg/application/messageprocessor.go:199

Error:
undefined: iosMethodNames

Root Cause: messageprocessor.go references iosMethodNames for logging, but Android builds don't have this defined.

Fix Applied:
Added stub in pkg/application/messageprocessor_android.go:
// Empty iOS method names map for logging on Android
var iosMethodNames = map[int]string{}

---
4. Runtime Failure: App Crashes When Calling Go Functions

Symptom: App builds successfully but crashes when clicking the "Greet" button (which calls the Greet() Go function).

Root Cause: The handleMessageForAndroid() function was just a stub returning {"success":true} without actually processing method calls through the MessageProcessor.

Fix Applied:
Completely rewrote handleMessageForAndroid() in application_android.go (lines 635-690):

1. Added global MessageProcessor storage:
var (
    globalMessageProc    *MessageProcessor
    globalMessageProcLock sync.RWMutex
)

2. Updated platformRun() to create and store MessageProcessor:
func (a *App) platformRun() {
    messageProc := NewMessageProcessor(a.Logger)

    globalMessageProcLock.Lock()
    globalMessageProc = messageProc
    globalMessageProcLock.Unlock()

    // ... rest of initialization
}

3. Implemented proper message handling to route calls through MessageProcessor.

---
5. Runtime Failure: Message Format Handling

Symptom: Error in logs: Failed to parse message: invalid character 'w' looking for beginning of value when processing wails:runtime:ready.

Root Cause: The message handler expected ALL messages to be JSON RuntimeRequest objects, but some messages (like "wails:runtime:ready") are sent as plain strings.

Evidence from internal/runtime/runtime_android.go:12:
window._wails.invoke=function(m){
    return window.wails.invoke(typeof m==='string'?m:JSON.stringify(m));
};

This shows that messages can be either strings OR JSON objects.

Fix Applied:
Updated handleMessageForAndroid() to detect message type:
func handleMessageForAndroid(app *App, message string) string {
    // Check if this is a special string message (not JSON)
    if len(message) > 0 && message[0] != '{' {
        androidLogf("debug", "🤖 [handleMessageForAndroid] Handling special string message: %s", message)
        return `{"success":true}`
    }

    // Parse and process JSON RuntimeRequest
    var req RuntimeRequest
    if err := json.Unmarshal([]byte(message), &req); err != nil {
        // ... error handling
    }

    // Route through MessageProcessor
    result, err := messageProc.HandleRuntimeCallWithIDs(ctx, &req)

    // ... return result
}

---
Steps to Reproduce

1. Clone the Wails v3 repository at commit 4aaec93fb (v3.0.0-alpha.72)
2. Navigate to examples/android
3. Set up Android environment:
export ANDROID_HOME=~/Library/Android/sdk
export JAVA_HOME="/Applications/Android Studio.app/Contents/jbr/Contents/Home"
4. Attempt to build:
wails3 task android:package

Expected: Build succeeds and app runs correctlyActual: Build fails with compilation errors listed above

After fixing compilation errors and installing the app:
5. Click the "Greet Me!" button in the app

Expected: Go Greet() function is called and returns a greetingActual: App crashes (before message format fix)

---
Impact

These issues make the Android example completely non-functional out of the box, which could mislead developers trying to build Android apps with Wails v3.

Questions for Maintainers

1. Event System: Was the removal of events.Android intentional? If so, what's the recommended approach for Android lifecycle events?
2. Message Processing: The original Android support commit (4d8ec29fe) also had handleMessageForAndroid as a stub. Was there a complete implementation that got lost, or was Android
message handling never fully implemented?
3. API Changes: The runtime.Core() API change affected Android. Are there other platform implementations that might have similar issues?

Suggested Actions

1. Restore Android Events: Re-add the events.Android structure or update the documentation to explain the new approach for handling Android lifecycle events.
2. Update Android Implementation: Ensure all Android-specific files are updated when core APIs change (like runtime.Core()).
3. Complete Message Handling: Review and complete the message handling implementation for Android, ensuring it matches the patterns used in iOS and other platforms.
4. Add Integration Tests: Add tests that verify Android builds successfully and can execute basic Go function calls to prevent regressions.
5. Update Example Documentation: The Android example should include build prerequisites and any known limitations.