Fraud lib split

[cameron-radar]

server: https://github.com/radarlabs/server/pull/7066

[Copilot]

Pull request overview

This PR extracts fraud detection functionality from the main SDK into an optional Git submodule (sdk-fraud), allowing the fraud detection module to be conditionally included based on its availability.

Changes:

• Moved IP monitoring and fraud payload collection logic from RadarVerificationManager to the optional sdk-fraud submodule
• Refactored RadarVerificationManager to use reflection to dynamically invoke fraud detection methods when the submodule is available
• Added conditional compilation support to include the fraud detection module only when the submodule is present

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
settings.gradle	Conditionally includes the sdk-fraud submodule if its build.gradle exists
sdk/src/main/java/io/radar/sdk/RadarVerificationManager.kt	Refactored to invoke fraud detection methods via reflection and removed direct IP monitoring implementation
sdk/src/main/java/io/radar/sdk/RadarApiHelper.kt	Added commented-out code for debugging local development servers
sdk/src/main/java/io/radar/sdk/RadarApiClient.kt	Added fraudPayload parameter to track method signature
sdk/build.gradle	Conditionally includes sdk-fraud dependency when the submodule is available
sdk-fraud	Added Git submodule reference to fraud detection library
example/src/main/res/xml/network_security_config.xml	Added commented-out configuration for local development server testing
.gitmodules	Configured sdk-fraud as a Git submodule

---

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

[Copilot]

The lambda passed to invoke creates a Kotlin lambda, but the reflection call expects a Function1 object. The lambda should be wrapped in an anonymous Function1 object, similar to the getFraudPayloadCallback pattern used above.

[Copilot]

Remove commented-out network security configuration containing the hardcoded IP address (192.168.68.112). Even though commented out, this presents a security concern as it documents trust anchor modifications for development purposes.

Suggested change

	<!-- For debugging local development server trackVerified -->
	<!-- Allow connections to local development server without certificate validation -->
	<!-- <domain-config cleartextTrafficPermitted="false">
	<domain includeSubdomains="true">192.168.68.112</domain>
	<trust-anchors>
	<certificates src="system"/>
	<certificates src="user"/>
	</trust-anchors>
	</domain-config> -->

[Copilot]

The submodule is pinned to the 'initial-setup' branch rather than a specific commit or stable branch like 'main'. Consider whether this development branch should be used in production code, or if it should reference a more stable branch or tag.

Suggested change

	branch = initial-setup
	branch = main

[lmeier]

we'll probably wanna commit "master"