WO2015196967A1 - 应用程序常驻操作系统后台的方法及装置 - Google Patents

应用程序常驻操作系统后台的方法及装置 Download PDF

Info

Publication number
WO2015196967A1
WO2015196967A1 PCT/CN2015/082075 CN2015082075W WO2015196967A1 WO 2015196967 A1 WO2015196967 A1 WO 2015196967A1 CN 2015082075 W CN2015082075 W CN 2015082075W WO 2015196967 A1 WO2015196967 A1 WO 2015196967A1
Authority
WO
WIPO (PCT)
Prior art keywords
keep
alive
host
main process
main
Prior art date
Application number
PCT/CN2015/082075
Other languages
English (en)
French (fr)
Inventor
唐炜
Original Assignee
北京奇虎科技有限公司
奇智软件（北京）有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京奇虎科技有限公司, 奇智软件（北京）有限公司 filed Critical 北京奇虎科技有限公司
Publication of WO2015196967A1 publication Critical patent/WO2015196967A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine

Definitions

  • the present invention relates to application communication technologies, and in particular, to a method and apparatus for an application resident in an operating system background.
  • the communication device provides users with convenient Internet services by installing an operating system and installing an application (App, Application) based on the installed operating system.
  • the Android operating system is an operating system applied to mobile communication devices.
  • the source code provided by Google is customized for major manufacturers.
  • the application program is an executable program installed on Android.
  • some third-party App needs to be resident in the background of the operating system due to the task running.
  • instant messaging applications it is necessary to update the latest news from the server in real time to ensure normal service.
  • electronic marketplace application it is necessary to monitor the installation and uninstallation of other applications in the communication device in the background to upload the installation and uninstallation data of the application in the communication device, thereby analyzing the user's favorite behavior characteristics.
  • LBS location based services
  • the Android operating system allows a system-level application developed by a third-party developer to reside in the operating system background (referred to as the background)
  • the operating system is modified by acquiring the root permission of the operating system on the communication device.
  • the configuration information of the /system/build.prop file can be used to implement the third-party App resident in the background of the operating system, that is, to exploit the vulnerability of the operating system configuration file to achieve background persistence.
  • the above application resides in the background of the operating system.
  • the communication device needs to have a Root function.
  • the current Root ratio is roughly 20%, the application is limited, and the applicability is not wide.
  • the Android operating system is provided with a task manager for recording the parent process corresponding to the application and directly related to the parent process.
  • the information about the memory resources occupied by the associated child process is managed by the operating system based on the Android operating system. Therefore, there are many applications running in the background of the operating system, and a large amount of memory resources are used, resulting in insufficient operating system memory resources.
  • the parent process and the child process corresponding to the third-party App built by acquiring the operating system Root permission are managed and controlled by the operating system, and the task manager is queried according to preset rules, for example, according to rules.
  • the memory resource usage or application priority kills the parent process corresponding to some applications and the child process directly associated with the parent process, thereby terminating the running of the application and reclaiming the memory resources occupied by the application.
  • the parent process corresponding to the third-party App of the station and the associated child process may be cleared by the operating system to release the memory resource; or the anti-virus software installed in the communication device is used to check the anti-virus process, the parent process corresponding to the third-party App and Child processes directly associated with the parent process may also be cleaned up.
  • the third-party App can be re-run in the background only by restarting the communication device and running the third-party App.
  • the existing application is resident in the background of the operating system, and the third-party App resident cannot be implemented because the application residing in the background is cleared when the operating system has insufficient memory resources or during the process of checking for antivirus ( For example, 24 hours) the operating system background makes the application resident in the background less reliable, which brings inconvenience to the user's normal communication service, and affects the normal operation of the user communication service, thereby reducing the user's communication service experience.
  • the process flow is cumbersome, and the time required for the application to reside in the background is longer, and the communication of the entire communication device is interrupted. It has a greater impact on the user's communication service experience.
  • the present invention has been made in order to provide a method and apparatus for an application resident resident operating system background that overcomes the above problems or at least partially solves the above problems.
  • a method for an application resident system backend comprising:
  • the main process calls a function to create a host keepalive process
  • the host keepalive process calls a function to create a keep-alive process, and after the keep-alive process is created, the keep-alive process is hosted to the operating system;
  • an apparatus for residing an application resident background comprising: a main process creation module, a host keep-alive process creation module, a keep-alive process creation module, a connection module, and a snoop processing module, among them,
  • the main process creation module is configured to receive a target application startup request, and create a main process for the target application corresponding to the target application startup request;
  • the host keepalive process creation module is configured to trigger the main process call function to create a host keepalive process
  • a keep-alive process creation module configured to trigger a host keepalive process call function to create a keep-alive process, and after the keep-alive process is created, the keep-alive process is hosted to the operating system;
  • connection module configured to establish a connection between the main process and the keep-alive process, triggering the main process and the keep-alive process to monitor each other based on the established connection;
  • the listening processing module is configured to start the closed process after the main process is monitored or the keep-alive process is closed.
  • a computer program comprising computer readable code that, when executed on a communication device, causes the communication device to perform the method of the preceding clause.
  • a computer readable medium storing the computer program described in the preceding paragraph is provided.
  • the main process creates a host keep-alive process by calling the fork function fork(), and sets the host keep-alive process.
  • the keepalive process is created by calling the fork function fork(), and after the keepalive process is created successfully, it ends its life cycle. Therefore, the user process is separated by the two-level process, and after the host keep-alive process is closed, there is no direct relationship between the main process corresponding to the same application and the keep-alive process, and the operating system or the anti-virus software is directly related.
  • the technical problem that the application can not stay in the background the process is started by the process that is not closed, so that the application can still reside in the background, which can well meet the needs of 7x24h background running.
  • the business needs of the application the benefits of improving the reliability of the application's resident background; further, the method can be used on both Root and non-Root communication devices; and, without waiting for the communication device to restart the reload configuration file
  • the operation process is relatively simple, and the time required for the application to stay in the background is short, the communication device communication is not affected, and the communication service experience of the user is improved.
  • FIG. 1 is a flowchart of a method for backing up an operating system of an application program according to an embodiment of the present invention
  • FIG. 2 is a flowchart showing a specific process of a method for residing an operating system in an application program according to an embodiment of the present invention
  • FIG. 3 is a diagram showing an apparatus structure of an application resident resident operating system in the background of the embodiment of the present invention.
  • Figure 4 shows a block diagram of a communication device for performing the method according to the invention
  • Figure 5 shows a storage unit for holding or carrying program code implementing the method according to the invention.
  • the parent process based on the fork function and the child process directly associated with the parent process are hosted in the operating system implementation application.
  • the resident background method after the application exits the foreground, the parent process running in the foreground and the child process directly associated with the parent process running in the background can still be activated, but the application residing in the background has insufficient operating system memory resources.
  • the active parent process and the child process directly associated with the parent process may be cleared, and the third-party App resident (for example, 24 hours) operating system background cannot be implemented; Restarting the load application to restart the process that is turned off resides in the background. Not only is the operation process cumbersome, it takes a long time for the application to reside in the background, and the communication of the entire communication device is interrupted.
  • the application resident operating system background can be implemented, if a process in the two processes corresponding to the application is closed by the operating system or the anti-virus software. After that, the closed process can be started in time through another process, so that the timely reactivation of the shutdown process in the background of the operating system can be ensured, so that the application corresponding to the process can be restored and resides in the background.
  • the existing parent process created by the application and the child process have a direct association relationship, when the task manager releases the memory resource, the parent process and the resources occupied by the child process having the direct association relationship are released together. Thus, the parent process and the child process are simultaneously closed, so that there is no situation in which one of the two processes corresponding to the application is closed by the operating system or the anti-virus software.
  • the fork function fork() is derived from the multi-threaded task in the operating system (OS).
  • OS operating system
  • the operating system After the application is started in the foreground, the operating system first allocates a process for the application and creates an original with the operating system.
  • the process (parent process) is almost identical to the process (child process). Among them, two processes can perform the same function or perform different functions.
  • the parent process calls the fork() function
  • the operating system first allocates resources to the new process (child process), such as storing data and code space; then copies all the resources of the original process to the new new process, of course, You can also modify the copied resources yourself after completing the fork.
  • the fork function two processes appear, one is a child process, one Is the parent process. In the child process, the fork function returns 0.
  • fork returns the process ID of the newly created child process.
  • the child process can reside in the background.
  • the lower-level child process is created for the child process by calling the fork function fork().
  • the child process becomes an orphan process, which is hosted to the operating system process, and the lower child process corresponds to the child process.
  • the task manager closes the process according to the association relationship.
  • the embodiment of the present invention can be used regardless of whether it is a Root or a non-Root communication device, and is basically not affected by anti-virus software (soft killing), and the power consumption is very low.
  • FIG. 1 shows a method flow of an application resident resident operating system background in the embodiment of the present invention. Referring to Figure 1, the process includes:
  • Step 101 Receive a target application startup request, and create a main process for the target application corresponding to the target application startup request.
  • the target application is an application that needs to be resident in the background of the operating system, for example, an instant messaging application, an electronic market application, and a location service application, wherein the instant messaging application can be QQ, WeChat, Weibo, etc.
  • the target application startup request is received by the operating system, and the operating system includes but is not limited to an Android operating system, a Linux operating system, a Symbian operating system, and the like.
  • the operating system background refers to the location where the foreground application is located in the operating system and is located in the operating system background.
  • an application that needs to be in the background of the resident operating system can be set in advance as a startup list of the communication device booting. That is, the target application is stored in a preset startup list. In this way, after the communication device starts up, it automatically triggers a target application startup request to the operating system, and the operating system acquires a preset startup list according to the received target application startup request, automatically loads the application in the startup list, and Assign the appropriate main process to each application in the startup list.
  • the user may click on the application of the resident operating system background that needs to be started after the user starts the communication device, and trigger a target application startup request to the operating system.
  • the user can select one or more applications that need to be resident in the background of the operating system according to their actual needs.
  • the process of creating a main process for the target application is a well-known technology, which is omitted here.
  • Step 102 The main process calls a function to create a host keep-alive process
  • the function is a bifurcation function.
  • the main process corresponds to the parent process
  • the host keepalive process corresponds to the child process.
  • the parent process calls the fork function to generate a child process, and the child process has the same resource as the parent process.
  • Step 103 The host keepalive process calls a fork function to create a keep-alive process, and after the keep-alive process is created, the keep-alive process is hosted to the operating system;
  • the process of the host keepalive process calling the fork function to create the keep alive process is the same as the process of the main process calling the fork function to create the host keepalive process, which is omitted here.
  • the host keep-alive process corresponds to the parent process
  • the keep-alive process corresponds to the child process
  • the state parameter identifier is set. For example, when the state parameter identifier is 1, it indicates that the process is in a normal state; when the state parameter identifier is 0, it indicates that the process is in a closed state. That is, if the process is in the closed state, the status parameter identifier corresponding to the process is automatically set to 0.
  • the peer process is configured to read the status parameter identifier corresponding to the process, so that the peer process can actively and timely know whether the end process is alive or closed during the life cycle.
  • the status parameter identifier when the status parameter identifier is 0, it indicates that the process is in a normal state; when the status parameter identifier is 1, it indicates that the process is in the closed state.
  • the keep-alive process becomes an orphan process
  • the keep-alive process that becomes an orphan process is managed to the earliest.
  • the process that forks out that is, the operating system process.
  • the user process is separated by the two-stage process, so that there is no direct relationship between the main process and the keep-alive process, thereby effectively preventing the task manager or the anti-virus software from killing the process according to the direct association relationship, and avoiding the main process. Both the keep-alive process and the keep-alive process were killed.
  • the host keep-alive process is queried, but due to the host keep-alive process Has been closed, thus, the main process is closed to release the memory resources, in the case that the subsequent keep-alive process has not been detected, the keep-alive process that has not been detected can resurrect the main process being killed, so that the main process
  • the application corresponding to the keep-alive process can still reside in the backend of the operating system.
  • the host keepalive process places itself in a closed state to host the keep alive process to the operating system.
  • putting yourself in the off state includes:
  • the host process When the host process creates the host keepalive process, it sets a life cycle for the created host keepalive process, and after the set life cycle ends, the host keepalive process is naturally closed.
  • the time required for the subsequent host keepalive process to create the keepalive process is considered, so that the set lifetime is greater than or equal to the host keeps alive. It takes time to create a keepalive process.
  • placing itself in the off state may also include:
  • the host keepalive process After receiving the keepalive process creation success message, the host keepalive process sets its own life cycle to zero.
  • the host keepalive process when the main process sets the life cycle for the created host keepalive process, the default is the maximum value set by the operating system, that is, the default life cycle is infinitely long, and the host keepalive process creates a keep-alive process, and the keep-alive process After the creation is successful, the creation success information is returned to the host keepalive process. Therefore, the host keep-alive process can set its own life cycle to zero after receiving the keep-alive process creation success information, so that the host keep-alive process naturally dies.
  • Step 104 The main process is connected to the keep-alive process, and the main process and the keep-alive process are triggered to monitor each other based on the established connection.
  • connection between the main process and the keep-alive process includes:
  • the main process creates a server socket (LocalServerSocket), and the keepalive process creates a client socket (LocalSocket);
  • the computer operating system provides an interface called a socket for the application to interact with the Transmission Control Protocol/Internet Protocol (TCP/IP).
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • the socket is used to distinguish the network communication and connection between different application processes, is the basic operation unit of the network communication supporting the TCP/IP protocol, and is the endpoint of the two-way communication between processes of different hosts, that is, Both parties of the communication can complete the communication process through the correlation function in the socket.
  • the main process and the keep-alive process use the client/server (C/S, Client/Service) mode for communication.
  • the main process creates a server-side Unix domain socket, that is, LocalServerSocket is used as a server to establish a socket listening client request, and the keep-alive process creates a client socket (LocalSocket), and the client socket runs in the keep-alive process.
  • a server socket is created as an example, and a server descriptor is used to create an existing server socket.
  • the server socket resource address dev/socket/ is specified in init.rc. ., create a socket as a server, the program code segment is as follows:
  • LocalServerSocket socket new LocalServerSocket(createFileDescriptor(fileDesc)).
  • the socket type based on the TCP/IP protocol may include: a stream socket (SOCK_STREAM), a datagram socket (SOCK_DGRAM), and a raw socket (SOCK_RAW).
  • SOCK_STREAM a stream socket
  • SOCK_DGRAM datagram socket
  • SOCK_RAW a raw socket
  • the contents of the socket include: the destination IP address of the communication, the transport layer protocol used, for example, the TCP protocol or the User Datagram Protocol (UDP), and the port number used.
  • the transport layer protocol used for example, the TCP protocol or the User Datagram Protocol (UDP)
  • UDP User Datagram Protocol
  • the server socket does not locate a specific client socket, but is in a state of waiting for a connection, and monitors the network status in real time.
  • the block code that binds the server socket address and listens to the client socket through the server socket can be as follows:
  • the client sets the connection address and establishes a connection.
  • the client socket of the keep-alive process sends a connection request, carrying the communication destination IP address, and the communication destination IP address is a server-side socket. That is, the client socket first describes the server socket that needs to be connected, writes the address and port number of the server socket, and then sends a connection request to the server-side socket.
  • the program code segment for setting the connection address can be as follows:
  • LocalSocketAddress address new LocalSocketAddress("installd", LocalSocketAddress.Namespace.RESERVED);
  • the client socket establishes a socket connection with the server socket.
  • this step when the server-side socket listens or receives the connection request sent by the client socket, responds to the request of the client socket, establishes a new thread, and sends the information of the server-side socket.
  • the keepalive process corresponding to the client socket the keepalive process confirms the socket connection. Specifically, this step includes:
  • the main process creates a keepalive process host object through the server socket, and allocates a corresponding keep alive process identifier to the keep alive process host object;
  • the main process creates and manages the keepalive process host object, and each keep-alive process host object corresponds to a keep-alive process, and has the same keep-alive process identifier as the corresponding keep-alive process.
  • the main process starts the keep-alive process by using the created keep-alive process host object, and sends a reactivation instruction to the keep-alive process, where the re-lived instruction carries the keep-alive process identifier and the main process communication interface handle;
  • the keepalive process host object provides a method for creating and starting a keep-alive process, and provides a data communication interface for sending a resurrection instruction to the keep-alive process.
  • the main process creates a new keep-alive process by calling the process creation method provided by the keep-alive process host object in a command line manner, and the command line includes the resurrection instruction.
  • the keep-alive process starts and receives a resurrection instruction from the main process
  • the keep-alive process creates a corresponding keep-alive process object through a client socket, and initializes the keep-alive process object;
  • the keep-alive process saves the command line parameters such as the keep-alive process identifier and the main process communication interface handle carried in the received resurrection instruction.
  • the keep-alive process object sends a start response message to the main process, where the start response message carries a keep-alive process communication interface handle and a keep-alive process identifier corresponding to the keep-alive process object;
  • the keep-alive process object sends an initiation response message to the main process by using Inter-Process Communication (IPC).
  • IPC Inter-Process Communication
  • the main process determines the corresponding keep-alive process host object according to the keep-alive process identifier in the start-up response message, and sets a corresponding keep-alive for the keep-alive process host object.
  • Process communication interface handle After receiving the start response message of the keep-alive process, the main process determines the corresponding keep-alive process host object according to the keep-alive process identifier in the start-up response message, and sets a corresponding keep-alive for the keep-alive process host object.
  • the keep-alive process host object in the main process has the keep-alive process communication interface handle of the corresponding keep-alive process object, and the keep-alive process also obtains the communication interface handle of the corresponding main process. Based on the obtained keep-alive process communication interface handle, the keep-alive process host object provides a communication interface for inter-process communication with the corresponding keep-alive process object, so that the main process can send data to the corresponding keep-alive process by calling the communication interface. .
  • both the main process and the keep-alive process are in the listening state, and the state of the other party is monitored.
  • the method may further include:
  • A15 the main process and the keep-alive process establish a communication channel for data transmission.
  • This step may specifically include:
  • the main process receives data from the keep-alive process through the main process communication interface handle, and sends data to the corresponding keep-alive process through the keep-alive process communication interface handle of the keep-alive process host object;
  • the keep-alive process receives data from the main process through the keep-alive process communication interface handle, and sends data to the main process through the main process communication interface handle.
  • step 105 after the main process is monitored or the keep-alive process is closed, the closed process is started.
  • the main process and the keep-alive process are each other's processes, that is, after the interception of the other process is closed, the closed process is started.
  • listening to the other party's process is closed including:
  • the first process can be either a primary process or a keep alive process.
  • the process is shut down. It may be because the operating system needs to release the memory resources and shut down the process when the memory resources are insufficient. It may also be that the anti-virus software checks and kills the process and shuts down the process. It may be other In the case of closing the process.
  • the listening component corresponding to the first process end acquires that the first process is in a closed state, and the first process is The status parameter identifier is set to 0;
  • the second process connected by the socket reads the status parameter identifier of the first process.
  • the second process is the keep-alive process; if the first process is the keep-alive process, the second process is the primary process.
  • the second process determines that the status parameter identifier of the first process is 0, and determines that the other process is closed.
  • listening to the other party's process is closed including:
  • the main process and the keep-alive process use a socket connection to listen to each other, determine that the virtual socket connection is broken, and determine that the other process is closed.
  • the socket connection is used for mutual monitoring, the power consumption is small and stable, and the error is not easy.
  • all resources of the shutdown process are further released, so that the operating system can automatically recover system resources such as memory and CPU occupied by the shutdown process.
  • the process of starting the shutdown may include:
  • the main process monitors that the keep-alive process is closed, and invokes the resurrection command to start the keep-alive process.
  • the process of starting the shutdown may further include:
  • the keep-alive process listens to the main process being closed, calls the resurrection instruction to start the main process and triggers the starting main process to execute the call fork function to create a process of the host keep-alive process, and puts itself in the off state after the main process starts successfully. .
  • the keep-alive process starts the main process in the non-Android life cycle, and uses the am command to start the main process in the linux-C process, thereby restoring the Android service, so that the application can reside in the background of the operating system.
  • FIG. 2 is a flowchart showing a specific process of a method for residing an operating system in the background of an application program according to an embodiment of the present invention. Referring to Figure 2, taking the main process as an example, the process includes:
  • Step 201 After the main process starts, the fork function is invoked to create a host keep-alive process, and a resurrection instruction is sent to the created host keep-alive process to instruct to start the keep-alive process;
  • Step 202 The host keepalive process receives the incoming resurrection instruction, and invokes the fork function to create a keep-alive process.
  • the keep-alive process is copied by calling the fork instruction in the fork function in the operating system, thereby creating a keep-alive process.
  • Step 203 the life cycle of the host keep-alive process ends, and the patient dies naturally;
  • Step 204 the main process creates a LocalServerSocket and waits for a connection
  • Step 205 the keep-alive process is connected to the main process and monitor each other;
  • the keep-alive process and the main process monitor the state of the other party, that is, read the state parameter identifier of the other party.
  • Step 206 the keep-alive process monitors that the main process is killed (closed), and invokes a resurrection instruction to revive the main process;
  • step 207 the life cycle of the keep-alive process ends and naturally dies.
  • the main process creates a host keepalive process by calling the fork function fork(), and the host keepalive process creates a keepalive process by calling the fork function fork(). And after the creation of the keep-alive process is successful, end its own life cycle. In this way, the user process is separated by the two-level process. After the host keep-alive process is closed, the keep-alive process becomes an orphan process, which is hosted to the operating system process, and there is no direct association between the main process and the keep-alive process. relationship.
  • the method of the embodiment of the present invention can be used on both the Root and non-Root communication devices, has a wide application range, and has low power consumption, thereby being lower.
  • the cost of implementing a third-party application resident in the background is especially important for applications that must be resident in the background, so that the reliability of the application resident in the background is high; further, since the main process does not exit, all resources are No change, the generated keep-alive process inherits the resources of the main process, can ensure that the keep-alive process resources are unchanged, thereby ensuring that the application runs reliably; and, when a process corresponding to the application is closed, the application can correspond to Another process is instantly revived, and there is no need to load the application through the restart of the communication device to restart the process of the closed process.
  • the operation flow is relatively simple, and the time required for the application to stay in the background is short, and the whole process is not caused.
  • the interruption of the communication of the communication device effectively improves the communication service experience of the user.
  • FIG. 3 shows the structure of an apparatus in the background of an application resident operating system according to an embodiment of the present invention.
  • the device is a communication device, including: a main process creation module, a host keep-alive process creation module, a keep-alive process creation module, a connection module, and a snoop processing module, where
  • the main process creation module is configured to receive a target application startup request, and create a main process for the target application corresponding to the target application startup request;
  • the operating system receives the target application startup request and creates a main process, including but not limited to an Android operating system, a Linux operating system, a Symbian operating system, and the like.
  • the target application is stored in a pre-set boot list.
  • the letter device automatically triggers a target application startup request to the operating system, and the operating system obtains a preset startup list according to the received target application startup request, automatically loads the application in the startup list, and is a startup list.
  • Each application in the middle is assigned the corresponding main process.
  • the host keepalive process creation module is configured to trigger the main process call function to create a host keepalive process
  • the function is a bifurcation function.
  • a keep-alive process creation module configured to trigger a host keepalive process call function to create a keep-alive process, and after the keep-alive process is created, the keep-alive process is hosted to the operating system;
  • the main process, the host keep-alive process, and the keep-alive process are provided with state parameter identifiers for indicating whether the process is in the closed state.
  • the keep-alive process creation module includes: a keep-alive process creation unit, a lifecycle setting unit, and a lifecycle operation unit (not shown), where
  • a keep-alive process creation unit for triggering a host keepalive process to call a fork function to create a keep-alive process
  • a life cycle setting unit configured to set a life cycle for the created host keepalive process
  • the life cycle running unit is configured to run the set life cycle, and after the set life cycle ends, trigger the host keep-alive process to die naturally.
  • the time required for the subsequent host keepalive process to create the keepalive process is considered, so that the set lifetime is greater than or equal to the host keepalive process.
  • the time required to create a keep-alive process is fine.
  • connection module configured to establish a connection between the main process and the keep-alive process, triggering the main process and the keep-alive process to monitor each other based on the established connection;
  • connection module includes: a connection pre-processing unit, a connection unit, and a monitoring unit (not shown), wherein
  • the connection pre-processing unit is configured to trigger the main process to create a server socket, and the keep-alive process creates a client socket; the main process binds the server socket address, and listens to the client socket through the server socket. Socket; waiting for a client socket connection;
  • connection unit configured to trigger a client socket to establish a socket connection with the server socket
  • connection unit includes: a keep alive process host object creation subunit, a startup subunit, a keep alive process startup subunit, an initialization subunit, a response subunit, and a response processing subunit, where
  • the keepalive process host object creation sub-unit is configured to trigger the main process to create a keep-alive process host object through the server socket, and assign a corresponding keep-alive process identifier to the keep-alive process host object;
  • a startup subunit configured to trigger the main process to start a keep alive process by using the created keep alive process host object, and send a reactivation instruction to the keep alive process, where the revitalization instruction carries the keep alive process identifier and the main process communication interface handle ;
  • the keep-alive process startup sub-unit is configured to trigger the keep-alive process to start and receive a resurrection instruction from the main process;
  • An initialization subunit configured to trigger the keepalive process to create a corresponding keepalive process by using a client socket An object, and initializing the keep alive process object;
  • a response sub-unit configured to trigger the keep-alive process object to send a startup response message to the main process, where the startup response message carries a keep-alive process communication interface handle and a keep-alive process identifier corresponding to the keep-alive process object;
  • the response processing sub-unit is configured to: after triggering the main process to receive the start response message of the keep-alive process, determine, according to the keep-alive process identifier in the start-up response message, the corresponding keep-alive process host object, and host the keep-alive process The object sets the corresponding keepalive process communication interface handle.
  • the connecting unit may further include:
  • a data transmission sub-unit configured to trigger the main process to receive data from the keep-alive process through the main process communication interface handle, and send data to the corresponding keep-alive process through the keep-alive process communication interface handle of the keep-alive process host object;
  • the keep-alive process receives data from the main process through the keepalive process communication interface handle, and sends data to the main process through the main process communication interface handle.
  • the monitoring unit is configured to trigger the main process and the keep-alive process to monitor each other based on the constructed connection.
  • the listener processing module is configured to start the closed process after listening to the other party's process being closed.
  • the monitoring processing module includes: a state parameter identifier setting unit, a state parameter identifier reading unit, a state parameter identifier determining unit, and a process restarting unit (not shown), wherein
  • a state parameter identifier setting unit configured to: after the first process is closed, in a closed state, the listening component corresponding to the first process end acquires the first process is in a closed state, and sets a state parameter identifier of the first process to a closed state;
  • the first process may be a main process or a keep-alive process.
  • the process is shut down. It may be because the operating system needs to release the memory resources and shut down the process when the memory resources are insufficient. It may also be that the anti-virus software checks and kills the process and shuts down the process. It may be other In the case of closing the process.
  • a status parameter identifier reading unit configured to read a status parameter identifier of the first process by using a second process of the socket connection
  • the second process is a keep alive process if the first process is a primary process; if the first process is a keep alive process, the second process is a primary process.
  • a state parameter identifier determining unit configured to determine, in the second process, that the state parameter identifier of the first process is in a closed state, and determine that the first process is closed;
  • a process restart unit that is used to start the first process.
  • the main process monitors that the keep-alive process is closed, and invokes a reactivation instruction to start the keep-alive process;
  • the keep-alive process listens to the main process being closed, calls the resurrection instruction to start the main process and triggers the starting main process to execute the call fork function to create a process of the host keep-alive process, and puts itself in the off state after the main process starts successfully. .
  • the keep-alive process starts the main process in the non-Android life cycle, and uses the am command to start the main process in the linux-C process, thereby restoring the Android service, so that the application can reside in the background of the operating system.
  • modules in the devices of the embodiments can be adaptively changed and placed in one or more devices different from the embodiment.
  • the modules or units or components of the embodiments may be combined into one module or unit or component, and further they may be divided into a plurality of sub-modules or sub-units or sub-components.
  • any combination of the features disclosed in the specification, including the accompanying claims, the abstract and the drawings, and any methods so disclosed, or All processes or units of the device are combined.
  • Each feature disclosed in this specification (including the accompanying claims, the abstract and the drawings) may be replaced by alternative features that provide the same, equivalent or similar purpose.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor may be used in practice to implement some or all of some or all of the components of the application resident operating system background device in accordance with embodiments of the present invention. All features.
  • the invention may also be embodied as a device or device program for performing some or all of the methods described herein (example For example, computer programs and computer program products).
  • Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website server, provided on a carrier signal, or provided in any other form.
  • the various component embodiments of the present invention may be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof.
  • a microprocessor or digital signal processor may be used in practice to implement some of some or all of the components of a device that implements an application resident operating system background in accordance with an embodiment of the present invention. Or all features.
  • the invention can also be implemented as a device or device program (e.g., a computer program and a computer program product) for performing some or all of the methods described herein.
  • Such a program implementing the invention may be stored on a computer readable medium or may be in the form of one or more signals. Such signals may be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.
  • Figure 4 illustrates an apparatus, such as a communication device, that can implement the background of an application resident operating system in accordance with the present invention.
  • the communication device conventionally includes a processor 410 and a computer program product or computer readable medium in the form of a memory 420.
  • the memory 420 may be an electronic memory such as a flash memory, an EEPROM (Electrically Erasable Programmable Read Only Memory), an EPROM, a hard disk, or a ROM.
  • Memory 420 has a memory space 430 for program code 431 for performing any of the method steps described above.
  • storage space 430 for program code may include various program code 431 for implementing various steps in the above methods, respectively.
  • the program code can be read from or written to one or more computer program products.
  • These computer program products include program code carriers such as hard disks, compact disks (CDs), memory cards or floppy disks.
  • Such computer program products are typically portable or fixed storage units as described with reference to FIG.
  • the storage unit may have a storage section, a storage space, and the like arranged similarly to the memory 420 in the communication device of FIG.
  • the program code can be compressed, for example, in an appropriate form.
  • the storage unit includes computer readable code 431', ie, code that can be read by a processor, such as 410, that when executed by the communication device causes the communication device to perform each of the methods described above step.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Telephonic Communication Services (AREA)
  • Information Transfer Between Computers (AREA)
  • Stored Programmes (AREA)

