JP6143476B2 - Application processing apparatus, method, and program thereof - Google Patents

Description

  The present invention relates to an application processing apparatus, method, and program for processing an application package.

  As an application execution environment, Java (registered trademark) is widely adopted. Reasons for adopting Java (registered trademark) include platform independence, abundant class libraries, a secure execution environment, and the like. Another major feature is a unified application distribution form.

  Java (registered trademark) Runtime Environment (JRE), which is an execution environment of Java (registered trademark), is a software for executing a class library and an application described in Java (registered trademark) VM (Java (registered trademark) language). ), And a porting layer specific to the terminal on which the JRE is mounted. When the execution environment receives a JAR (Java (registered trademark) Archive) file as an input, the class file (source code written in the Java (registered trademark) language necessary for execution is compiled from the JAR file by the Java (registered trademark) compiler. The program module generated by doing this is read and executed. A JAR file is a file in which various resource files (image file, text file, etc.) used in the course of executing a class file and a Java (registered trademark) application are packaged in a JAR format. Class loading is performed by the class loader. The class loader searches a class of a class file packaged in the JAR format with reference to a class path (information indicating a path where the class exists).

  The JAR file A can include a JAR file B, which is another JAR file, but the normal class loader cannot read the JAR file B inside the JAR file A. Therefore, the JAR file B inside the JAR file A is expanded outside the JAR file A, and expanded to the class path set in the execution environment when the JAR file A is executed or the class path set in the class loader that reads the JAR file A. There is a method in which the JAR file B is read by a normal class loader by adding the above location.

  The class loader cannot read a JAR file that normally exists inside the JAR file. That is, in the above example, the JAR file B inside the JAR file A is not recognized as a read target from the class loader and is not read. As described above, if the JAR file is not deleted together with the development, a plurality of identical files exist. In this state, the development-source JAR file includes a file that is not read when the program is executed, which causes a problem in a device having a small storage area.

  As a technique for solving such a problem, for example, there is a technique for executing a JAR file program once, specifying a file that is unnecessary at the time of execution, and deleting it from the JAR file (see, for example, Patent Documents 1, 2, and 3). .

JP2010-66872A JP2012-123619A WO02 / 075525

  In Patent Document 1, an icon image file included in a JAR file is deleted, and the size of the JAR file is reduced. However, in order to specify the file to be deleted, the JAR file program must be executed at least once.

  In Patent Document 2, resource consumption is reduced by deleting unnecessary functions included in an application. However, since an unnecessary function is determined based on the execution history of each function, the program must be executed at least once. Files relating to unnecessary functions continue to occupy storage until they are determined to be unnecessary functions and are deleted.

  In Patent Document 3, when an application is updated, a file that becomes unnecessary after the update is deleted. However, only the difference files generated by the update are to be deleted.

  In an environment where the storage capacity of the device is not sufficient, it is necessary to quickly reduce the size of the JAR file in the installation / update process.

  The present invention has been made in view of the above problems, and an object of the present invention is to provide an application processing apparatus that quickly reduces the size of a JAR package file and saves the storage capacity of the device. Moreover, it aims at providing the method and program.

  The application processing apparatus of the present invention has the following configuration. That is, an application processing apparatus that processes an application package including a library and setting information, the receiving means for receiving the application package, and a development target library that the setting information designates as a development target is expanded in a storage device. And writing means for writing the package not including the library to be expanded into the storage device.

  According to the present invention, since the library file expanded outside the application package is not included in the application package, the size of the application can be reduced.

The figure which shows an example of the hardware constitutions of an information management apparatus The figure which shows an example of the system configuration constructed | assembled on an information management apparatus Diagram showing file structure of application package 2 is a diagram illustrating a configuration of an application management framework 203 according to the first embodiment and an area of a storage device included in the information management apparatus. FIG. Flowchart of installation processing according to the first embodiment Flowchart of update processing according to the second embodiment (A) The figure which shows the file written in the general purpose area and installation area concerning Embodiment 2 (b) The figure which shows the file written in the general purpose area and installation area concerning Embodiment 2 (c) Embodiment 2 The figure which shows the file written in the general purpose area | region concerning installation and the area | region for installation (d) The figure which shows the file written in the general purpose area | region and installation area concerning Embodiment 2 The figure which shows the structure of the application management framework 203 concerning Embodiment 3. FIG. The figure which shows the file structure of the installed package of the installed application concerning Embodiment 3. Flowchart of installation processing according to the third embodiment Flow chart of update processing according to embodiment 4 A text file describing a list of applications to be installed according to the third embodiment Flow chart of installation processing according to embodiment 5 Flow chart of installed application reduction processing according to the sixth embodiment The figure which shows the structure of the application management framework 203 concerning Embodiment 6. FIG.

  Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. The configurations shown in the following embodiments are merely examples, and the present invention is not limited to the illustrated configurations.

<Embodiment 1>
FIG. 1 is a diagram illustrating an example of a hardware configuration of a general information management apparatus 101. As shown in FIG. 1, the information management apparatus 101 includes a CPU 11 as a hardware configuration.

  The CPU 11 realizes each function or flowchart described later by performing processing based on a program corresponding to each of the application and program execution environment described later stored in the storage device 13.

  Further, an input device 12, a storage device 13, a display device 14, and an external connection IF 15 are connected to the CPU 11 via the bus 10. The input device 12 is a keyboard and / or a mouse for inputting information. The storage device 13 includes, for example, a ROM, a RAM, a hard disk device, and the like, and stores data used in processing based on the program in addition to the above-described programs. The display device 14 is a display that displays a screen or the like. The external connection IF 15 is a network interface and various connection interfaces with external devices.

  The CPU 11 can function as various means by executing a program. Note that a control circuit such as an ASIC that operates in cooperation with the CPU 11 may function as these means. These means may be realized by cooperation between the CPU 11 and a control circuit that controls the operation of the information management apparatus. Further, the CPU 11 does not have to be a single one and may be a plurality. In this case, the plurality of CPUs 11 can perform processing in a distributed manner. Further, the plurality of CPUs 11 may be disposed on a single computer, or may be disposed on a plurality of physically different computers. Note that the means realized by the CPU 11 executing the program may be realized by a dedicated circuit.

  Next, a system configuration built on the information management apparatus 101 will be described with reference to FIG. FIG. 2 is a diagram illustrating an example of a system configuration of the information management apparatus 101.

  The operating system 201 is software that is the basis of the entire system. The application execution environment 202 is software that provides an environment in which an application operates on itself while being a process on the operating system 201 such as a virtual machine. The application management framework 203 has a function of managing the operation state of each application 204. In addition, a system application 205 that instructs the application management framework 203 may operate. For example, a system application 205 having a user interface for instructing application installation / update is given.

  In the hardware configuration of the information management apparatus 101 used in the present embodiment, the storage device 13 includes a high-speed installation area and a low-speed general-purpose area. Since the capacity of the installation area is relatively small, it becomes a problem to suppress the storage of files unnecessary for executing the application.

  In order to solve these problems, the present embodiment realizes a mechanism that allows the application management framework 203 to reduce the size of the installed application to occupy the storage device while properly using the general-purpose disk area and the installation disk area.

  First, the package configuration of an application to be installed / updated will be described with reference to FIGS. 3 (a) and 3 (b). FIG. 3A shows the file structure of the package. FIG. 3B shows the file structure of the installed package.

  An application 301 shown in FIG. 3A is a JAR file. The JAR file includes a bin 302 that is an executable program. It also includes a manifest 303 describing the application name, id, vendor, etc. (hereinafter, synonymous with the manifest file). Further, the application 301 can include a plurality of bins 302 that implement specific functions in a JAR file. The included JAR file group is lib304 (library). The application 301 necessarily includes the bin 302 and the manifest 303, but does not necessarily include the lib 304. When the lib 304 is included, the path of each JAR file that is an element of the lib 304 is described in the item of the manifest 303 describing the JAR file group to be expanded.

  An application 301 illustrated in FIG. 3B has a file configuration already installed in the installation area 402. The lib 304 is expanded outside the JAR file 301 and is not in the JAR file 301. Information for the class loader to find the lib 304 is stored as class path information 305.

  Next, the operation of the application management framework 203 will be described with reference to FIGS. FIG. 4 is a diagram illustrating a configuration of the application management framework 203 and a storage device area included in the information management apparatus 101. FIG. 5 is a flowchart showing a procedure of processing in which the application management framework 203 installs the application 301.

  The general-purpose area 401 and the installation area 402 are storage areas included in the storage device 13. The area writing unit 404 can write to both the general-purpose area 401 and the installation area 402 by specifying the write destination path and writing the data.

  The application management framework 203 receives the data of the application 301 to be installed / updated by the package receiving unit 403 (step S501). The received data is given as a data stream, and the application management framework 203 needs to convert the data stream into a file format in order to read the manifest 303 of the target application. Therefore, the application management framework 203 uses the area writing unit 404 to write the package stream as a temporary file in the general-purpose area 401 (step S502). The reason why the general-purpose area 401 is written is that a temporary file is not arranged in the installation area 402. If a temporary file is arranged in the installation area 402, when writing to the installation area 402 in step S 504, which will be described later, the free area of the installation area 402 becomes small and writing may fail. is there. As a specific example, the installation area 402 has a capacity of 10 MB, and a 6 MB application 301 is installed. Here, if a temporary file is arranged in the installation area 402, a capacity of 12 MB is required during the installation process, and thus writing fails.

  When the application 301 is written in the general-purpose area 401, the application management framework 203 reads the manifest (manifest 303) by the setting information acquisition unit 405 (step S503).

  Then, the application management framework 203 confirms whether the file to be expanded (lib 304) is described in the manifest (step S504). If it is described, the package development unit 406 uses the region writing unit 404 to perform development by writing the lib 304 in the installation region 402 (S506).

  When step S504 or step S506 is completed, the application management framework 203 writes a file other than the deployment target JAR file (lib 304) described in the manifest in the installation area 402 (step S505). In writing, the JAR file 301 in the general-purpose area 401 is opened, and necessary files (bin 302 and manifold 303) are written into the data stream opened for the file in the installation area 402. By doing so, the JAR file of the application 301 without the lib 304 is written in the installation area 402 without writing the temporary file in the installation area 402.

  Next, the application management framework 203 saves the class path information 305 in the installation area 402 (step S507). The class path information 305 is the path of the application 301 written in the installation area 402 and the path of the lib 304.

  When the class path information 305 is saved, the package written in the general-purpose area 401 is deleted (step S508), and the installation process ends. The embodiment in the case where the application management framework 203 performs the installation process has been described above. The package size of the installed application can be reduced by placing the package to be installed once in the general-purpose area and writing the package including only necessary files in the installation area. Since the lib 304 file is not written redundantly in the installation area 402, the package size is reduced.

<Embodiment 2>
Next, an application update processing procedure performed by the application management framework 203 will be described with reference to FIGS. 6, 7A, 7B, 7C, and 7D. FIG. 6 is a flowchart illustrating a processing procedure performed by the application management framework 203. FIG. 7A, FIG. 7B, FIG. 7C, and FIG. 7D show the files written in the general-purpose area 401 and the installation area 402 in each update process of the application management framework 203. FIG.

  An example in which the installed application 301 is updated by the application 701 will be described. The application 701 is an upgraded version of the application 301. In the manifest 303 and the manifest 703, the name and id of the application are the same.

  Steps S601 and S602 are the same as steps S501 and S502, respectively. After step S602, the general-purpose area 401 and the installation area 402 are in the state shown in FIG.

  Next, the application management framework 203 saves the installed package (the JAR file of the application 301 in the installation area 402) and the lib 304 of the application 301 in the general-purpose area 401 (S603). The saving process is performed by deleting the package of the application 301 and the lib 304 from the installation area 402 after copying the package of the application 301 and the lib 304 to the general-purpose area 401. At this time, the states of the general-purpose area 401 and the installation area 402 are as shown in FIG.

  Next, the application management framework 203 reads the manifest in the same manner as in step S503 (step S604), and performs the same processing as in steps S504 and S506 (S605 and S607). Similarly to step S505, the package of the application 701 and the lib 704 are written in the installation area 402 so that the lib 704 does not overlap (S606).

  When step S606 is completed, it is confirmed whether an exception has occurred in the processing so far (step S608). As an assumed exception, there is a write exception due to insufficient free space in the installation area 402. For example, when the package size increases before and after the update, an exception of insufficient free space may occur. In addition, if a new package is written in step S605 without saving in step S603, a shortage of free space in the installation area 402 is likely to occur. Also, if data is overwritten without being saved, when the update fails, the state before the update cannot be restored as in step S610.

  If no exception has occurred, the new class path information is saved as class path information 705 (step S609). At this time, the states of the general-purpose area 401 and the installation area 402 are as shown in FIG. If an exception has occurred, the files (applications 701 and lib 704) written in the installation area 402 are deleted. Then, the saved package (application 301, lib 304) is returned to the installation area 402 and restored to the original state (step S610).

  Next, the application management framework 203 deletes the packages 301, 701, and lib 304 written in the general-purpose area (S611), and the process ends. If no error has occurred in step S608, the state of the general-purpose area 401 and the installation area 402 at this time is as shown in FIG.

  Note that the process of step S603 may be performed at any timing as long as it is prior to steps S606 and S607.

  The embodiment in the case where the application management framework 203 performs application update processing has been described above.

<Embodiment 3>
In the first embodiment, a process of writing a package with a reduced size in a state where there is no lib 304 into the installation area 402 is performed. If a temporary file is arranged in the installation area in this reduction process, the installation area may not be fully utilized. In order to place a temporary file in the installation area, the free space in the installation area is twice as large as the installation target application. Therefore, in the first embodiment, the stream received in the installation process is written as a file in the general-purpose area 401 and then the file is written in the installation area 402.

  On the other hand, when the application 301 does not include the lib 304, the installation process can be performed at higher speed by directly writing the stream into the installation area 402. In addition, when the size of the lib 304 is small, it may be desired to prioritize speeding up the installation process over reducing the size. In order to deal with such a case, the application management framework 203 has a function to instruct / set in advance whether or not to perform package reduction processing, and to determine whether or not to perform reduction processing with reference to the instruction. It is necessary to prepare.

  Therefore, an embodiment having a function of determining a package reduction process will be described as a third embodiment with reference to FIG. FIG. 8 is a diagram illustrating a configuration of the application management framework 203 including a package reduction process determination unit.

  The reduction processing determination unit 801 determines whether the application management framework 203 performs reduction processing. As a determination method, the application management framework 203 includes two types of APIs, ie, an installation API that performs reduction processing and an API that does not perform reduction processing, and does not perform reduction processing depending on which API the system application 205 executes. It is conceivable to determine whether or not.

  In this case, as the system application 205, there is a system application that includes a UI that receives an installation instruction from the user. The user selects whether or not to perform reduction processing, and instructs the installation of the application 204 from the UI of the system application 205. The system application 205 uses the two APIs according to the user's selection.

  Further, it is conceivable to provide an API for installation, and an API for setting whether or not to perform a separate reduction process. In this case, the UI of the system application 205 includes a check box for instructing reduction processing, and the application management framework 203 is set according to the selection state of the check box by the user. By setting in advance, the user omits the selection of the reduction process when instructing the installation, and the reduction process determination unit 801 performs the determination with reference to the setting. When installing a plurality of applications, confirmation with the user each time can be omitted.

  In addition, when installing a plurality of applications 204 by firmware update, it is inefficient if a user performs an installation operation for each application 204. Therefore, there is a method in which a list of applications to be installed is described in a text file, and the application management framework 203 reads the text file immediately after the firmware update and automatically installs it. The text file describes whether or not reduction processing is performed for each application. Text files are created manually by the farm creator and included in the farm. FIG. 12 is an example of the description of the text file. FIG. 12 is a text file showing a list of applications 204 to be automatically installed. At this time, the time required for automatic installation can be shortened by reducing only the application (appB.jar) that is expected to have a reduction effect. Therefore, the text file also describes whether or not to perform reduction processing (Reduction item) for each application to be installed. When the application management framework 203 reads the text file of FIG. jar is read from the firmware and given to the package receiving unit 403. Then, the reduction process determination unit 801 refers to the description “Reduction = false” and determines that the reduction process is not performed. appA. When the installation of jar is finished, the appB. jar, appC. The jar is also installed and the automatic update is complete.

  The specific example of the assumed reduction processing determination unit 801 has been described above. From here, the flow of the installation process will be described with reference to FIGS.

  FIG. 9 is a diagram illustrating configurations of installed packages of an application 701 installed by performing package reduction processing and an application 901 installed without performing reduction processing. FIG. 10 is a flowchart showing a procedure of installation processing of the application management framework 203.

  Step S1001 is the same as step S501. Upon receiving an installation instruction, the application management framework 203 determines whether the reduction process is necessary by the reduction process determination unit 801 (step S1002).

  If the reduction process is not necessary, the package stream is written as a file in the installation area 402 (step S1003), and the manifest is read (step 1004). Then, it is confirmed whether or not the lib to be expanded is described in the manifest (step S1005). If it is described, the lib is expanded in the same manner as in step S506 (step S1006).

  On the other hand, if the reduction process is necessary, as in step S502, the general area 401 is written (step S1007) and the manifest is read (step S1008). Then, it is confirmed whether or not the lib to be expanded is described in the manifest (step S1009), and if it is described, the lib is expanded as in step S506 (S1011). When lib is not described in the manifest, or when step S1011 is completed, the package is written in the installation area 402 as in step S505 (step S1010).

  Next, the class path information is stored as in step S507 (step S1012). The file written in the installation area 402 at this time becomes an application 701 in FIG. 9 when it is determined that the reduction process is necessary. When it is determined that the reduction process is not necessary, the application 901 in FIG. 9 is obtained.

  Finally, the package in the general-purpose area 401 is deleted as in step S508 (step S1013), and the process ends. However, if it is determined that the reduction process is not necessary, nothing is written in the general-purpose area 401, so nothing is deleted in step S1013.

  The installation process of the application management framework 203 including the reduction process determination unit 801 has been described above.

<Embodiment 4>
Next, an application update process performed by the application management framework 203 including the reduction process determination unit 801 will be described with reference to FIG.

  When the update process starts, a package to be updated is received as in step S601 (step S1101). Then, similarly to step S603, the installed package and lib are saved in the general-purpose area (step S1102). Then, it is determined whether package reduction processing is necessary (step S1103).

  If it is determined that the reduction process is not necessary, the package stream is written as a file in the installation area 402 (step S1104), and the manifest is read (step 1105). Then, it is confirmed whether or not the lib to be expanded is described in the manifest (step S1106). If it is described, the lib is expanded in the same manner as in step S607 (step S1107).

  On the other hand, if it is determined that the reduction process is necessary, the general area 401 is written (step S1108) and the manifest is read (step S1109) as in step S602. Then, it is confirmed whether or not the lib to be expanded is described in the manifest (step S1110). If it is described, the lib is expanded in the same manner as in step S607 (step S1112). If lib is not described or the expansion is completed in step S1112, the package is written in the installation area as in step S606 (step S1111).

  Next, as in step S608, it is confirmed whether an exception has occurred in the processing so far (step S1113). If no exception has occurred, the class path information is saved as in step S609 (step S1114). If an exception has occurred, the saved package is returned to the installation area 402 as in step S610 (step S1115).

  Finally, the package in the general-purpose area is deleted as in step S611 (step S1116), and the process ends.

  The update process of the application management framework 203 including the reduction process determination unit 801 has been described above.

<Embodiment 5>
In the first embodiment, when there is sufficient free space in the installation area 402, a temporary file may be written in the installation area 402 without using the general-purpose area 401. The present invention can be implemented even when the storage device 13 includes only an installation area. The operation of the application management framework 203 when the storage device 13 has only one area will be described with reference to FIG. FIG. 13 is a diagram showing a flow of installation processing of the application management framework 203.

  First, the package data to be installed is received as in step S501 (step S1301). Then, as in step S502, the package is written in the storage device 13 (step S1302).

  Steps S1303, S1304, S1305, S1306, and S1307 are the same as steps S503, S504, S505, S506, and S507, respectively.

  Finally, the package written as a temporary file in the storage device 13 is deleted (step S1308), and the process ends.

  The installation process in the case where the storage device 13 has only one area has been described above.

<Embodiment 6>
In the first embodiment, a process of writing a package whose size is reduced so that the lib 304 is not held redundantly into the installation area 402 is performed. This process was called a reduction process.

  By the way, the system configuration built on the information management apparatus 101 changes due to firmware update. For example, it is assumed that the application A is installed in the information management apparatus 101 in which the old application management framework 203 that does not support reduction processing is installed. Thereafter, when a new application management framework 203 corresponding to the reduction process is introduced into the information management apparatus 101 by updating the firmware, the size of the installed application A is not reduced unless it is updated and reinstalled.

  As described above, it is assumed that the application management framework 203 has a function of performing only the reduction process in an environment in which an application that has not been subjected to the reduction process has been installed. Then, the size of the installed application can be reduced without updating and reinstalling the application A.

  The function that the application management framework 203 reduces the size of the installed application will be described with reference to FIGS. FIG. 14 is a flowchart showing the procedure of the reduction process performed by the application management framework 203. FIG. 15 is a diagram illustrating a configuration of the application management framework 203 including a package reduction processing instruction receiving unit.

  The reduction process is started when the system application 205 instructs the application management framework 203 to specify the application to be reduced, and the reduction process instruction receiving unit 1501 included in the application management framework 203 receives the instruction. The presence or absence of the lib file is confirmed, and the size of the lib file exceeds a certain value to confirm the application to be reduced. An example in which the application management framework 203 includes an API for instructing reduction processing and is executed by the system application 205 is given. Further, there may be an example in which the system application 205 creates a list of reduction processing target applications 204 as a reduction instruction file, and the application management framework 203 reads the reduction instruction file at the time of activation.

  When the reduction process has not been performed, the installed application 901 is held as an installed package 901 and an expanded lib 904 as illustrated in FIG.

  First, the application management framework 203 reads the manifest 903 of the installed package 901 to be reduced (step S1401). Then, it is confirmed whether or not the lib 904 to be developed is described in the manifest 903 (step S1402). If not, the process ends.

  If the lib 904 to be expanded is described in the manifest, it is confirmed whether the lib 904 is included in the installed package 901 (step S1403). If not, the process ends.

  If the lib 904 is included in the installed package 901, the installed package 901 is moved to the general-purpose area 401 (S1404). Then, referring to the moved package, the package is written in the installation area 402 as a package from which lib 904 has been removed (S1405), and the process ends.

  The reduction process execution procedure for the case where the information management apparatus 101 in which the application management framework 203 that does not support the reduction process is supported by the firmware update has been described above.

<Other embodiments>
Although the embodiment has been described in detail above, the present invention can take an embodiment as a system, apparatus, method, program, recording medium (storage medium), or the like. Specifically, the present invention may be applied to a system composed of a plurality of devices (for example, a host computer, an interface device, an imaging device, a web application, etc.), or may be applied to a device composed of a single device. good.

  Needless to say, the object of the present invention can be achieved as follows. That is, a recording medium (or storage medium) that records a program code (computer program) of software that implements the functions of the above-described embodiments is supplied to the system or apparatus. Needless to say, such a storage medium is a computer-readable storage medium. Then, the computer (or CPU or MPU) of the system or apparatus reads and executes the program code stored in the recording medium. In this case, the program code itself read from the recording medium realizes the functions of the above-described embodiment, and the recording medium on which the program code is recorded constitutes the present invention.

Claims (12)

An application processing device that processes an application package including a library and setting information,
Receiving means for receiving a package of the application;
An application processing apparatus comprising: writing means for expanding and writing a development target library specified by the setting information as a development target in a storage device, and writing a package not including the development target library to the storage device. The storage device includes a first storage area and a second storage area,
The writing means writes the package received by the receiving means during the installation process into the second storage area, and writes the development target library specified by the setting information as the development target into the first storage area. 2. The application processing apparatus according to claim 1, wherein a package not including the development target library is written in the first storage area. The receiving means receives a package of a new application,
The writing unit writes the installed application package, the deployed library, and the new application package received by the receiving unit to the second storage area, and the setting information of the new package is designated as a deployment target. A development target library to be developed and written to the first storage area , a new package not including the development target library is written to the first storage area,
The application processing apparatus according to claim 2, further comprising a deletion unit that deletes the installed application package, the deployed library, and the new application package written in the second storage area. A reduction process determination unit that determines an instruction to write either a package that does not include the expansion target library or a package that includes the expansion target library to the storage device during the installation process;
The application processing apparatus according to claim 1, wherein the writing unit writes a package based on a result of the reduction processing determination unit. 2. The application processing according to claim 1, wherein the receiving unit receives a package in a stream format, writes the package in the stream format as a file in the storage device, and acquires the setting information by reading the file. apparatus. The application processing apparatus according to claim 1, wherein the setting information is a manifest file. The application processing apparatus according to claim 1, wherein the application processing apparatus has an application management framework function. The application processing apparatus according to claim 1, wherein the receiving unit receives a package of an application to be installed. The application processing apparatus according to claim 2, wherein the first storage area is an installation area, and the second storage area is a general-purpose area. The application processing apparatus according to claim 3, wherein an installed application is updated by the new application. An application processing method for processing an application package including a library and setting information,
Receiving a package of the application;
The development target library designated as the deployment target by the setting information is expanded and written in a storage device,
An application management method comprising a writing step of writing a package that does not include the development target library into the storage device. Receiving means for receiving a package of an application including a library and configuration information;
A program for causing a development target library specified by the setting information as a development target to be developed and written in a storage device, and to function as writing means for writing a package that does not include the development target library into the storage device.

Images