Every major Android version update will bring a lot of updates to the underlying mechanism, the most important and most concerned part of the user, in addition to the interface design should be "performance and endurance".
Specific to the Android 13 developer preview just released this year, the new "Front Desk Service Manager" is particularly eye-catching.
▍ Tasks, activities and services
On Android, the distinction between the front and back office is actually quite intuitive: what the user can't see is the background, and the rest can be seen is the front desk. But for those of us whose daily operations are mainly "open the app, switch multitasking, and swipe away the app card", the concept of "service" is a bit difficult to understand.
Let's take the application apart - most of the time, the interaction with us is actually just a part of the application, these different interactive interfaces we call the "active window"; in addition to the active window, the application can also run a "service" independently, according to Google's official documentation, the service is an application component that can perform long-running operations in the background without providing an interface.
Typical front-end services, including music playback, activity, location sharing, voice or video calls, and more. For foreground services, the system exposes them to the user as much as possible through the notification system.
Taking photo backup upload as an example, once the backup starts, OneDrive will pop up a notification to inform the user of the specific progress of the photo backup upload, which is a typical foreground service notification. At this time, if we cross out the active window of OneDrive in the multitasking interface, this notification will still exist and the backup will continue. The moment the backup is complete, the service comes to the end of its time and the notification is automatically eliminated.
So if you open the app in the future and coldly pop up a "Syncing..." notification, or pop up a "Optimizing Photo" notification after taking a photo, don't be surprised, this means that the system and the application collaboration is normal.
As for back-office services... Users don't even perceive which background services are running on their phones, and Google tends to let apps leave long-term background tasks to the system, just like on iOS, and need to open another article to talk about this.
Front desk services are actually quite common
▍ Why limit front desk services
Inform the user through the notification system, so that the app can get the user's attention focus to increase the priority of the run and ultimately complete the task. This is a clever approach in my opinion, and now such mechanisms have become an important means of application to ensure the completion of the task.
However, it is not difficult to see from the above introduction that the front desk service has two main characteristics:
Even if the user stops interacting with the app, it can continue to run
A notification must be displayed during execution
So another fact that combines the two is that as long as the application guarantees that notifications are displayed correctly, its foreground service will continue to run.
Therefore, if the same mechanism is abused, it is also possible to waste a lot of system resources. In the real world, all kinds of magic UI helps users "receive" notifications, not to mention, the application itself may also pop up confusing notifications (such as disguised as weather data) to ensure the continuous survival of their services. Not to mention that most users have no concept of "the application can run continuously with a notification".
In such cases, the necessary testing and discontinuation are necessary. The foreground service manager introduced by Android 13 this time has finally made up for this link.
The first step in prevention and control is naturally to list all the applications of the front-end service. Android 13's quick switch panel in the rearrangement at the same time, the bottom also has a column "front service manager", click to expand after you can see the current active application, click the corresponding "stop" button can make the application stop running, can be described as quite "fast and accurate" management method.
According to the design of Android 13 at this stage, such warning notifications for the same app will not be repeated for 30 days. In addition, not all applications will appear in the foreground service manager, system-level applications, emergency security-related applications will not appear in this list; some applications will appear in this list but do not have a "stop" button, such as activating the device owner's application, dial-up application, etc.
▍ The difference between "card slashing and killing"
In the documentation on the foreground service manager, we can also see for the first time the modern Android definition of the behavior of "swiping a card on the multitasking interface" and its actual difference from the foreground service manager.
In the early years, the black domain, the green guardian and some manufacturers' "card killing" were actually closer to the rightmost Force stop, that is, forced stop. Now enter the application management details page can still see this button, the forced stop of the application will stop all activities, generally can not start themselves, only the user manually or the rest of the application pull up to resume operation.
From this table, it can also be seen that the multitasking interface has truly become the "application running history", rather than representing the actual running state of the application. By simply removing the history and clearing the "active window", the app does not leave the RAM immediately, and theoretically can continue to retain notifications and play media.
The foreground service manager's stop button not only pauses the foreground service, but also drives the app away from RAM. It should be noted that the application is only stopped and will not be removed from the multitasking window, perhaps to facilitate the user to quickly resume the task while reducing system resource consumption.
▍ Conclusion
Reading the last two versions of the Android development guide document, the biggest feeling for me is that Google tries to let the system mechanism take over the activities of the application, service processes, etc., and does not recommend that developers handle it themselves. The practice of taking over specific behaviors by the system can not only reduce the abuse of system resources and permissions by the application, but also effectively protect the privacy of users, which should have been practiced by the next camp.
It's just that the caliber of the document at this stage is only "suggestions", and I hope that Google can implement it step by step in the future, so that the Android system can truly transform into an operating system for "human-computer interaction".
https://sspai.com/post/72283?utm_source=wechat&utm_medium=social
Author: Lu Zhongnan
Editor-in-Charge: Himself