Abstract

一种应用程序常驻操作系统后台的方法及装置，该方法包括：接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程（101）；所述主进程调用函数创建宿主保活进程（102）；宿主保活进程调用函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统（103）；构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听（104）；在监听到主进程或保活进程被关闭后，启动被关闭的进程（105）。应用该方案，可以实现应用程序长驻留在操作系统后台。

Description

应用程序常驻操作系统后台的方法及装置 技术领域
本发明涉及应用程序通信技术，具体涉及一种应用程序常驻操作系统后台的方法及装置。
背景技术
随着互联网的普及，用户对网络通信服务的依耐性越来越强，对网络通信服务系统的稳定性、响应能力以及不间断(zero-downtime)的服务特性也有了越来越高的要求。通信设备作为承载网络通信服务的载体，通过安装操作系统，并基于安装的操作系统安装应用程序(App，Application)，从而为用户提供便捷的互联网服务。
以安卓(Android)操作系统为例，Android操作系统是一种应用于移动通信设备的操作系统，由google提供源码给各大厂商定制，应用程序是安装在Android上的可执行程序。在目前Android操作系统环境下，一些第三方App由于任务运行的需要，需要常驻在操作系统后台，例如，对于即时通讯类应用程序，需要实时从服务器更新最新消息，以保证正常服务。再例如，对于电子市场类应用程序，需要在后台监控通信设备中其他应用程序的安装、卸载情况，以上传通信设备中应用程序的安装、卸载数据，从而对用户的喜好行为特征进行分析。再例如，对于定位服务(LBS，Location Based Services)类应用程序，需要监控通信设备的地理位置信息，以实现运营商广告的精确投放。因此，如何实现第三方App常驻操作系统后台成为迫切需要解决的技术问题。
现有技术中，由于Android操作系统允许第三方开发者开发的系统级应用程序驻留操作系统后台(简称后台)，因而，通过获取通信设备上操作系统的根(Root)权限，修改操作系统中/system/build.prop文件的配置信息，可以实现第三方App在操作系统后台常驻，即利用操作系统配置文件的漏洞，从而实现后台常驻，具体流程如下：
首先，获取操作系统Root权限；接着，修改操作系统下的/system/build.prop文件的配置信息，在该build.prop文件的配置信息中加入sys.keep_App_1＝xxx.xxx.xxx，其中，xxx.xxx.xxx是第三方App包名；然后，重启动通信设备后生效，并通过分叉函数(fork)构建针对该第三方App的父进程以及与父进程直接相关联的子进程。这样，由于在操作系统下的/system/build.prop文件的配置信息加入了第三方App相关信息，使得操作系统可以对该第三方App构建的父进程以及子进程进行管理和控制，在第三方App退出操作系统后，第三方App对应的父进程和子进程仍可驻留于后台，从而实现第三方App常驻操作系统后台。
但上述应用程序常驻操作系统后台的方法，首先，需要通信设备具有Root功能， 但据不完全统计，目前Root的比率大致为20％，应用受到限制，适用性不广；其次，Android操作系统设置有任务管理器，用于记录应用程序对应的父进程以及与父进程直接相关联的子进程占用的内存资源等信息，由于基于Android操作系统中的进程是托管给操作系统的，因而，在操作系统后台运行的应用程序较多、占用大量内存资源导致操作系统内存资源不足，需要进行系统清理的情况下，由于通过获取操作系统Root权限构建的第三方App对应的父进程以及子进程由操作系统进行管理和控制，通过查询任务管理器，依据预先设置的规则，例如，按照内存资源占用量或应用程序优先级关闭(kill)一些应用程序对应的父进程以及与父进程直接相关联的子进程，从而终止该运用程序的运行，并能回收该运用程序占用的内存资源以保证操作系统的正常运行，导致驻留于后台的第三方App对应的父进程以及关联的子进程可能被操作系统清除掉以释放内存资源；或者，通信设备中安装的杀毒软件进行查杀毒的过程中，第三方App对应的父进程以及与父进程直接相关联的子进程也可能会被清除掉。在第三方App被清除掉的情况下，只有通过重新启动通信设备，并运行该第三方App，才能重新将第三方App置于后台运行方式。
由上述可见，现有应用程序常驻操作系统后台的方法，由于驻留于后台的应用程序在操作系统内存资源不足时或在查杀毒的过程中被清除掉，不能实现第三方App常驻(例如24小时)操作系统后台，使得应用程序常驻后台的可靠性较低，从而给用户的正常通信业务带来不便，并影响用户通信业务的正常进行，降低了用户的通信业务体验。而通过通信设备的重启动加载应用程序以重新启动被关掉的进程驻留后台，不仅操作流程较为繁琐，实现应用程序驻留后台所需时间较长，更会导致整个通信设备通信的中断，对用户的通信业务体验影响更大。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的应用程序常驻操作系统后台的方法及装置。
依据本发明的一个方面，提供了应用程序常驻操作系统后台的方法，该方法包括：
接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程；
所述主进程调用函数创建宿主保活进程；
宿主保活进程调用函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统；
构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听；
在监听到主进程或保活进程被关闭后，启动被关闭的进程。
根据本发明的另一个方面提供了一种应用程序常驻操作系统后台的装置，该装置包括：主进程创建模块、宿主保活进程创建模块、保活进程创建模块、连接模块以及监听处理模块，其中，
主进程创建模块，用于接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程；
宿主保活进程创建模块，用于触发主进程调用函数创建宿主保活进程；
保活进程创建模块，用于触发宿主保活进程调用函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统；
连接模块，用于构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听；
监听处理模块，用于在监听到主进程或保活进程被关闭后，启动被关闭的进程。
根据本发明的又一个方面，提供了一种计算机程序，其包括计算机可读代码，当所述计算机可读代码在通信设备上运行时，导致所述通信设备执行前项所述的方法。
根据本发明的再一个方面，提供了一种计算机可读介质，其中存储了前项所述的计算机程序。
由上述实施例可以看出，与现有技术相比，本发明的有益效果在于：
根据本发明的应用程序常驻操作系统后台的方法及装置，在操作系统为应用程序创建主进程后，主进程再通过调用分叉函数fork()创建宿主保活进程，设置宿主保活进程再通过调用分叉函数fork()创建保活进程，并在保活进程创建成功后，结束自身的生命周期。由此通过两级进程分离用户进程，在宿主保活进程被关闭后，使得同一应用程序对应的主进程与保活进程之间不存在直接关联关系，解决了操作系统或杀毒软件依据直接关联关系进行查杀导致应用程序不能常驻后台的技术问题，取得了通过未被关闭的进程来启动关闭的进程，从而使得应用程序仍可以驻留在后台，可以很好地满足必须要7x24h后台运行的应用程序的业务需求、提升应用程序常驻后台的可靠性的有益效果；进一步地，该方法不管在Root还是非Root的通信设备上都能使用；而且，无需等待通信设备重启动重新加载配置文件以使得进程常驻，操作流程较为简单，实现应用程序驻留后台所需时间短，不影响通信设备通信，提升了用户的通信业务体验。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普 通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
图1示出了本发明实施例应用程序常驻操作系统后台的方法流程；
图2示出了本发明实施例应用程序常驻操作系统后台的方法具体流程；
图3示出了本发明实施例应用程序常驻操作系统后台的装置结构；
图4示出了用于执行根据本发明的方法的通信设备的框图；以及
图5示出了用于保持或者携带实现根据本发明的方法的程序代码的存储单元。
具体实施例
下面结合附图和具体的实施方式对本发明作进一步的描述。现有通过获取操作系统根权限，然后修改操作系统中/system/build.prop文件的配置信息，使得基于fork函数构建的父进程和与父进程直接相关联的子进程托管于操作系统实现应用程序常驻后台的方法，在应用程序退出前台后，前台运行的父进程以及后台运行的与父进程直接关联的子进程仍可处于激活状态，但驻留于后台的应用程序在操作系统内存资源不足时或在查杀毒的过程中，处于激活状态的父进程以及与父进程直接关联的子进程可能被清除掉，不能实现第三方App常驻(例如24小时)操作系统后台；而通过通信设备的重启动加载应用程序以重新启动被关掉的进程驻留后台，不仅操作流程较为繁琐，实现应用程序驻留后台所需时间较长，更会导致整个通信设备通信的中断。
由于应用程序通过fork函数创建父进程以及与父进程直接关联的子进程，可以实现应用程序常驻操作系统后台，如果能在应用程序对应的两进程中的一进程在被操作系统或杀毒软件关闭后，能够通过另一进程及时地启动关闭的进程，这样，可以确保关闭进程在操作系统后台的及时复活，使得进程对应的应用程序可以恢复并驻留在后台。但由于现有为应用程序创建的父进程以及子进程之间存在直接关联关系，因而，在任务管理器释放内存资源时，会将父进程以及存在直接关联关系的子进程占用的资源一同释放，从而使得父进程以及子进程同时被关闭，使得不存在应用程序对应的两进程中的一进程被操作系统或杀毒软件关闭的情形。
分叉函数fork()源于操作系统(OS，Operation System)中多线程任务的需要，应用程序在前台启动后，操作系统首先为该应用程序分配进程，并通过操作系统调用，创建一个与原进程(父进程)几乎完全相同的进程(子进程)。其中，两个进程可以执行完全相同的功能，也可以执行不同的功能。当父进程调用fork()函数后，操作系统先给新的进程(子进程)分配资源，例如存储数据和代码的空间；然后将原进程的所有资源都复制到新的新进程中，当然，在完成fork之后也可以自行修改被复制的资源。这样，在fork函数执行完毕后，出现两个进程，一个是子进程，一 个是父进程。在子进程中，fork函数返回0，在父进程中，fork返回新创建子进程的进程ID。因而，在应用程序退出后，子进程可以驻留在后台。
本发明实施例中，考虑操作系统通过调用分叉函数fork()为父进程创建子进程后，再通过调用分叉函数fork()为子进程创建下级子进程。这样，父进程与下级子进程之间不存在直接关联关系，在子进程被关闭后，则下级子进程成为孤儿进程，从而会被托管给操作系统进程，而由于下级子进程与子进程都对应同一应用程序，因而，后续使用中，在系统内存资源不足或杀毒软件在查杀毒过程中，由于父进程与下级子进程不存在直接关联关系，因而，在任务管理器依据关联关系进行进程关闭处理时，两个进程被操作系统同时清除或被杀毒软件同时查杀的概率较低，这样，可以通过未被关闭的进程来启动关闭的进程，从而使得父进程与下级子进程可以驻留在后台，从而保障应用程序在后台持续运行，可以很好地满足必须要7x24h后台运行的(第三方)应用程序的业务需求。相比采用Root的技术方案，本发明实施例不管在Root还是非Root的通信设备上都能使用，基本不受杀毒软件(杀软)影响，而且功耗很低。
图1示出了本发明实施例应用程序常驻操作系统后台的方法流程。参见图1，该流程包括：
步骤101，接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程；
本步骤中，目标应用程序为需要常驻操作系统后台的应用程序，例如，即时通讯类应用程序、电子市场类应用程序以及定位服务类应用程序等，其中，即时通讯类应用程序可以是QQ、微信、微博等。
本发明实施例中，作为可选实施例，由操作系统接收目标应用程序启动请求，操作系统包括但不限于安卓操作系统、Linux操作系统、塞班操作系统等。
本发明实施例中，操作系统后台是指前台应用程序在关闭后，驻留在操作系统中所处的位置为操作系统后台。
实际应用中，可以预先将需要常驻操作系统后台的应用程序设置为通信设备开机启动的启动列表中。即所述目标应用程序存储在预先设置的启动列表中。这样，在通信设备每次启动后，自动触发向操作系统发起目标应用程序启动请求，操作系统根据接收的目标应用程序启动请求，获取预先设置的启动列表，自动加载启动列表中的应用程序，并为启动列表中的各应用程序分配相应的主进程。
当然，作为可选实施例，也可以是由用户在启动通信设备后，点击需要启动的常驻操作系统后台的应用程序，触发向操作系统发起目标应用程序启动请求。这样，用户可以根据自身实际需要，选取需要常驻操作系统后台的一个或多个应用程序。
本发明实施例中，为目标应用程序创建主进程的流程为公知技术，在此略去详述。
步骤102，所述主进程调用函数创建宿主保活进程；
本步骤中，作为可选实施例，函数为分叉函数。对于主进程和宿主保活进程，主进程对应父进程，宿主保活进程对应子进程。
本发明实施例中，父进程调用fork函数产生子进程，子进程具有与父进程相同的资源。
步骤103，宿主保活进程调用分叉函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统；
本步骤中，宿主保活进程调用分叉函数创建保活进程的流程与主进程调用分叉函数创建宿主保活进程的流程相同，在此略去详述。
本发明实施例中，对于宿主保活进程和保活进程，宿主保活进程对应父进程，保活进程对应子进程。
在主进程、宿主保活进程以及保活进程中，设置有状态参数标识，例如，当状态参数标识为1时，表示进程处于正常状态；当状态参数标识为0时，表示进程处于关闭状态。也就是说，如果进程处于关闭状态，则该进程对应的状态参数标识被自动设置为0。这样，后续应用中，对端进程通过读取该进程对应的状态参数标识，使得所述对端进程在生命周期内能够主动地，及时知道该端进程是否存活或被关闭。当然，实际应用中，也可以设置当状态参数标识为0时，表示进程处于正常状态；当状态参数标识为1时，表示进程处于关闭状态。
本发明实施例中，以Linux操作系统为例，在Linux操作系统上，当宿主保活进程被关闭，保活进程变成孤儿进程，同时，变为孤儿进程的保活进程会被托管给最早fork出来的进程，即操作系统进程。这样，通过两级进程分离用户进程，可以使得主进程与保活进程之间不存在直接关联关系，从而可以有效防止任务管理器或杀毒软件依据直接关联关系对进程进行查杀时，避免主进程与保活进程都被查杀。也就是说，例如，任务管理器或杀毒软件在查杀到主进程并需要清除主进程时，依据存储的该主进程的直接关联关系，查询到宿主保活进程，但由于该宿主保活进程已被关闭，因而，将主进程关闭以释放内存资源，在后续保活进程没有被查杀到的情况下，未被查杀到的保活进程可以复活被查杀的主进程，使得主进程和保活进程对应的应用程序仍可驻留于操作系统后台。
作为可选实施例，所述宿主保活进程将自身置于关闭状态，以使所述保活进程托管给操作系统。
其中，将自身置于关闭状态包括：
主进程在创建宿主保活进程时，为创建的所述宿主保活进程设置生命周期，在设置的生命周期结束后，所述宿主保活进程自然关闭。
本步骤中，主进程在为创建的所述宿主保活进程设置生命周期时，考虑后续宿主保活进程创建保活进程所需的时间，使得设置的生命周期大于或等于宿主保活进 程创建保活进程所需的时间即可。
作为另一可选实施例，将自身置于关闭状态也可以包括：
宿主保活进程在接收到保活进程创建成功信息后，将自身的生命周期置零。
本步骤中，主进程在为创建的所述宿主保活进程设置生命周期时，默认为操作系统设置的最大值，即默认生命周期为无限长，宿主保活进程创建保活进程，保活进程在创建成功后，向宿主保活进程返回创建成功信息。因而，可以设置宿主保活进程在接收到保活进程创建成功信息后，将自身的生命周期置零，以使宿主保活进程自然死亡。
步骤104，构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听；
本步骤中，作为可选实施例，构建主进程与保活进程连接包括：
A11，主进程创建服务端套接字(LocalServerSocket)，保活进程创建客户端套接字(LocalSocket)；
本步骤中，在基于多个传输控制协议(TCP，Transmission Control Protocol)进行连接或存在多个应用程序进程的情况下，可能需要通过同一个TCP协议端口传输数据。为了区别不同的应用程序进程和连接，计算机操作系统为应用程序与传输控制协议/网际协议(TCP/IP，Transfer Control Protocol/Internet Protocol)交互提供了称为套接字(Socket)的接口。其中，套接字用于区分不同应用程序进程间的网络通信和连接，是支持TCP/IP协议的网络通信的基本操作单元，是不同主机之间的进程进行双向通信的端点，也就是说，通信的两方可以通过套接字中的相关函数来完成通信过程。
本发明实施例中，主进程与保活进程采用客户端/服务端(C/S，Client/Service)模式进行通信。主进程创建服务器端Unix域套接字，即LocalServerSocket作为服务端使用，建立socket监听客户端请求，保活进程创建客户端套接字(LocalSocket)，客户端套接字运行在保活进程中。
本发明实施例中，以创建服务端套接字为例，采用文件描述符创建已经存在的服务端套接字，例如，在init.rc中指定服务端套接字资源地址dev/socket/......，创建作为服务端的套接字，程序代码段如下：
LocalServerSocket socket＝new LocalServerSocket(createFileDescriptor(fileDesc))。
作为可选实施例，本发明实施例中，基于TCP/IP协议的套接字类型可以包括：流套接字(SOCK_STREAM)、数据报套接字(SOCK_DGRAM)以及原始套接字(SOCK_RAW)。关于套接字类型为公知技术，在此略去详述。
套接字内容包括：通信的目的IP地址、使用的传输层协议，例如，TCP协议或用户数据报协议(UDP，User Datagram Protocol)，以及使用的端口号。
A12，绑定服务端套接字地址，并通过服务端套接字监听客户端套接字；
本步骤中，服务端套接字不定位具体的客户端套接字，而是处于等待连接的状态，并实时监控网络状态。
绑定服务端套接字地址，并通过服务端套接字监听客户端套接字的程序段代码可以如下：
//绑定地址
localAddress＝new LocalSocketAddress(name)；
impl.bind(localAddress)；
//监听
impl.listen(LISTEN_BACKLOG)；
A13，等待客户端套接字连接；
本步骤中，客户端设置连接地址，并建立连接。具体来说，保活进程的客户端套接字发送连接请求，携带通信目的IP地址，该通信目的IP地址为服务器端套接字。也就是说，客户端套接字首先描述需要连接的服务器套接字，写入服务器套接字的地址和端口号，然后再向服务器端套接字发送连接请求。
设置连接地址的程序代码段可以如下：
LocalSocketAddress address＝new LocalSocketAddress(″installd″，LocalSocketAddress.Namespace.RESERVED)；
/建立连接
mSocket.connect(address)；
A14，客户端套接字与服务端套接字建立套接字连接。
本步骤中，当服务器端套接字监听或接收到客户端套接字发送的连接请求后，响应客户端套接字的请求，建立一个新的线程，并将服务器端套接字的信息发送给客户端套接字对应的保活进程，保活进程确认该套接字连接。具体来说，该步骤包括：
A01，主进程通过服务端套接字创建保活进程宿主对象，并为所述保活进程宿主对象分配对应的保活进程标识；
本步骤中，主进程创建并管理保活进程宿主对象，每个保活进程宿主对象对应一个保活进程，并拥有与所对应保活进程相同的保活进程标识。
A02，主进程使用创建的保活进程宿主对象启动保活进程，并向所述保活进程发送复活指令，所述复活指令携带所述保活进程标识、主进程通信接口句柄；
本步骤中，保活进程宿主对象中提供了创建和启动保活进程的方法，并提供数据通信接口用于向保活进程发送复活指令。具体来说，主进程以命令行的方式通过调用保活进程宿主对象提供的进程创建方法创建一个新的保活进程，所述命令行包括所述复活指令。
A03，保活进程启动并接收来自主进程的复活指令；
A04，所述保活进程通过客户端套接字创建对应的保活进程对象，并初始化所述保活进程对象；
本步骤中，在初始化过程中，保活进程对接收到的复活指令中携带的保活进程标识、主进程通信接口句柄等命令行参数进行保存。
A05，所述保活进程对象向所述主进程发送启动应答消息，所述启动应答消息携带所述保活进程对象对应的保活进程通信接口句柄、保活进程标识；
本步骤中，完成初始化后，保活进程对象使用进程间通信(IPC，Inter-Process Communication)向主进程发送启动应答消息。
A06，主进程收到保活进程的启动应答消息后，根据所述启动应答消息中的保活进程标识确定对应的保活进程宿主对象，并为所述保活进程宿主对象设置对应的保活进程通信接口句柄。
这样，主进程中的保活进程宿主对象就拥有了与其对应的保活进程对象的保活进程通信接口句柄，而保活进程也获得了对应主进程的通信接口句柄。基于获得的保活进程通信接口句柄，保活进程宿主对象对外提供与对应的保活进程对象进行进程间通信的通信接口，使得主进程能够通过调用所述通信接口向对应的保活进程发送数据。
在建立套接字连接后，主进程与保活进程都处于监听状态，监听对方的状态。
进一步地，在建立套接字连接后，该方法还可以进一步包括：
A15，主进程和保活进程建立通信通道进行数据传输。
该步骤可以具体包括：
所述主进程通过主进程通信接口句柄接收来自保活进程的数据，并通过保活进程宿主对象的保活进程通信接口句柄向对应的保活进程发送数据；
所述保活进程通过保活进程通信接口句柄接收来自主进程的数据，并通过主进程通信接口句柄向主进程发送数据。
步骤105，在监听到主进程或保活进程被关闭后，启动被关闭的进程。
本步骤中，主进程和保活进程互为对方进程，也就是在监听到对方进程被关闭后，启动被关闭的进程。
作为可选实施例，监听到对方进程被关闭包括：
B11，第一进程被关闭，处于关闭状态；
本步骤中，第一进程既可以是主进程，也可以是保活进程。进程被关闭，可能是由于操作系统在内存资源不足时，需要释放内存资源而将该进程关闭；也可能是杀毒软件在查杀毒过程中，查杀该进程而将该进程关闭；还可能是其它情形下关闭进程。
B12，第一进程端对应的监听组件获取该第一进程处于关闭状态，将第一进程 的状态参数标识设置为0；
B13，通过套接字连接的第二进程读取第一进程的状态参数标识；
本步骤中，如果第一进程为主进程，则第二进程为保活进程；如果第一进程为保活进程，则第二进程为主进程。
B14，第二进程确定第一进程的状态参数标识为0，确定对方进程被关闭。
作为另一可选实施例，监听到对方进程被关闭包括：
主进程和保活进程使用套接字连接互相监听，确定虚拟套接字连接断开，确定对方进程被关闭。
本发明实施例中，采用套接字连接进行互相监听，功耗小且稳定，不易出错。
较佳地，操作系统或杀毒软件关闭进程后，进一步释放所述关闭进程的所有资源，从而使得操作系统可自动回收该关闭进程占用的内存、CPU等系统资源。
作为可选实施例，在监听到对方进程被关闭后，启动关闭的进程可以包括：
主进程监听到保活进程被关闭，调用复活指令启动保活进程。
作为另一可选实施例，在监听到对方进程被关闭后，启动关闭的进程还可以包括：
保活进程监听到主进程被关闭，调用复活指令启动主进程并触发启动的主进程执行所述调用分叉函数创建宿主保活进程的流程，并在主进程启动成功后将自身置于关闭状态。
本步骤中，为避免复活的主进程通过创建宿主保活进程，并传入复活指令创建保活进程，使得操作系统存在冗余的保活进程，从而占用不必要的操作系统内存。因而，当保活进程启动主进程后，结束自身的生命周期，退出操作系统后台。
较佳地，保活进程在非Android生命周期内启动主进程，并使用am指令在linux-C进程启动主进程，从而恢复Android的服务，使得应用程序可以驻留在操作系统后台。
图2示出了本发明实施例应用程序常驻操作系统后台的方法具体流程。参见图2，以主进程被关闭为例，该流程包括：
步骤201，主进程启动后，调用fork函数创建宿主保活进程，并向创建的宿主保活进程传入复活指令，指示启动保活进程；
步骤202，宿主保活进程接收传入的复活指令，调用fork函数创建保活进程；
本步骤中，通过调用操作系统中的fork函数中的fork指令，复制出保活进程，从而创建出保活进程。
步骤203，宿主保活进程生命周期结束，自然死亡；
本步骤中，在生命周期结束后，宿主保活进程关闭自己。
步骤204，主进程创建LocalServerSocket并等待连接；
步骤205，保活进程连接到主进程，并互相监听；
本步骤，保活进程与主进程监听对方的状态，即读取对方的状态参数标识。
步骤206，保活进程监听到主进程被杀死(关闭)，调用复活指令复活主进程；
本步骤中，保活进程监听到与主进程的连接断开，则调用复活指令复活主进程，返回执行步骤201。
步骤207，保活进程生命周期结束，自然死亡。
本步骤中，当保活进程的生命周期结束时，退出操作系统后台，以避免复活的主进程通过创建宿主保活进程，并传入复活指令创建保活进程，使得操作系统存在冗余的保活进程，从而占用不必要的操作系统内存。
本发明实施例中，操作系统为应用程序创建主进程后，主进程再通过调用分叉函数fork()创建宿主保活进程，宿主保活进程再通过调用分叉函数fork()创建保活进程，并在保活进程创建成功后，结束自身的生命周期。这样，通过两级进程分离用户进程，在宿主保活进程被关闭后，则保活进程成为孤儿进程，从而会被托管给操作系统进程，并使得主进程与保活进程之间不存在直接关联关系。因而，后续应用中，在主进程和保活进程中的一个进程被关闭的情况下，由于主进程与保活进程不存在直接关联关系，使得依据直接关联关系进行查杀的另一个进程被同时关闭的概率较低，这样，可以通过未被关闭的进程来启动关闭的进程，从而使得应用程序仍可以驻留在后台，可以很好地满足必须要7x24h后台运行的应用程序的业务需求。相比采用Root(即获得超级管理员权限)的技术方案，本发明实施例的方法不管在Root还是非Root的通信设备上都能使用，适用范围广，而且功耗很低，从而以较低的代价实现第三方应用程序常驻后台运行，对于那些必须常驻后台的软硬结合的应用尤其重要，使得应用程序常驻后台的可靠性高；进一步地，由于主进程没有退出，所有资源均没有变化，产生的保活进程继承主进程的资源，可以确保保活进程资源不变，从而确保应用程序可靠运行；而且，在应用程序对应的一进程被关闭时，可以通过该应用程序对应的另一进程即时复活，无需通过通信设备的重启动加载应用程序以重新启动被关掉的进程驻留后台，不仅操作流程较为简单，实现应用程序驻留后台所需时间短，更不会导致整个通信设备通信的中断，有效提升了用户的通信业务体验。
图3示出了本发明实施例应用程序常驻操作系统后台的装置结构。参见图3，该装置为通信设备，包括：主进程创建模块、宿主保活进程创建模块、保活进程创建模块、连接模块以及监听处理模块，其中，
主进程创建模块，用于接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程；
本发明实施例中，操作系统接收目标应用程序启动请求，并创建主进程，包括但不限于安卓操作系统、Linux操作系统、塞班操作系统等。
作为可选实施例，将目标应用程序存储在预先设置的启动列表中。这样，在通 信设备每次启动后，自动触发向操作系统发起目标应用程序启动请求，操作系统根据接收的目标应用程序启动请求，获取预先设置的启动列表，自动加载启动列表中的应用程序，并为启动列表中的各应用程序分配相应的主进程。
宿主保活进程创建模块，用于触发主进程调用函数创建宿主保活进程；
本发明实施例中，函数为分叉函数。
保活进程创建模块，用于触发宿主保活进程调用函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统；
本发明实施例中，主进程、宿主保活进程以及保活进程设置有用于表示进程是否处于关闭状态的状态参数标识。
作为可选实施例，保活进程创建模块包括：保活进程创建单元、生命周期设置单元以及生命周期运行单元(图中未示出)，其中，
保活进程创建单元，用于触发宿主保活进程调用分叉函数创建保活进程；
生命周期设置单元，用于为创建的所述宿主保活进程设置生命周期；
生命周期运行单元，用于运行设置的生命周期，在设置的生命周期结束后，触发所述宿主保活进程自然死亡。
本发明实施例中，主进程在为创建的所述宿主保活进程设置生命周期时，考虑后续宿主保活进程创建保活进程所需的时间，使得设置的生命周期大于或等于宿主保活进程创建保活进程所需的时间即可。
连接模块，用于构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听；
作为可选实施例，连接模块包括：连接预处理单元、连接单元以及监听单元(图中未示出)，其中，
连接预处理单元，用于触发主进程创建服务端套接字，保活进程创建客户端套接字；使主进程绑定服务端套接字地址，并通过服务端套接字监听客户端套接字；等待客户端套接字连接；
连接单元，用于触发客户端套接字与服务端套接字建立套接字连接；
本发明实施例中，连接单元包括：保活进程宿主对象创建子单元、启动子单元、保活进程启动子单元、初始化子单元、应答子单元以及应答处理子单元，其中，
保活进程宿主对象创建子单元，用于触发主进程通过服务端套接字创建保活进程宿主对象，并为所述保活进程宿主对象分配对应的保活进程标识；
启动子单元，用于触发主进程使用创建的保活进程宿主对象启动保活进程，并向所述保活进程发送复活指令，所述复活指令携带所述保活进程标识、主进程通信接口句柄；
保活进程启动子单元，用于触发保活进程启动并接收来自主进程的复活指令；
初始化子单元，用于触发所述保活进程通过客户端套接字创建对应的保活进程 对象，并初始化所述保活进程对象；
应答子单元，用于触发所述保活进程对象向所述主进程发送启动应答消息，所述启动应答消息携带所述保活进程对象对应的保活进程通信接口句柄、保活进程标识；
应答处理子单元，用于触发主进程收到保活进程的启动应答消息后，根据所述启动应答消息中的保活进程标识确定对应的保活进程宿主对象，并为所述保活进程宿主对象设置对应的保活进程通信接口句柄。
作为可选实施例，连接单元还可以进一步包括：
数据传输子单元，用于触发所述主进程通过主进程通信接口句柄接收来自保活进程的数据，并通过保活进程宿主对象的保活进程通信接口句柄向对应的保活进程发送数据；所述保活进程通过保活进程通信接口句柄接收来自主进程的数据，并通过主进程通信接口句柄向主进程发送数据。
监听单元，用于触发所述主进程与保活进程基于构建的连接进行相互监听。
监听处理模块，用于在监听到对方进程被关闭后，启动关闭的进程。
本发明实施例中，监听处理模块包括：状态参数标识设置单元、状态参数标识读取单元、状态参数标识确定单元以及进程重启动单元(图中未示出)，其中，
状态参数标识设置单元，用于在第一进程被关闭，处于关闭状态后，第一进程端对应的监听组件获取该第一进程处于关闭状态，将第一进程的状态参数标识设置为关闭状态；
本发明实施例中，第一进程既可以是主进程，也可以是保活进程。进程被关闭，可能是由于操作系统在内存资源不足时，需要释放内存资源而将该进程关闭；也可能是杀毒软件在查杀毒过程中，查杀该进程而将该进程关闭；还可能是其它情形下关闭进程。
状态参数标识读取单元，用于通过套接字连接的第二进程读取第一进程的状态参数标识；
本发明实施例中，如果第一进程为主进程，则第二进程为保活进程；如果第一进程为保活进程，则第二进程为主进程。
状态参数标识确定单元，用于在第二进程确定第一进程的状态参数标识为关闭状态，确定第一进程被关闭；
进程重启动单元，用于启动第一进程。
本发明实施例中，主进程监听到保活进程被关闭，调用复活指令启动保活进程；或者，
保活进程监听到主进程被关闭，调用复活指令启动主进程并触发启动的主进程执行所述调用分叉函数创建宿主保活进程的流程，并在主进程启动成功后将自身置于关闭状态。
较佳地，保活进程在非Android生命周期内启动主进程，并使用am指令在linux-C进程启动主进程，从而恢复Android的服务，使得应用程序可以驻留在操作系统后台。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的应用程序常驻操作系统后台的装置中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例 如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站服务器上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(DSP)来实现根据本发明实施例的实现应用程序常驻操作系统后台的设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
例如，图4示出了可以实现根据本发明的应用程序常驻操作系统后台的装置，例如通信设备。该通信设备传统上包括处理器410和以存储器420形式的计算机程序产品或者计算机可读介质。存储器420可以是诸如闪存、EEPROM(电可擦除可编程只读存储器)、EPROM、硬盘或者ROM之类的电子存储器。存储器420具有用于执行上述方法中的任何方法步骤的程序代码431的存储空间430。例如，用于程序代码的存储空间430可以包括分别用于实现上面的方法中的各种步骤的各个程序代码431。这些程序代码可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(CD)、存储卡或者软盘之类的程序代码载体。这样的计算机程序产品通常为如参考图5所述的便携式或者固定存储单元。该存储单元可以具有与图4的通信设备中的存储器420类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩。通常，存储单元包括计算机可读代码431’，即可以由例如诸如410之类的处理器读取的代码，这些代码当由通信设备运行时，导致该通信设备执行上面所描述的方法中的各个步骤。
本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本发明的至少一个实施例中。 此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
此外，还应当注意，本说明书中使用的语言主要是为了可读性和教导的目的而选择的，而不是为了解释或者限定本发明的主题而选择的。因此，在不偏离所附权利要求书的范围和精神的情况下，对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。对于本发明的范围，对本发明所做的公开是说明性的，而非限制性的，本发明的范围由所附权利要求书限定。

