react-native-acoustic-connect-beta 19.0.21 → 19.0.23

package/CHANGELOG.md

@@ -1,3 +1,13 @@
+## 19.0.23 (2026-09-10)
+
+### Reverts
+
+* Revert "Beta ReactNativeConnect build: 18.0.36" ([609ad7d](https://github.com/aipoweredmarketer/react-native-acoustic-connect-beta/commit/609ad7d3244ec06f27dced5864d40585c5b3c9cf))
+## 19.0.22 (2026-09-10)
+
+### Reverts
+
+* Revert "Beta ReactNativeConnect build: 18.0.36" ([609ad7d](https://github.com/aipoweredmarketer/react-native-acoustic-connect-beta/commit/609ad7d3244ec06f27dced5864d40585c5b3c9cf))
 ## 19.0.21 (2026-09-09)
 
 ### Reverts

package/ConnectConfig.example.json

@@ -1,7 +1,7 @@
 {
     "Connect": {
         "AndroidNotificationIconResName": "ic_notification",
-        "AndroidVersion": "11.0.23-beta",
+        "AndroidVersion": "11.0.26-beta",
         "AppKey": "YOUR_CONNECT_APP_KEY_HERE",
         "KillSwitchUrl": "YOUR_KILL_SWITCH_URL_HERE",
         "PostMessageUrl": "YOUR_POST_MESSAGE_URL_HERE",

package/README.md

@@ -569,13 +569,22 @@ one. To turn screenshot capture off on both platforms:
   "Connect": {
     "layoutConfig": {
       "AutoLayout": {
-        "GlobalScreenSettings": { "ScreenShot": false, "CaptureScreenshotOn": 0 }
+        "GlobalScreenSettings": { "ScreenShot": false }
       }
     }
   }
 }
 ```
 
+`ScreenShot` is the cross-platform switch — set it in `layoutConfig` (or per
+platform) and both native SDKs honour it. `CaptureScreenshotOn` is a related
+but **iOS-only** key: iOS's native auto-instrumentation reads it, but on
+Android the equivalent reader has no callers, so `CaptureScreenshotOn` is
+accepted wherever you put it and does nothing there. Set it only under
+`layoutConfigIos` if you want it; leaving it out of `layoutConfigAndroid` (or
+the shared `layoutConfig`) costs nothing on Android and avoids implying it
+does something it doesn't.
+
 Put anything common in `layoutConfig` and use `layoutConfigIos` /
 `layoutConfigAndroid` only for what differs. The platform block is **deep-merged**
 over the shared one, so it refines the baseline rather than replacing it: an
@@ -584,6 +593,32 @@ rules, and every other shared value. Arrays are replaced outright rather than
 concatenated, so a platform block can shorten or clear a shared list such as
 `MaskIdList`.
 
+#### Masking is selection, then redaction — an unmatched pattern leaves data unmasked
+
+A screen rule's `Masking` block works in two independent steps: a control is
+first **selected** by a matching `MaskIdList` (control id), `MaskValueList`
+(control value), `MaskAccessibilityIdList` (accessibility id), or
+`MaskAccessibilityLabelList` (accessibility label) pattern, and only a
+*selected* control is redacted — its value, and (Connect iOS 2.1.22+ / Android
+11.0.23-beta+ only — older SDKs serialised the accessibility object verbatim
+regardless of masking) its accessibility label and hint. A control whose value
+never matches any pattern in any of the four lists is not masked in any field.
+That's by design, not a bug — but it means a client whose patterns don't
+happen to match a given value can believe that value is masked when it never
+was.
+
+Email addresses are an easy miss: they rarely match a card-number or
+`SECRET-`-style pattern, and free-text fields (bios, support messages,
+usernames) routinely contain one. For any screen that collects email
+addresses, add a pattern to `MaskValueList`:
+
+```json
+{ "MaskValueList": ["[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}"] }
+```
+
+(The `bare-workflow` and `expo` sample `ConnectConfig.example.json` already
+ship this pattern on `GlobalScreenSettings`.)
+
 When no block applies, each native SDK keeps the defaults from its own bundled
 layout config:
 
@@ -636,6 +671,54 @@ every shipped template uses. To stand layout capture down deliberately, set
 `CaptureLayoutOn: 0` on the rule instead — it is the key that means that, and it
 leaves `NumberOfWebViews` free to describe the screen.
 
+#### WebView capture on Android: prerequisites and two open limitations
+
+A screen that hosts a `react-native-webview` `WebView` has capture behaviour
+beyond the config above:
+
+- **The WebView must be scrolled on screen.** A capture only records what is
+  currently visible — the native tree-walk skips subtrees outside the
+  viewport by design. A `WebView` sitting below the fold at the default
+  scroll position yields a layout with no WebView nodes at all, which looks
+  exactly like WebView capture never engaged. Scroll it fully into view
+  before triggering (or waiting on) a capture.
+- **`GoogleWebViewEnabled`** is a top-level `Connect` key (Android only,
+  default `true`) that gates whether the SDK instruments WebViews at all:
+
+  ```json
+  { "Connect": { "GoogleWebViewEnabled": false } }
+  ```
+
+  Set to `false`, the SDK does not discover or walk into any `WebView` on the
+  screen — the rest of that screen still captures normally. It does not gate
+  anything else on this list: screen views, clicks, and non-WebView layout
+  content are unaffected either way.
+- **A discovered WebView currently drops that screen's whole layout
+  message.** Once the SDK finds a `WebView`, it waits for a DOM-capture
+  correlation id from the page before it can finish and post the layout — and
+  a React Native-hosted `WebView` never supplies one, so the wait never
+  resolves and the *entire* screen's layout message is dropped, not just the
+  WebView's portion. Confirmed present in Android Connect **11.0.23-beta**, the
+  newest published artifact at the time of writing, and in every earlier version
+  in the supported range — measured on an emulator, where a capture on a screen
+  with a visible `WebView` posted **no messages at all** for that session, since
+  the layout's queue placeholder blocks the batch it sits in. There is no
+  client-side fix; `GoogleWebViewEnabled: false` (below) avoids it by not
+  instrumenting the `WebView` in the first place. A fix exists in the native SDK
+  but is not in any published artifact yet — check the Android Connect release
+  notes for a version above 11.0.23-beta before assuming this still applies.
+- **Enabling WebView capture replaces the app's `WebViewClient`.** The native
+  SDK installs its own `WebViewClient` on that `WebView` to instrument it, in
+  place of the one `react-native-webview` had set — so callbacks such as
+  `onHttpError` and `onNavigationStateChange` on that `WebView` stop firing
+  while capture is active. Same status as the item above: present through Android
+  Connect **11.0.23-beta**, fixed in the native SDK but not yet published, and
+  the rest of the screen is unaffected either way.
+
+Both of the limitations above only occur once the SDK is instrumenting a
+`WebView`, so `GoogleWebViewEnabled: false` avoids both — at the cost of
+getting no WebView capture on that screen at all.
+
 #### Capture timing (`CaptureLayoutDelay`)
 
 `AutoLayout.GlobalScreenSettings.CaptureLayoutDelay` is how long, in

package/android/src/main/assets/ConnectAdvancedConfig.json

@@ -24,7 +24,7 @@
     "IpPlaceholder": "N/A",
     "KillSwitchAsync": true,
     "KillSwitchDelay": 300,
-    "LibraryVersion": "11.0.23-beta",
+    "LibraryVersion": "11.0.26-beta",
     "LogFullRequestResponsePayloads": true,
     "MessageTypeHeader": "WorklightHit",
     "MessageTypes": "4,5",

package/android/src/main/assets/ConnectBasicConfig.properties

@@ -1,4 +1,4 @@
-#Wed Sep 09 15:11:03 GMT 2026
+#Thu Sep 10 19:35:29 GMT 2026
 UseWhiteList=true
 PrintScreen=3
 UseRandomSample=false

package/package.json

@@ -233,7 +233,7 @@
     "source": "src/index",
     "summary": "react-native ios android tealeaf connect cxa wxca er enhanced-replay",
     "types": "./lib/typescript/src/index.d.ts",
-    "version": "19.0.21",
+    "version": "19.0.23",
     "workspaces": [
         "example",
         "Examples/bare-workflow"