Re: [Dev] App installers package

최원영 Wed, 19 Nov 2014 20:48:49 -0800

Title: Samsung Enterprise Portal mySingle

Hello Baptise Durand,

Thanks for your feedback.

The frontend(slp-pkgmgr) doesn't determine if it is in a upgrade case or install case. The slp-pkgmgr just delegates

every processes to the backend. Because the PKGID is required to determine them and it is written in the config.xml

of installing package file.

Therefore, We have to consider "kill running apps" and "backup installed package" steps in the new installer.

And more about "kill running apps" step, I think the installer should kill running application during the installation.
The installer may change resources of the package in a upgrade case. If the old application is running,
that application could be crashed because of the changed resources.

And please refer below description about the installation modes.

Current wrt-installer in Tizen 2.3 supports below installation modes.

PRELOAD:
If we have to support preloaded applications,
the installer should be able to install any web applications in image creating time.

In this case, we should consider checking certifications and privileges and registering the manifest to the package-manager.
Because there are no running daemons for security and managing packages at that time.

        To install applications at first booting time can be a method to support preloaded applications,
        But if the preloaded package has large size (eg. 100MB ~), It takes too much time to show first screen.

FOTA: Firmware OTA
        This is a method to upgrade platform with DELTA over the air.
        FOTA replaces files in Read-Only partitions before booting system.
        And then, It sends a signal to the pkgmgr to update information for changed files.

** This is a commercialization feature. You don't have to add steps for this mode in the tizen common platform.

CSC: Consumer Software Customization
        In general, Mobile devices have a CSC partition to support differnt settings and applications for each region or carrier branding.
        In first booting or changing csc setting by user, the csc script will be executed automatically.
        If the CSC partition has any web application, the web installer should be able to install them.

** This is a commercialization feature. You don't have to add steps for this mode in the tizen common platform.

REINSTALL(RDS): Rapid Development Support
When using RDS, the application is first launched normally. After the first launch, the packaging process is skipped and only modified,
added, and deleted files are installed in the target. If an error occurs while launching, the normal mode is executed.

https://developer.tizen.org/dev-guide/2.2.1/org.tizen.native.appprogramming/html/app_dev_process/rapid_dev_support.htm

RECOVERY:
If the device is turned off during the application installation, the pkgmgr or the any installer should clean up the broken package
and recover already installed package.

BRs,
WonYoung Choi

------- Original Message -------

Sender : Baptiste Durand<[email protected]>

Date : 2014-11-19 20:25 (GMT+09:00)

Title : Re: [Dev] App installers package

Hi WonYoung,

Thanks for your really interesting reply.

See my comments below in blue

There is a weekly call on this topic with Poland Samsung Team to manage the development of app installer framework

I let you see with this Team , if you are interesting to join this task

Thanks

BR

Baptiste

2014-11-19 9:01 GMT+01:00 최원영 <[email protected]>:

Hello Baptiste Durand,

I'm a WRT guy in Samsung. I want to discuss about steps of your new installer.

I think the steps should be divided more, because we have to consider other installation modes (eg. FOTA, CSC, PRELOAD, RDS..).

Could you describe all acronym or abbreviation of rhe installation mode mentioned in a wiki page?

CSC is not clear for me, because in the code of slp-pkgmgr is not linked to a backend installer... there is no call to a backend for this request : PM_REQUEST_CSC .

Could tell us more about these modes?

We are writting an app_installer as backend for pkgmgr-server to manage package for installation / uninstallation / upgrade etc...

Small step operations could be reused in these modes more easily.

This is also my point of view I thinks we are globally in sync.

I just reorganized steps roughly. Please see below contents.

BRs,

WonYoung Choi

--------------------------------------------------------------------------------------------
CASE: INSTALL
// tempdir
#step       create_tmpdir
#abort_step remove_tmpdir

// read config
#step       read_config

// read signature
#step       read_signatures
#step       check_author_signature
#step       check_cert_level

// prepare
#step       check_available_space
#step       backup_installed_package
#abort_step restore_installed_package
#step       kill_running_apps

I thinks there is no needs in case of package installation

For uninstallation case (here there is a need) It is already handled in the pkgmgr-server code :

look the CAPI pkgmgr_client_usr_uninstall

So step for kill_running apps is not relevant

// install
#step       create_pkgdir
#step_abort remove_pkgdir
#step       install_files
#step       create_symlink_for_execution

