A mobile command center puts essential software operations within reach
The new ASL Command Center for Android is designed for the practical moments when a platform administrator is away from a desk but needs to check whether important systems can be reached. The opening screen presents the central Command Center together with ASL Tunnel, Sentinel, Repo Runner and account-security settings. It performs lightweight availability checks when the app opens, refreshes them every sixty seconds while the screen is active, and includes a manual refresh button for an immediate second look. The result is a focused mobile operations view rather than a miniature copy of every administrative tool.
This first release is intentionally a companion. It helps an authorized staff member recognize which destination needs attention and then opens that protected destination in the device browser. Detailed service logs, customer data and infrastructure controls remain on their established protected systems. That boundary keeps the mobile feature useful without putting every privileged capability into a new application at once. Future native actions can be added only after their permission model, audit trail, error handling and recovery path have been tested.
Delivered in this update
- Direct access to the Command Center, Tunnel, Sentinel and Repo Runner
- Automatic sixty-second availability checks plus manual refresh
- Dedicated account-security link for password and factor management
- Focused staff workflow without copying private operational data onto the phone
Existing authenticator, passkey and password protections remain part of sign-in
Protected pages open in a trusted browser so the current Auto Secure Login authentication experience stays in charge of credentials and sessions. Staff can continue to use the central password, authenticator-app code and compatible passkey or security-key options already associated with the platform. The Android app does not imitate the login form, collect a password or create a separate mobile credential database. This reduces the chance that the first testing build becomes an accidental second identity system with different security rules.
The browser handoff also gives the user a visible address bar. Before entering credentials, staff should confirm that the address is autosecurelogin.com or an exact subdomain ending in .autosecurelogin.com and that the connection uses HTTPS. The app applies the same rule to every outbound destination: plain HTTP, lookalike domains, embedded usernames, nonstandard ports and malformed addresses are rejected. Automated tests cover both expected addresses and common unsafe variations so this trust boundary can be reviewed during later releases.
Delivered in this update
- Central Authelia multi-factor sign-in remains authoritative
- No password, authenticator seed or session cookie stored by the Android app
- HTTPS-only allowlist for the main domain and exact subdomains
- Tests reject lookalike hosts, user information and unexpected ports
Privacy and device safeguards are part of the first build
A mobile administration tool should not create a new cache of sensitive information simply for convenience. The testing release stores no API keys, client records, customer messages, private service logs or authentication cookies. Android backup and device-to-device transfer are disabled for the application data area, cleartext network traffic is blocked, and the operating system is asked to prevent screenshots of the app window. These choices narrow the information available if a test phone is lost, backed up to an unintended account or inspected by another application.
Availability checks request only the configured public or protected HTTPS entry points. They report a simple reachable or attention state and response time; they do not download administrative records or attempt to bypass sign-in. A protected page may respond by directing the user to authentication, which still confirms that the service path is alive without exposing its contents. This is deliberately different from full observability. Detailed CPU, memory, storage, service-state and work-queue information continues to live in the protected web Command Center.
Delivered in this update
- Cleartext traffic disabled throughout the app
- Screenshots blocked for the Android window
- Application backup and device transfer excluded
- No customer content, private logs or credentials collected
English and Spanish support are included from the start
The interface includes English and Spanish labels for its title, connection summary, service descriptions, refresh controls, privacy notice and account-security path. Android selects the appropriate language from the device settings, so a bilingual staff member can use the same install without navigating a separate website route first. This follows the broader Auto Secure Login approach of building bilingual access into product structure instead of treating Spanish as an afterthought added after release.
The application supports Android 8.0 and newer and targets the current Android platform level used by the development environment. The tested package is a staff evaluation build, not a public-store release. It has passed compilation, unit tests, Android lint, package inspection and signature verification, but it uses a development signing certificate. A production release must use an owner-controlled signing key, complete device installation checks on representative phones and document the update process before it is offered as a normal customer download.
Delivered in this update
- Native English and Spanish resources
- Android 8.0 and newer compatibility target
- Current testing package validated by build, unit-test, lint and signature checks
- Owner-controlled production signing required before broad distribution
The next mobile features will be driven by safe operational value
The staff pilot will show which mobile actions save real time. Good candidates include authenticated incident acknowledgement, maintenance reminders, deployment-status notifications and a concise view of unresolved work across the portfolio. Each feature must answer who is allowed to perform the action, how it is recorded, what happens during a lost connection and how an incorrect action can be reversed. Notifications also need careful filtering so confidential project names, user information or security details do not appear on a locked screen.
A later release may use the shared OpenID Connect client identity broker directly and call narrowly scoped Command Center APIs instead of opening every destination in a browser. That would make richer native interactions possible, but it also requires registered redirect addresses, PKCE, secure token storage, role enforcement and revocation testing. The current browser-based design provides immediate mobile usefulness while those foundations are evaluated. It is a working Android companion and a measured step toward a more capable mobile operations platform.
Delivered in this update
- Staff pilot feedback will determine the next native actions
- Potential incident, maintenance and deployment notifications
- Direct OpenID Connect integration reserved for a reviewed later phase
- Every privileged action will require roles, audit history and recovery behavior