Pre-release validation
Testing login, onboarding, checkout, and recovery flows on controlled Android profiles before production rollout.
← Back to home
Policy
Compliance Policy
Device Changer is intended for legal testing, QA validation, and authorized security research only. This page explains the approved scope of use and the responsibilities of every customer.
Core principle
Device Changer is built for controlled Android testing environments. The product may be used only when the customer has legal authority to run the test, to access the target device or application, and to store or review the generated test evidence.
If a scenario lacks authorization, written approval, or a legitimate QA / research purpose, it falls outside the permitted scope of this product.
Allowed use
- QA and release validation on your own apps, devices, or managed test environments.
- Authorized security testing with documented permission from the app owner or system owner.
- Compatibility testing in enterprise mobile environments where the organization controls the devices and policies.
- Developer debugging and regression analysis inside an internal, lawful testing process.
Examples of acceptable scenarios
Authorized research
Running agreed integrity or anti-abuse checks when the application owner has explicitly approved the engagement.
Managed fleet testing
Validating app behavior across organization-owned devices in internal MDM, compliance, or rollout workflows.
Prohibited use
- Unauthorized access to third-party systems, apps, devices, or accounts.
- Fraud, abuse, deception, or evasion of legal restrictions, platform rules, or contractual obligations.
- Using the tool to support account takeover, payment abuse, identity abuse, or any unlawful conduct.
- Any activity that violates local law, export restrictions, data protection requirements, or internal customer policy.
Customer responsibilities
- Confirm legal authorization before any test run starts.
- Protect credentials, logs, screenshots, and other evidence collected during testing.
- Limit access to the tool to approved team members and internal workflows.
- Document the purpose, scope, and ownership of every security or QA test involving real environments.
How to stay compliant in practice
- Define the testing goal and confirm that the target belongs to you or to a client that granted permission.
- Keep written approval for security-oriented scenarios and preserve it with project notes.
- Use repeatable profiles for evidence, but store results only in approved internal systems.
- Review internal legal and security policy before expanding testing to new regions or teams.
Ask about your use case Testing workflows