// register
#step       generate_manifest
#step_abort remove_manifest
#step       register_manifest
#step_abort unregister_manifest
#step       register_signatures
#step_abort unregister_signatures

// encrypt
#step       encrypt_resources

// security
#step       set_smack_labels
#step_abort revoke_smack_labels

// finish
#step       clean_up

CASE: REINSTALL (RDS)
#step       read_config
#step       read_signatures
#step       check_author_signature
#step       kill_running_apps
        #step       install_files_for_rds
#step       register_signatures
#step       encrypt_resources
#step       set_smack_labels

CASE: FOTA
...
CASE: CSC
...
CASE: PRELOAD
...

--------------------------------------------------------------------------------------------

InstallContext {
tmpdir,    /* temporary directory */
src,    /* source path */
config,    /* widget config object */
author_signature,  /* author signature object */
distributor_signature[], /* array of distributor signature objects */
cert_level,   /* Unknown/Public/Partner/Platform */
files,    /* array of installed file path */

This part of your answers is not clear.

You mention this step
# backup_installed_package
depends: config

It is not totally true,
This step is not called during installation but only during upgrade of a package

So this will be only depends of the type of the request : pkgmgr-server should determine this before execute backend.
For me it is not the role of a backend to determine if it is in a upgrade case or install case.

It should be handled by pkgmgr-server .

Install = PKGMGR_REQ_INSTALL:

Uninstall = PKGMGR_REQ_UNINSTALL:

Upgrade = PKGMGR_REQ_UPGRADE.

}

## steps

# create_tmpdir
depends: N/A
output: tmpdir

create a temporary directory for installation.
eg. $HOME/.tmp/{auto_generated_id}

# remove_tmpdir (abort)
depends: tmpdir

remove the temporary directory.

# read_config
depends: tmpdir, src
output: config

Read and parse the widget configuration file, and make a widget config object.
If 'src' path has below file extension,
  1) .wgt: extract config.xml to the temp dir and read it.
  2) .xpk: extract manifest.json to the temp dir and read it.
  3) .xml: read it
* XML schema validation with .xsd file is needed

I thoutght that it is already done. pkgmgr-info package : ./parser/manifest.xsd.in

This file is used by parser library

# read_signatures
depends: tmpdir, src
output: author_signature, distributor_signature[]

Read and parse the signature files, and make signature objects.
If 'src' path has below file extension,
  1) .wgt: extract signature files to the temp dir and read it.
  2) .xpk: extract signature files to the temp dir and read it.
If 'src' path is a directory (in case of RDS),
  read signature files in the specific directory.
* XML schema validation with .xsd file is needed.

# check_author_signature
depends: author_signature

If the package having 'config.pkgid' is already installed, Old author-signature of the installed package and
new author-signature of the new package should be compared.
If these signatures are different, the installation process should be aborted.

# check_cert_level
depends: config, distributor_signatures[]
output: cert_level

Detect the certification level with the distributor signatures and check the widget configuration.
Some attributes and elements and privileges of the widget config require the partner level or over.

# check_available_space
depends: src

Check available space to install new package.
If the 'src' path is a compressed file, consider the uncompressed size of the package.

# backup_installed_package
depends: config

If the package having 'config.pkgid' is already installed, the installed package should be moved to
the backup location.
eg. $HOME/.config/xwalk_service/applications/{pkgid}/ ==>
     $HOME/.config/xwalk_service/applications/{pkgid}.backup/

# restore_installed_package (abort)
depends: config

If the backup directory for the installed package is exist, restore it.
eg. $HOME/.config/xwalk_service/applications/{pkgid}.backup/ ==>
     $HOME/.config/xwalk_service/applications/{pkgid}/

# kill_running_apps
depends: config

If the applications of the installed package are running, these should be killed before installation.

As I already said before, I don't fully agree with you
for me it is true for uninstallation case only and it is already done in pkgmgr_client_usr_uninstall

# create_pkgdir
depends: config

Create a directory to install new package.
eg. $HOME/.config/xwalk_service/applications/{pkgid}

Ok for the proposition
execpt for the PATH , FYI the path is the one currently used but it is not aligned witht the spec. => https://wiki.tizen.org/wiki/Application_framework#Application_Paths

# remove_pkgdir
depends: config

Remove the created package directory.
eg. $HOME/.config/xwalk_service/applications/{pkgid}

