Phone lock no longer bases only on number of attempts. Now there is a cooldown time between each attempt, starting from a third attempt.
#Auto-locking mechanism
PurePhone screen can be locked automatically due to user inactivity.
The Auto-locking mechanism is controlled by 'gs_auto_lock_time' parameter settings stored in database.
Initial value for 'gs_auto_lock_time' (units for value is ms) can be changed in image/user/db/settings_v2_002.sql.
Values lower than 1000 (<1s) are treated as 0 and thus disable auto-locking.
Auto lock action is performed only if following conditions are met:
- tethering is off
- focused application does not prevent auto-locking
#SIM PIN flow
The PIN/PUK-related flow between SIM card and PurePhone User is directed by three main entities:
Service Cellularthat is responsible for handling modem interactions in this contextApplicationsManagerthat is responsible forApplicationDesktopmanagement and reliable messaging in theService->Applicationdirection in this context.ApplicationDesktopthat is responsible forPurePhone<->Userinteractions in this context
Following document focus mainly on (above listed) entities interactions and flow. Occasionally minimal interaction with other entities (such as User or modem) is outlined.
Functional Decomposition
Basic interactions can be captured by following interfaces:
Service CellularrealizesSrvCellularMessageHandler
ApplicationsManagerrealizesAPMActions
ApplicationDesktoprealizesAppDesktopActionHandler
General flow overview
Each flow in this context consists of single action originating in ServiceCellular send with ApplicationsManager being middle-party that is responsible for appropriate action setup and optional feedback message sent directly from ApplicationDesktop to ServiceCellular via sys::Bus service.