Claims (25)

  1. 一种应用程序常驻操作系统后台的方法，包括：
    接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程；
    所述主进程调用函数创建宿主保活进程；
    宿主保活进程调用函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统；
    构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听；
    在监听到主进程或保活进程被关闭后，启动被关闭的进程。
  2. 如权利要求1所述的方法，所述操作系统包括但不限于安卓操作系统、Linux操作系统、塞班操作系统。
  3. 如权利要求1所述的方法，所述目标应用程序存储在预先设置的启动列表中，在通信设备每次启动后，自动触发向操作系统发起目标应用程序启动请求，操作系统根据接收的目标应用程序启动请求，获取预先设置的启动列表，自动加载启动列表中的应用程序，并为启动列表中的各应用程序分配相应的主进程。
  4. 如权利要求1所述的方法，所述宿主保活进程将自身置于关闭状态，以使所述保活进程托管给操作系统。
  5. 如权利要求4所述的方法，所述将自身置于关闭状态包括：
    主进程在创建宿主保活进程时，为创建的所述宿主保活进程设置生命周期，在设置的生命周期结束后，所述宿主保活进程自然关闭。
  6. 如权利要求4所述的方法，所述将自身置于关闭状态包括：
    宿主保活进程在接收到保活进程创建成功信息后，将自身的生命周期置零。
  7. 如权利要求1所述的方法，所述构建主进程与保活进程连接包括：
    主进程创建服务端套接字，保活进程创建客户端套接字；
    绑定服务端套接字地址，并通过服务端套接字监听客户端套接字；
    等待客户端套接字连接；
    客户端套接字与服务端套接字建立套接字连接。
  8. 如权利要求7所述的方法，所述客户端套接字与服务端套接字建立套接字连接包括：
    主进程通过服务端套接字创建保活进程宿主对象，并为所述保活进程宿主对象分配对应的保活进程标识；
    主进程使用创建的保活进程宿主对象启动保活进程，并向所述保活进程发送复活指令，所述复活指令携带所述保活进程标识、主进程通信接口句柄；
    保活进程启动并接收来自主进程的复活指令；
    所述保活进程通过客户端套接字创建对应的保活进程对象，并初始化所述保活进程对象；
    所述保活进程对象向所述主进程发送启动应答消息，所述启动应答消息携带所述保活进程对象对应的保活进程通信接口句柄、保活进程标识；
    主进程收到保活进程的启动应答消息后，根据所述启动应答消息中的保活进程标识确定对应的保活进程宿主对象，并为所述保活进程宿主对象设置对应的保活进程通信接口句柄。
  9. 如权利要求8所述的方法，所述在建立套接字连接后，所述方法进一步包括：
    所述主进程通过主进程通信接口句柄接收来自保活进程的数据，并通过保活进程宿主对象的保活进程通信接口句柄向对应的保活进程发送数据；
    所述保活进程通过保活进程通信接口句柄接收来自主进程的数据，并通过主进程通信接口句柄向主进程发送数据。
  10. 如权利要求1所述的方法，所述监听到主进程或保活进程被关闭包括：
    第一进程被关闭，处于关闭状态；
    第一进程端对应的监听组件获取该第一进程处于关闭状态，将第一进程的状态参数标识设置为0；
    通过套接字连接的第二进程读取第一进程的状态参数标识；
    第二进程确定第一进程的状态参数标识为0，确定对方进程被关闭。
  11. 如权利要求1所述的方法，所述监听到主进程或保活进程被关闭包括：
    主进程和保活进程使用套接字连接互相监听，确定虚拟套接字连接断开，确定主进程或保活进程被关闭。
  12. 如权利要求1所述的方法，所述在监听到主进程或保活进程被关闭后，启动被关闭的进程包括：
    主进程监听到保活进程被关闭，调用复活指令启动保活进程。
  13. 如权利要求1所述的方法，所述在监听到主进程或保活进程被关闭后，启动被关闭的进程包括：
    保活进程监听到主进程被关闭，调用复活指令启动主进程并触发启动的主进程执行所述调用函数创建宿主保活进程的流程，并在主进程启动成功后将自身置于关闭状态。
  14. 如权利要求12或13所述的方法，所述保活进程在非安卓生命周期内启动主进程，并使用am指令在linux-C进程启动主进程。
  15. 如权利要求1所述的方法，所述函数为分叉函数。
  16. 如权利要求1所述的方法，所述主进程与所述宿主保活进程为父子进程关系，所述宿主保活进程与所述保活进程为父子进程关系。
  17. 如权利要求1所述的方法，通过未被关闭的所述保活进程或所述主进程启 动所述被关闭的进程。
  18. 一种应用程序常驻操作系统后台的装置，该装置包括：主进程创建模块、宿主保活进程创建模块、保活进程创建模块、连接模块以及监听处理模块，其中，
    主进程创建模块，用于接收目标应用程序启动请求，为该目标应用程序启动请求对应的目标应用程序创建主进程；
    宿主保活进程创建模块，用于触发主进程调用函数创建宿主保活进程；
    保活进程创建模块，用于触发宿主保活进程调用函数创建保活进程，并在保活进程创建后，将所述保活进程托管给操作系统；
    连接模块，用于构建主进程与保活进程连接，触发所述主进程与保活进程基于构建的连接进行相互监听；
    监听处理模块，用于在监听到主进程或保活进程被关闭后，启动被关闭的进程。
  19. 如权利要求18所述的装置，所述保活进程创建模块包括：保活进程创建单元、生命周期设置单元以及生命周期运行单元，其中，
    保活进程创建单元，用于触发宿主保活进程调用函数创建保活进程；
    生命周期设置单元，用于为创建的所述宿主保活进程设置生命周期；
    生命周期运行单元，用于运行设置的生命周期，在设置的生命周期结束后，触发所述宿主保活进程自然关闭。
  20. 如权利要求18所述的装置，所述连接模块包括：连接预处理单元、连接单元以及监听单元，其中，
    连接预处理单元，用于触发主进程创建服务端套接字，保活进程创建客户端套接字；使主进程绑定服务端套接字地址，并通过服务端套接字监听客户端套接字；等待客户端套接字连接；
    连接单元，用于触发客户端套接字与服务端套接字建立套接字连接；
    监听单元，触发所述主进程与保活进程基于构建的连接进行相互监听。
  21. 如权利要求20所述的装置，所述连接单元包括：保活进程宿主对象创建子单元、启动子单元、保活进程启动子单元、初始化子单元、应答子单元以及应答处理子单元，其中，
    保活进程宿主对象创建子单元，用于触发主进程通过服务端套接字创建保活进程宿主对象，并为所述保活进程宿主对象分配对应的保活进程标识；
    启动子单元，用于触发主进程使用创建的保活进程宿主对象启动保活进程，并向所述保活进程发送复活指令，所述复活指令携带所述保活进程标识、主进程通信接口句柄；
    保活进程启动子单元，用于触发保活进程启动并接收来自主进程的复活指令；
    初始化子单元，用于触发所述保活进程通过客户端套接字创建对应的保活进程对象，并初始化所述保活进程对象；
    应答子单元，用于触发所述保活进程对象向所述主进程发送启动应答消息，所述启动应答消息携带所述保活进程对象对应的保活进程通信接口句柄、保活进程标识；
    应答处理子单元，用于触发主进程收到保活进程的启动应答消息后，根据所述启动应答消息中的保活进程标识确定对应的保活进程宿主对象，并为所述保活进程宿主对象设置对应的保活进程通信接口句柄。
  22. 如权利要求21所述的装置，所述连接单元进一步包括：数据传输子单元，用于触发所述主进程通过主进程通信接口句柄接收来自保活进程的数据，并通过保活进程宿主对象的保活进程通信接口句柄向对应的保活进程发送数据；所述保活进程通过保活进程通信接口句柄接收来自主进程的数据，并通过主进程通信接口句柄向主进程发送数据。
  23. 如权利要求18所述的装置，所述监听处理模块包括：状态参数标识设置单元、状态参数标识读取单元、状态参数标识确定单元以及进程重启动单元，其中，
    状态参数标识设置单元，用于在第一进程被关闭，处于关闭状态后，第一进程端对应的监听组件获取该第一进程处于关闭状态，将第一进程的状态参数标识设置为关闭状态；
    状态参数标识读取单元，用于通过套接字连接的第二进程读取第一进程的状态参数标识；
    状态参数标识确定单元，用于在第二进程确定第一进程的状态参数标识为关闭状态，确定第一进程被关闭；
    进程重启动单元，用于启动被关闭的第一进程。
  24. 一种计算机程序，包括计算机可读代码，当所述计算机可读代码在服务器上运行时，导致所述服务器执行根据权利要求1-17中的任一个所述的方法。
  25. 一种计算机可读介质，其中存储了如权利要求24所述的计算机程序。
