New Features

Evaluations Module

• What - Added a new Evaluations top-level navigation module to the Android mobile application. The module includes two submenu destinations for evaluation workflows and follows existing mobile permission and navigation behavior so only authorized users can access the applicable options.
• Why - Adding Evaluations directly to the mobile navigation gives authorized users faster access to evaluation workflows while working away from a desktop computer and keeps the mobile experience aligned with the broader platform.
• How
  • Open the Main Menu.
  • Select Evaluations.
  • Choose the applicable evaluation submenu.
  • Available options are automatically controlled by the user's assigned permissions.
• Use Case - A supervisor working from an Android device can access the appropriate evaluation workflow directly from the main navigation without needing to separately navigate through the web platform.

Automatic Incident Command Template Selection

• What - Enhanced the Take Command workflow so the Android application automatically selects the Incident Command template associated with the dispatch's mapped incident type when a template is available. Manual template selection remains available when no applicable mapping exists.
• Why - Automatically loading the appropriate command template reduces setup time when establishing command and aligns the Android workflow more closely with existing web behavior.
• How
  • Open a dispatched incident.
  • Select Take Command.
  • If the incident type has a mapped Incident Command template, the application automatically selects it.
  • If no mapping is available, continue using the existing manual template selection workflow.
• Use Case - A responder taking command of a structure fire can immediately begin with the appropriate Incident Command template already selected instead of manually searching for the correct configuration.

Feature Enhancements

Map Layer Preference Permission Handling

• What - Updated map-layer preference synchronization so users without permission to modify applicable preferences no longer send restricted preference changes to the server. Users can continue interacting with supported map workflows while server-side preference updates remain governed by assigned permissions.
• Why - This enhancement ensures mobile preference behavior respects established access controls and prevents unauthorized configuration changes from being submitted.
• How
  • Continue using map-layer controls through the normal responder workflow.
  • If the user does not have permission to update the applicable preferences, restricted changes are not synchronized to the server.
  • Users with the appropriate permission continue using preference synchronization normally.
  • No additional configuration is required.
• Use Case - A responder without administrative preference permissions can interact with map features without inadvertently changing organization-managed map settings for other users.

Mobile Navigation Route Alignment

• What - Updated several Android navigation paths to match the current server-defined web routes for Pre-Plans Map, Pre-Plan List, Expiring Items, and Hydrants List.
• Why - Keeping Android navigation aligned with current server routes improves reliability and reduces the risk of outdated mobile links opening incorrect or unavailable pages.
• How
  • Access the applicable workflows through the Main Menu.
  • Navigate to Pre-Plans Map, Pre-Plan List, Expiring Items, or Hydrants List as normal.
  • The application automatically uses the updated server-aligned destination.
  • No user configuration is required.
• Use Case - A responder opening the Pre-Plan List from an Android device is taken directly to the current web destination without being affected by legacy mobile routing.

Google Places SDK Compatibility Improvements

• What - Updated the Android application's Google Places integration to replace deprecated functionality and improve compatibility with newer Google Places SDK requirements.
• Why - Maintaining compatibility with supported Google platform components helps ensure location and place-related workflows remain reliable as underlying SDK requirements evolve.
• How
  • Continue using supported address and place-related workflows normally.
  • Google Places functionality now operates using the updated integration.
  • No user action or configuration is required.
• Use Case - A responder searching for a location through a Google Places-supported workflow continues receiving expected location results while the application remains compatible with current platform requirements.

Fixes

Responder Tracking During Background Routing

• What - Fixed an issue where responder tracking could stop when the application moved to the background during an active routing workflow.
• Why - Maintaining responder location tracking during navigation is important for situational awareness and allows other users to continue seeing unit movement even when the Android application is not actively displayed.
• How
  • Start a supported routing workflow.
  • Allow the application to move to the background or switch to another application as needed.
  • Responder tracking now continues while applicable routing remains active.
  • No additional user action is required.
• Use Case - A responder starts navigation to an incident and switches to an external mapping application while traveling. Their location continues updating for users monitoring unit movement.

App Settings Menu Visibility

• What - Fixed an issue where the App Settings menu could be missing for Android users whose roles included the permission required to access it.
• Why - Users with assigned access should consistently be able to reach application settings without being blocked by incorrect menu visibility behavior.
• How
  • Open the Main Menu.
  • Users with the required permission can now see and select App Settings.
  • Users without the applicable permission continue to have the option hidden.
• Use Case - An authorized user who needs to adjust mobile application settings can access App Settings directly from the menu without requiring a role change or workaround.

Google Map View Cleanup Crash

