Charles support

App Name: Your App Name [e.g., Netflix]

App Link on Amazon Appstore (found through Developer Console > Actions column in App List > View on Amazon.com): Your App Link [e.g., Netflix - App on Amazon Appstore ]

Is your feature request related to a problem?

We need to perform tests on production apps and websites which do not have debugging features.

(Write your answer here.)

Describe the solution you’d like

We would like to use Charles to capture the network traffic

(Describe your proposed solution here.)

Is this a blocker? Describe alternatives you’ve considered

We cannot have clients add the Charles support in their apps.

(Write your answer here.)

Additional context

(Write your answer here.)

Hi @Amy_Sockanathan,

Thanks for reaching out!

Vega currently supports two options for monitoring network traffic:

1. Charles Proxy integration — You can configure your Vega app to route traffic through Charles by adding a proxy-config.json and root certificate to your app’s assets/raw/ directory. Full setup guide here: Monitor Network Traffic with Charles Proxy | Design and Develop Vega Apps

2. Vega Studio Network Proxy — A built-in network monitoring tool in Vega Studio that supports HTTP, HTTPS, WebSocket, XMLHttpRequest, and Media Player traffic, with breakpoint support: Monitor Traffic with Network Proxy | Design and Develop Vega Apps

Both approaches currently require bundling proxy configuration into the app at build time. Could you clarify your use case? Specifically, are you looking to capture traffic from apps you build and control, or from third-party production apps you can’t modify? This will help us better understand your needs.

Warm regards,
Aishwarya

We are not the owners of the Vega app. We certify client apps who integrate our SDKs in their apps. Hope this helps.

Also we tried Network Proxy option and it doesn’t work for us.

Hi Amy_Sockanathan,

Like amen mentioned above, both solutions need to rebuild the app with the certification. And the reason - Tools like Charles Proxy work as a “man-in-the-middle” debugger: they intercept the connection, decrypt it for inspection, then re-encrypt it before forwarding it to the server. For this to succeed, your device must trust Charles as a legitimate certificate authority.

You will need to ask the app teams for approval and provide cert files, following this doc: Monitor Network Traffic with Charles Proxy | Design and Develop Vega Apps

Hi Karl, Let me try to explain the problem. We get the apps from our clients for certification and we can’t rebuild the app. We can only test the client app and provide our approval before they go to production. Hope this helps.

Hi Amy,

I understand your request, but this is a hard limitation of Charles Proxy and network security/privacy in general; it’s not something we can just modify the Vega OS or tools to make it work. Without the proper certification from the owner team, this is more like hacking, not approving.

If you would like to dive deeper, can you provide:

  1. Why do you need to see the https traffic?
  2. Does the client app teams know that you are going to monitor their https traffic?
  3. Does your team monitor the same for other platforms? If yes, how is it done?

More detailed reason:

Fire OS 5 used to be able to use user-installed CAs, but not anymore from Fire OS 6. This change comes from Android itself, not specifically from Amazon/Fire OS. Fire OS 5 is based on Android 5 (Lollipop), and Fire OS 6 is based on Android 7 (Nougat). And Vega OS follow the same design.

In Android 7 (Nougat), Google changed the default network security behavior:

Before Android 7: Apps trusted both system CAs and user-installed CAs by default. This meant any certificate you installed at the device level was automatically trusted by all apps.

Android 7+: Apps only trust system CAs by default. User-installed certificates are no longer trusted unless the app explicitly opts in via network_security_config.xml.

The reason for this change was security. The old behavior was a risk because:

  • Any user (or malware) that could install a certificate on the device could intercept HTTPS traffic from every app.
  • Enterprise MDM solutions or malicious actors could perform man-in-the-middle attacks on all app traffic just by pushing a CA cert to the device.
  • Apps had no control over which CAs they trusted — it was entirely a device-level decision.

By making apps distrust user-installed certs by default, Android 7 gave each app control over its own trust policy. This is better from a security standpoint — an app’s encrypted traffic can’t be intercepted just because someone installed a rogue certificate on the device. The tradeoff is exactly what you’re running into: it makes legitimate debugging and traffic inspection harder, especially for apps you don’t control.