PCT/CN2015/082075 2014-06-24 2015-06-23 应用程序常驻操作系统后台的方法及装置 WO2015196967A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410287640.5 2014-06-24
CN201410287640.5A CN105335171B (zh) 2014-06-24 2014-06-24 应用程序常驻操作系统后台的方法及装置

Publications (1)

Publication Number Publication Date
WO2015196967A1 true WO2015196967A1 (zh) 2015-12-30

Family

ID=54936799

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/082075 WO2015196967A1 (zh) 2014-06-24 2015-06-23 应用程序常驻操作系统后台的方法及装置

Country Status (2)

Country Link
CN (1) CN105335171B (zh)
WO (1) WO2015196967A1 (zh)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2017206884A1 (zh) * 2016-05-31 2017-12-07 广东欧珀移动通信有限公司 应用程序关闭方法、装置、存储介质及电子设备
CN109240809A (zh) * 2017-07-11 2019-01-18 阿里巴巴集团控股有限公司 进程维护管理方法、容器维护方法、装置和操作系统
CN110688319A (zh) * 2019-09-30 2020-01-14 RealMe重庆移动通信有限公司 应用保活能力测试方法及相关装置
CN110879726A (zh) * 2019-10-24 2020-03-13 深圳数位传媒科技有限公司 移动终端应用程序的保活方法及装置
US10599409B2 (en) * 2016-02-02 2020-03-24 Blackberry Limited Application lifecycle operation queueing
CN112445530A (zh) * 2019-08-29 2021-03-05 成都鼎桥通信技术有限公司 第三方应用程序保活方法及设备
CN112612589A (zh) * 2020-12-26 2021-04-06 吉林亿联银行股份有限公司 一种应用程序的保活方法及装置
US11424931B2 (en) 2016-01-27 2022-08-23 Blackberry Limited Trusted execution environment
CN115113946A (zh) * 2021-03-17 2022-09-27 广东小天才科技有限公司 一种优化相机启动方法和装置
WO2022267765A1 (zh) * 2021-06-26 2022-12-29 荣耀终端有限公司 一种视频应用的保活方法以及电子设备