# install_files
depends: src, config
output: files

Extract files from the package file to the created package directory.
if the package is
  1) a packaged web app, extract files to $HOME/.config/xwalk_service/applications/{pkgid}/res/wgt/
  2) a hosted web app, copy the .xml file to $HOME/.config/xwalk_service/applications/{pkgid}/res/wgt/
  3) a hybrid web app, extract files to $HOME/.config/xwalk_service/applications/{pkgid}/

And make a list of installed files.

# install_files_for_rds
depends: src, config
output: files

In case of RDS, the SDK pushes changed files and a delta file to a temp dir.
        This step should read and parse the delta file first, and copy the changed files to the path of the
installed package or remove removed files from the path.
And make a list of installed files.

# create_symlink_for_execution
depends: config

Create a directory for execution files.
eg. $HOME/.config/xwalk_service/applications/{pkgid}/bin/
Create a symbolic link file to indicate 'xwalk_launcher'
eg. {appid} -> /usr/bin/xwalk_launcher

# generate_manifest
depends: config

Generate the manifest file for the package-manager with the widget configuration.
eg. $HOME/.applications/manifest/{pkgid}.xml

# remove_manifest (abort)
depends: config

Remove the manifest file of the package.
eg. $HOME/.applications/manifest/{pkgid}.xml

# register_manifest
depends: config

Register the generated manifest file to the package-manager.

# unregister_manifest (abort)
depends: config

Unregister the registered manifest from the package-manager.

# register_signatures
depends: config, author_signature, distributor_signature[]

Register signatures to the package-manager.

# unregister_signatures
depends: config

Unregister signatures from the package-manager.

# encrypt_resources
depends: config, files

If the "encryption" attribute of <setting> element has "enabled" value,
The installed files should be ecrypted.

# set_smack_labels

I'm affraid I don't agree on this step :

security manager should handle this part. in independent way.

It should be systematic to secure installation process for all kind of app.

# set_smack_labels ===> set security_manager_calls

depends: config

Set smack labels to directories of the installed package.
Set smack rules with privileges of the widget configuration.

# revoke_smack_labels
depends: config

remove smack labels and rules of the package.

# clean_up
depends: tmpdir

remove the temporary directory and the backup directory.

------- Original Message -------

Sender : Baptiste Durand<[email protected]>

Date : 2014-11-19 02:41 (GMT+09:00)

Title : [Dev] App installers package

Hi all,

As reminder, the goal of this package is to provide a set of function to implement easily a installer for every type of applications on Tizen.( i.e wgt/xpk and native app tpk).

The git repository for this new package is stored here : platform/appfw/app_installers

As decided with Samsung Team led by Pawel Sitorsky, the C++ language will be preferred to C language.
As the package should be aligned with the global architecture of Tizen, (https://wiki.tizen.org/w/images/2/2c/Architecture_Overview_.jpg) CAPI should be used to access to a platform service. So we need to wrap them because CAPI are mainly written in C.

The proposal is described here : https://wiki.tizen.org/wiki/Applications_Installer#Implementation_concept

The idea is to be able to initialize easily an app_installer by declare a list of step as below :

for widget as example
int
main (int argc, char **argv)
{
int result;
AppInstaller Installer = new AppInstaller();
/* get request data */
pi = pkgmgr_installer_new ();
if (!pi)
    return ENOMEM;
result = pkgmgr_installer_receive_request (pi, argc, argv);
if (result)
    {
      pkgmgr_installer_free (pi);
      return -result;
    }

/* treat the request */
switch (pkgmgr_installer_get_request_type (pi))
    {
    case PKGMGR_REQ_INSTALL:
        Installer->AddStep(step_unpack);
        Installer->AddStep(step_check_signature);
        Installer->AddStep(step_check_wgt);
        Installer->AddStep(step_manifest_wgt);
        Installer->AddStep(&step_register_app);
        Installer->Run();
      break;

    case PKGMGR_REQ_UNINSTALL:
    .............

    default:
      /* unsupported operation */
      result = EINVAL;
      break;
    }
pkgmgr_installer_free (pi);
return result;
}

Any point fo view are welcomed on this architecture.

Thanks in advance

BR

Baptiste

--

Baptiste DURAND
Eurogiciel Vannes/FR

Baptiste DURAND
Eurogiciel Vannes/FR

_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Re: [Dev] App installers package

Reply via email to