• What - Fixed a crash that could occur in the Google Map workflow when the application attempted to clean up a map view after an expected screen element was no longer available.
• Why - Improving map lifecycle handling reduces unexpected application closures when users navigate quickly between map and non-map workflows.
• How
  • Continue opening and closing Google Map workflows normally.
  • Map cleanup now safely handles situations where associated view components are no longer available.
  • No user configuration is required.
• Use Case - A responder rapidly moving between an incident map and another application screen can do so without triggering the previously identified cleanup crash.

Chat and Account Banner Crash

• What - Fixed a crash affecting chat and account-related workflows when an expected banner title was unavailable and an error occurred during background processing.
• Why - This fix improves stability when the application encounters incomplete or unexpected message data while processing account or communication-related information.
• How
  • Continue using chat and account workflows normally.
  • The application now safely handles the affected error condition and missing banner information.
  • No additional setup is required.
• Use Case - A responder receiving a chat-related update while account information is being processed no longer experiences an application crash if supporting banner information is unavailable.

ArcGIS Map Layout Crash

• What - Fixed a null-pointer crash in the ArcGIS map workflow that could occur when the application attempted to update the layout of a map action button that was no longer available.
• Why - This correction improves map stability during view transitions and other lifecycle conditions where screen controls may already have been removed.
• How
  • Continue using ArcGIS map workflows normally.
  • Map layout updates now safely verify applicable controls before modifying them.
  • No user action is required.
• Use Case - A responder navigating away from an ArcGIS map while the interface is updating can transition screens without the application unexpectedly closing.

ArcGIS Map Button Visibility Crash

• What - Fixed an additional ArcGIS map crash that could occur when the application attempted to change the visibility of a map action button that was no longer available.
• Why - Safely handling unavailable interface controls improves reliability during rapid navigation, background transitions, and other map lifecycle events.
• How
  • Continue interacting with ArcGIS maps normally.
  • Button visibility updates are now safely handled when the related map control is unavailable.
  • No configuration changes are required.
• Use Case - A responder switching between map views and incident details no longer encounters the previously identified crash when map controls are being hidden or displayed.

Google Map Button Reference Crash

• What - Fixed a Google Map crash that could occur when the application attempted to read information from a map button after its view reference was no longer available.
• Why - This fix reduces lifecycle-related crashes and improves reliability when map views change while background interface updates are still occurring.
• How
  • Continue using Google Map workflows normally.
  • The application now verifies map button availability before accessing its information.
  • No user action is required.
• Use Case - A responder moving quickly between map and responder screens can continue working without an unexpected crash caused by a stale map control.

Dispatch List Action Button Crash

• What - Fixed a crash in the dispatch list workflow that could occur when the application attempted to activate an action button that was no longer available.
• Why - Improving view-state handling helps ensure dispatch workflows remain stable during rapid navigation and screen lifecycle changes.
• How
  • Open and interact with the Dispatch List normally.
  • Action button interactions now safely handle situations where the button is unavailable.
  • No configuration changes are required.
• Use Case - A responder moving between dispatch records while the interface is updating can continue using the incident list without encountering the previously reported crash.

Call History Screen Crash

• What - Fixed a crash in Call History caused by incorrect handling of the screen's scrolling interface.
• Why - This correction restores stable access to call history and prevents users from being unexpectedly removed from the workflow while reviewing previous incidents.
• How
  • Navigate to Call History.
  • Review and scroll through historical call information normally.
  • The corrected screen handling now prevents the identified crash.
  • No additional configuration is required.
• Use Case - A responder reviewing previous incident activity can scroll through Call History without the application unexpectedly closing.

Browser Workflow Banner Crash

• What - Fixed a browser-based workflow crash that could occur when an error was encountered while scheduling or messaging banner information was unavailable.
• Why - Web-backed workflows should remain stable even when optional banner information is missing or an underlying request returns an error.
• How
  • Continue using browser-based scheduling and messaging workflows normally.
  • The application now safely handles affected error conditions and unavailable banner titles.
  • No user action is required.
• Use Case - A user navigating a web-backed scheduling or messaging workflow can continue working even if an associated banner cannot be generated.

Additional Browser Error Handling

• What - Added additional protection for the browser-related error condition affecting background processing and unavailable scheduling or messaging banner information, ensuring all identified paths are handled consistently.
• Why - The additional safeguard closes a related crash path and improves reliability across browser-based workflows where the same underlying error can occur through more than one application flow.
• How
  • Continue using supported browser-based workflows as normal.
  • The application automatically handles the affected error conditions without terminating unexpectedly.
  • No configuration changes are required.
• Use Case - A responder accessing web-backed functionality through a different navigation path receives the same stable behavior instead of encountering a related crash variation.