Integrate WPAndroid

[jkmassel]

What?

Integrate GutenbergKit with WordPress.com (WP Android) by moving editor loading UI into GutenbergView, adding WP.com REST API namespace support, adding native CORS proxy for Android, improving HTTP logging on both platforms, and fixing falsy post ID handling.

Why?

This branch prepares GutenbergKit for use in WP Android, which requires several changes:

1. Internal loading UI: Host apps (like WP Android) shouldn't need to implement their own loading/progress/error UI — GutenbergView should manage this internally, matching how iOS already works.
2. WP.com namespace support: WP.com's REST API uses a sites/{id}/ namespace segment (e.g., /wp/v2/sites/123/posts) that RESTAPIRepository didn't support.
3. CORS proxy: The Android WebView serves pages from appassets.androidplatform.net, making every fetch() to the WordPress REST API cross-origin. A native request proxy bypasses CORS without requiring server-side changes.
4. Post ID = 0 handling: Both platforms and the JS bridge treated 0 as a valid post ID, which caused the editor to attempt fetching a non-existent post.
5. Verbose HTTP logging: Debugging integration issues requires detailed request/response logging on both iOS and Android EditorHTTPClient.

How?

Android: Move loading UI into GutenbergView (refactor)

• Changed GutenbergView from extending WebView to extending FrameLayout, containing an internal WebView plus overlay views (EditorProgressView, ProgressBar, EditorErrorView).
• Removed the EditorLoadingListener interface and all consumer-side loading UI from the demo app's EditorActivity.
• Loading states (PROGRESS → SPINNER → READY / ERROR) are managed internally with animated transitions.

Android: CORS proxy in shouldInterceptRequest

• Added proxyRequest() to GutenbergView that intercepts non-asset, non-cached requests and performs them via HttpURLConnection, bypassing CORS.
• Handles OPTIONS preflight requests with a synthetic 204 response.
• Forwards cookies from CookieManager and adds Access-Control-Allow-* headers to responses.

WP.com namespace support (iOS + Android)

• Added buildNamespacedURL() to RESTAPIRepository (Android) and equivalent logic on iOS that inserts the namespace (e.g., sites/123/) after the API version segment in REST paths.
• Added tests for namespaced URL building on both platforms.

Post ID = 0 → nil

• EditorConfiguration on both platforms now coerces postId = 0 to nil.
• JS bridge uses || instead of ?? for post.id so falsy values (0, null, undefined) fall back to -1.
• Added unit tests on both platforms.

Verbose HTTP logging (iOS + Android)

• EditorHTTPClient on both platforms now logs full request/response details (method, URL, headers, status code, body on error, WP error codes) at debug/error levels.

Other

• Updated AGP to 8.10.1 to match WP Android.
• Skip theme style loading in EditorService when themeStyles is disabled.
• Deleted unused activity_editor.xml layout file.

Testing Instructions

1. Open the Android demo app and verify the editor loads with built-in progress bar → spinner → editor transitions.
2. Verify no loading UI code is needed in the host activity.
3. Test with a WP.com site using siteApiNamespace: ["sites/{id}/"] and confirm REST API calls include the namespace.
4. Create a new post (post ID = 0) and confirm the editor renders without trying to fetch post 0.
5. Check logcat/console for detailed HTTP request/response logs during editor initialization.

Accessibility Testing Instructions

Loading states use standard Android ProgressBar and TextView components with system accessibility defaults. No custom accessibility handling was added — verify screen readers announce the progress bar and error state text.

Screenshots or screencast

N/A – no visual design changes beyond moving existing loading UI into the library.

[dcalhoun]

Thank you for implementing this! 🙇🏻‍♂️

The overarching approach looks sound to me; it's aligned with much of the current iOS implementation.

While testing, I encountered a few critical issues that I noted in inline comments. We should discuss and address those.

[dcalhoun]

I encounter plugin load failures from CORS errors when launching the editor for a WoW/Atomic site or jetpack.wpmt.co.

Plugin load failure

CORS errors

Disabling this proxy by restate the previous implementation resolves the issue.

Example revert diff

diff --git a/android/Gutenberg/src/main/java/org/wordpress/gutenberg/GutenbergView.kt b/android/Gutenberg/src/main/java/org/wordpress/gutenberg/GutenbergView.kt
index 32c10632..78ec151d 100644
--- a/android/Gutenberg/src/main/java/org/wordpress/gutenberg/GutenbergView.kt
+++ b/android/Gutenberg/src/main/java/org/wordpress/gutenberg/GutenbergView.kt
@@ -414,6 +414,8 @@ class GutenbergView : FrameLayout {
                     // Cache miss – fall through to proxy below
                 }
 
+                return super.shouldInterceptRequest(view, request)
+
                 // Proxy all other requests natively so they bypass CORS
                 // (the editor page is served from appassets.androidplatform.net,
                 // making every API call cross-origin). This doesn't use `EditorHTTPClient` because

There appears to be something off with the new proxy logic.

[dcalhoun]

This same issue appears to cause all requests to fail with CORS errors. E.g., uploading an image fails.

[dcalhoun]

Presumably, this would negate the need for server logic like Automattic/jetpack#45292. Correct?

[jkmassel]

I'd prefer to avoid requiring Jetpack for this feature to work, but WDYT?

[dcalhoun]

Yes, agreed. If we can avoid the need for Jetpack plugin code for admin-ajax support that'd be great.

However, the CORS fix is only one facet of that support. For admin-ajax support, we still must enable authenticating those requests with app passwords with the application_password_is_api_request hook we use in Automattic/jetpack#45220.

I.e., if we solve the CORS problem in the client, Jetpack is still required to enable application password authentication of admin-ajax (VideoPress only). If other plugins want that support, they need to opt in for themselves via the hook.

[dcalhoun]

Presumably, this (erroneously?) empty body is the reason image uploads fail.

From researching, it seems you cannot retrieve/pass along body values from WebResourceRequest. Is proxying mutating requests actually possible in this manner or do we need to abandon this newly added proxy?

[dcalhoun]

Claude noted this may erroneously discard duplicate headers (e.g., multiple Set-Cookie). Should we join duplicates?

[dcalhoun]

Is it feasible for us to hoist these WP.com references to host app (Wordpress and/or Demo) to keep GutenbergKit free of these references?

[dcalhoun]

For a future PR, we should likely localize strings like this in a manner similar to iOS.

GutenbergKit/ios/Sources/GutenbergKit/Sources/EditorLocalization.swift

Lines 33 to 56 in 5b66f8e

	public final class EditorLocalization {
	/// This is designed to be overridden by the host app to provide translations.
	public static var localize: (EditorLocalizableString) -> String = { key in
	switch key {
	case .showMore: "Show More"
	case .showLess: "Show Less"
	case .search: "Search"
	case .insertBlock: "Insert Block"
	case .failedToInsertMedia: "Failed to insert media"
	case .patterns: "Patterns"
	case .noPatternsFound: "No Patterns Found"
	case .insertPattern: "Insert Pattern"
	case .patternsCategoryUncategorized: "Uncategorized"
	case .patternsCategoryAll: "All"
	case .loadingEditor: "Loading Editor"
	case .editorError: "Editor Error"
	}
	}
	/// Convenience subscript for accessing localized strings.
	public static subscript(key: EditorLocalizableString) -> String {
	localize(key)
	}
	}