Families Citing this family (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105930215A (zh) * 2016-04-07 2016-09-07 珠海市魅族科技有限公司 一种移动终端的控制方法及控制装置
CN106201690A (zh) * 2016-07-07 2016-12-07 乐视控股（北京）有限公司 应用运行控制方法及装置
CN106371911A (zh) * 2016-09-06 2017-02-01 北京海誉动想科技股份有限公司 守护进程重启被守护进程的方法
CN106775652A (zh) * 2016-11-24 2017-05-31 武汉斗鱼网络科技有限公司 对终端的应用程序进行唤醒的方法及装置
CN106775642B (zh) * 2016-11-24 2018-03-13 广州赛意信息科技股份有限公司 一种移动应用的无限后台定位方法及系统
CN106648863B (zh) * 2016-12-08 2020-01-03 武汉斗鱼网络科技有限公司 一种安卓应用安装包、应用目标进程保活方法及系统
CN107341052A (zh) * 2017-06-07 2017-11-10 努比亚技术有限公司 一种消息处理方法及装置
CN107342981B (zh) * 2017-06-07 2021-11-12 北京小鸟看看科技有限公司 传感器数据的传输方法及装置、虚拟现实头戴设备
CN107729128B (zh) * 2017-07-24 2019-09-24 深圳壹账通智能科技有限公司 应用程序数据恢复方法、装置、计算机设备和存储介质
CN107391199A (zh) * 2017-07-27 2017-11-24 珠海市魅族科技有限公司 应用启动方法及装置、终端和计算机可读存储介质
CN108287761B (zh) * 2017-08-09 2020-11-06 珠海市魅族科技有限公司 内存回收方法及装置、终端设备及计算机可读存储介质
CN108153620A (zh) * 2017-12-27 2018-06-12 深圳豪客互联网有限公司 一种进程控制方法及装置
CN109669838B (zh) * 2018-11-14 2022-05-27 百度在线网络技术（北京）有限公司 实现应用常驻的方法、装置、计算机设备及存储介质
CN109683974B (zh) * 2018-12-26 2022-05-31 北京金山安全软件有限公司 针对移动终端中应用后台服务进程的唤醒方法及相关设备
CN109992310B (zh) * 2019-03-12 2024-04-05 中国平安财产保险股份有限公司 应用程序保活方法、装置、计算机设备和存储介质
CN111782347A (zh) * 2019-04-03 2020-10-16 安克创新科技股份有限公司 手机应用保活方法、装置、系统及存储介质
CN111538541A (zh) * 2019-12-06 2020-08-14 杭州当虹科技股份有限公司 一种让Android App长期稳定后台运行的方法
CN111399924B (zh) * 2020-03-18 2023-06-16 山东车微联信息技术股份有限公司 一种安卓平台下应用进程保活的方法、终端及存储介质
CN114116040A (zh) * 2020-08-31 2022-03-01 华为技术有限公司 加速应用启动的方法、电子设备及计算机存储介质
CN112162783B (zh) * 2020-09-27 2021-09-14 珠海格力电器股份有限公司 音乐播放应用保活处理方法、系统、存储介质及电子设备
CN112860408A (zh) * 2021-03-03 2021-05-28 苏州沁游网络科技有限公司 一种云真机中的进程保活方法、装置、系统及存储介质
CN113377543A (zh) * 2021-06-28 2021-09-10 上海商汤科技开发有限公司 任务处理系统、电子设备和存储介质
CN116263718A (zh) * 2021-12-13 2023-06-16 北京有竹居网络技术有限公司 进程管理方法、装置、存储介质以及电子设备
CN114697377B (zh) * 2022-04-07 2023-09-05 深信服科技股份有限公司 一种客户端产品的保活方法、系统、装置及可读存储介质
CN114816546A (zh) * 2022-04-28 2022-07-29 合肥高维数据技术有限公司 客户端应用程序多重保活方法及系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102298538A (zh) * 2010-04-07 2011-12-28 苹果公司 机会性的多任务处理
CN102550003A (zh) * 2009-10-01 2012-07-04 瑞典爱立信有限公司 用于管理持续丰富因特网应用的方法和设备
CN103324536A (zh) * 2012-03-23 2013-09-25 宇龙计算机通信科技(深圳)有限公司 终端和应用程序保护方法
WO2013148223A1 (en) * 2012-03-29 2013-10-03 Microsoft Corporation Persistent and resilient worker processes

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8843930B2 (en) * 2012-07-10 2014-09-23 Sap Ag Thread scheduling and control framework
CN103577224A (zh) * 2013-10-21 2014-02-12 杭州魔品科技有限公司 一种提高pc端检测安卓手机端守护程序升级的方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102550003A (zh) * 2009-10-01 2012-07-04 瑞典爱立信有限公司 用于管理持续丰富因特网应用的方法和设备
CN102298538A (zh) * 2010-04-07 2011-12-28 苹果公司 机会性的多任务处理
CN103324536A (zh) * 2012-03-23 2013-09-25 宇龙计算机通信科技(深圳)有限公司 终端和应用程序保护方法
WO2013148223A1 (en) * 2012-03-29 2013-10-03 Microsoft Corporation Persistent and resilient worker processes

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11424931B2 (en) 2016-01-27 2022-08-23 Blackberry Limited Trusted execution environment
US10599409B2 (en) * 2016-02-02 2020-03-24 Blackberry Limited Application lifecycle operation queueing
WO2017206884A1 (zh) * 2016-05-31 2017-12-07 广东欧珀移动通信有限公司 应用程序关闭方法、装置、存储介质及电子设备
CN109240809A (zh) * 2017-07-11 2019-01-18 阿里巴巴集团控股有限公司 进程维护管理方法、容器维护方法、装置和操作系统
CN112445530A (zh) * 2019-08-29 2021-03-05 成都鼎桥通信技术有限公司 第三方应用程序保活方法及设备
CN110688319A (zh) * 2019-09-30 2020-01-14 RealMe重庆移动通信有限公司 应用保活能力测试方法及相关装置
CN110688319B (zh) * 2019-09-30 2023-05-02 RealMe重庆移动通信有限公司 应用保活能力测试方法及相关装置
CN110879726A (zh) * 2019-10-24 2020-03-13 深圳数位传媒科技有限公司 移动终端应用程序的保活方法及装置
CN110879726B (zh) * 2019-10-24 2023-09-26 深圳数位大数据科技有限公司 移动终端应用程序的保活方法及装置
CN112612589A (zh) * 2020-12-26 2021-04-06 吉林亿联银行股份有限公司 一种应用程序的保活方法及装置
CN115113946A (zh) * 2021-03-17 2022-09-27 广东小天才科技有限公司 一种优化相机启动方法和装置
WO2022267765A1 (zh) * 2021-06-26 2022-12-29 荣耀终端有限公司 一种视频应用的保活方法以及电子设备

Also Published As

Publication number Publication date
CN105335171A (zh) 2016-02-17
CN105335171B (zh) 2019-05-10

Similar Documents

Publication Publication Date Title
WO2015196967A1 (zh) 应用程序常驻操作系统后台的方法及装置
JP6363796B2 (ja) 動的コードデプロイメント及びバージョニング
US10802906B2 (en) Monitoring method and apparatus of server, and storage medium
US10728168B2 (en) Method for providing a connection of a client to an unmanaged service in a client-server remote access system
US10572656B2 (en) Isolated virtual environments for untrusted applications
CN108369534B (zh) 代码执行请求路由
US20200034254A1 (en) Seamless mobility for kubernetes based stateful pods using moving target defense
JP6132009B2 (ja) システム変更後におけるコンピューティング装置の適切な動作を確認するための方法及びシステム
US9003412B1 (en) Performing identified repeatable computations in a changing computing environment
WO2018095414A1 (zh) 虚拟机故障的检测和恢复方法及装置
US8918490B1 (en) Locality and time based dependency relationships in clusters
WO2021098354A1 (zh) 一种基于无障碍服务实现缄默安装的安卓渗透方法和装置
US20150143094A1 (en) System and Method to Perform an OS Boot Using Service Location Protocol and Launching OS Using a Dynamic Update of Network Boot Order Without a Reboot
US9780994B2 (en) Notification normalization
US11231919B2 (en) Live updates of stateful components
JP2006107500A (ja) ソフトウェアの実行中にソフトウェアを更新すること
US20170185420A1 (en) Broadcasting management information using fountain codes
WO2022072474A1 (en) Automated testing of systems and applications
TW201428613A (zh) 無盤工作站啟動系統及方法
US7917614B2 (en) Fault tolerance in a client side pre-boot execution
US10972350B2 (en) Asynchronous imaging of computing nodes
WO2016195624A1 (en) Transferring an image file over a network
US9658894B2 (en) Automatically and dynamically reclaiming resources during virtual machine decommission
TW201523447A (zh) 伺服器系統與韌體更新方法
US10740021B1 (en) Systems and methods for recovery of computing environments via a replication solution

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15812437

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15812437

Country of ref document: EP

Kind code of ref document: A1