Platform Basics
What is ATLAS MDM?
ATLAS MDM is a web-based Android device management platform for authorized businesses, resellers, sub resellers, and support teams. It helps manage devices, upload APKs, deploy updates, generate activation codes, organize clients, track credits, handle support tickets, and request consent-based remote support.
Who should use it?
The platform is intended for legitimate businesses that manage Android boxes, tablets, displays, or other Android devices for clients. It is not designed for hidden monitoring, unauthorized access, spyware, harassment, or any illegal use.
Accounts and Access
Can Admin see everything?
Yes. Admin has full access to accounts, resellers, sub resellers, clients, devices, APKs, activation codes, credits, tickets, logs, security flags, and agents.
Can resellers see each other?
No. Resellers should not have cross access to another reseller's clients, APKs, devices, folders, support sessions, or credit records.
Can a reseller see a sub reseller's APKs and clients?
The requested model keeps sub reseller-owned APKs and clients separate. A reseller can manage their direct sub reseller account relationship and credit requests, but should not freely access a sub reseller's private APK repository or client list unless your final business policy explicitly allows it.
Credits and Activation
How do credits work?
Credits control how many clients or devices can be activated. Admin can sell or assign credits. Resellers and sub resellers can activate clients only according to their available balance. If credits run out, they can submit a request for more credits.
What are the credit limits?
The requested model uses a minimum request of 50 credits and a maximum request of 1000 credits. Admin may adjust this policy before production launch.
What happens when an activation code expires?
The Android agent should ask the user to enter a new 6-digit code and display a message asking them to contact their provider. The panel should show the expired code and the device needing renewal.
APK Uploads and Device Commands
Can the system read package name and version from an APK?
The production backend should parse the APK manifest and signing metadata to detect package name, version, requested permissions, SDK targets, certificate information, checksum, and scan result before deployment.
Are APK uploads scanned?
Yes, the workflow should quarantine uploads and scan them before they become available. Defective or suspicious files should be rejected, and the uploader plus responsible parent account should be notified.
What commands can be sent?
Authorized users can queue actions such as APK install, APK update, APK uninstall, clear cache, reboot, sync agent, enable/disable agent, and folder-based group updates. The backend must verify ownership and permissions for every command.
Remote Support
Can support start without client approval?
No for the standard model. The device user must see an on-screen Allow/Deny prompt before screen mirroring and keyboard/mouse control begin.
What happens if abuse is detected?
If the platform or agent detects scam activity, harassment, unauthorized access, consent bypass attempts, or other illegal behavior, the remote session should stop immediately and the offending account should be blocked. Admin receives a detailed security flag and the user must open a support ticket for review.
Will strict networks block remote support?
Production remote support should use WebRTC with STUN and TURN relay fallback over TCP/TLS 443. This gives support sessions a better chance of working across office networks, firewalls, and restrictive ISPs.