-
Notifications
You must be signed in to change notification settings - Fork 1
Tizen 2.1 WRT features and related tasks
The web application package management in Tizen includes app installation, uninstallation, update and setting. Tizen WRT installer worked as a backend of Tizen system package manager. The installation could be triggered from Application Store Client or a file explorer, while uninstallation could be triggered from Application Setting menu.
The application installation tasks including:
- different installation source support(.wgt, config.xml path, directory, DRM package)
- parse configuration manifest file(W3C Widget Packaging format based) with Tizen extensions
- source file encryption
- Web API version check, quit installation when minimum version is not satisfied
- check signature and quit the installation when Web API privilege is not matched
- files and database manipulation, VCONF entries creation, SMACK rules creation
- install plugin when a NPAPI plugin is contained
The application settings include:
- basic app info
- clear app data
- security settings, including show security warnings, web notification, web database, location, filesystem
- developer options
- suspend JavaScript execution and rendering(including CSS animations) when app enters invisible state
- resume execution and rendering when app enters visible state
- do not suspend execution when background mode is enabled
- support W3C API and Tizen Device API
- support Tizen Device API in both top-level browsing context and nested browsing context
- external pages are not allowed to access Tizen Device API
- support system language change
- purge application memory when system memory is low
- some W3C API(geolocation, storage, notification...) permssion warning
- support multiple browsing contexts in one application
- support W3C Widget Access Request Policy
- support sms://, mmsto://, mailto:// schemes, launch platform's handler for each scheme with appropriate parameters
- application resource encryption
- custom user agent string
- screen orientation
- Application Control support
There're several layers for Tizen Web Application Security control.
- The first layer is widget signature, widgets with different signatures or no signature will be regarded as different trust levels.Different trust levels can access different privilege APIs, application with lower trust level can not access privileges require higher level.
- The second layer is Access Control Engine layer, OEM can provide a policy configuration file to configure different behaviors when a privilege API is accessed, like deny, permit, blanket prompt, session prompt, one-shot prompt and etc.
- The last layer will be the SMACK, it will control the access from the system level, WRT needs create and update SMACK rules according to its access permissions to different APIs.
Below is the table of API privileges and their minimum signature level:
WRT also provides privacy permission check at the first launching time when an application requires some sensitive API privileges.
Below is the map of API privileges to privacy:
AppWidget is a small application widget displayed on HOME screen. User can interact with app widget w/o launching the app. One AppWidget consist of one Box and one PD(optional).
Box features:
- provides simple information of an app on Home screen
- can be updated periodically, the period can be configured in config.xml
- can be resized by user
- stop after rendering its contents
PD(Progressive Disclosure) features:
- provides more detailed information and controls its Box
- can be exposed when user flicks down a Box
- is destroyed when user touches other screen area outside of PD
- receive all touch events except two finger zoom
AppWidget can use the same set of HTML5 and Tizen device APIs as the web application. Box and PD can communicate with each other by using pdWindow, window.opener and Web Messaging API.
|
Tizen2.1 |
Chromium |
Sysapps |
Manifest format |
W3C widget spec with Tizen extensions, XML formatted |
JSON formatted manifest |
JSON formatted manifesthttp://www.w3.org/2012/sysapps/manifest/
|
Package management |
Standalone web app installer worked as system package manager backend. Package format is the same as W3C widget spec, widget will be signed if needed according to: http://www.w3.org/TR/2013/REC-widgets-digsig-20130418/
Installation: API version check, source file encryption, signature check for required APIs Update: based on apppid/ID |
CRX package format. http://developer.chrome.com/extensions/crx.html Update: autoupdating supported by "update_url" field in manifest |
The container of packaged application must be a ZIP file. Package will be signed if needed. A minimum outside manifest is needed for installation and update.
|
Device/extension APIs |
Each different API category has a different plugin library, and most of them are loaded dynamically when needed. |
http://developer.chrome.com/extensions/api_index.html Implemented in browser process and called by IPC. Many of them are browser oriented. |
Only draft version Phase1: Alarm, Contacts, Messaging, Telephony, Raw Sockets Phase2: Bluetooth, Browser, Calendar, Device Capabilities, Idle, Media Storage, Network Interface, Secure Element, System Settings |
|
Permissions
|
Declare the requested APIs in manifest file as <privilege>.
Signature defines the app's trust level when installation, different trust level can access different privilege APIs. ACE controls API access and user interactive behavior when API access happens. SMACK control the underlying file system level access.
Applications can defined their CSP policy in the manifest files. |
Some declared permissions(not only API) will be prompted to user before installation.
Sandbox. The browser process perform the policy-allowed actions on behalf of the application process. http://www.chromium.org/developers/design-documents/sandbox
A CSP policy must be applied to all packaged apps.
|
Define all permissions it is going to use in the application manifest.
Only privileged application(marked privileged by a trusted installation origin with its sign) can access some APIs.
A CSP policy must be applied to privileged app. |
Privacy |
Some APIs maybe related to user's privacy information. Then when first launch the application will perform permission warning check. |
N/A |
N/A |
App lifecycle |
Suspend JS and rendering when app goes to background. Resume app when foreground. No JS callback is invented.
Keep running if background-support is enabled. |
Two events for event page. onLaunch() when event page loaded, onSuspend() when all windows are closed. Event page will be unloaded after idle for a moment.
Background page could be used for as long existing invisible service.
No JS or rendering suspend state is defined. |
"pause" event will send on Application object before switching its state; "terminate" event will send on Application object before shutting down the app; "resume" event will send on Application object after changing its state; "launch" event will send on Application object after the main browsing context is created but before the "load" and "DOMContentLoaded" events are fired.
Paused application will stop JS and rendering.
|
App Control/Intent |
App control for both web and native applications. Applications can be launched both explicitly or implicitly. |
Web Intents is removed currently. |
System Message can be used to handle this. But the manifest field is not defined yet. |
Multiple windows |
Multiple browsing contexts are supported in within one app. Contexts from the same origin can access the APIs like the main browsing context. The new window will stack on the old ones. |
New windows can be created by chrome.app.window.create() API. And JS has full control of a app window through the AppWindow object methods.
Event page can control to only have one open window when application is launched from the launcher. |
N/A |
Multiple instance |
Only one instance of an app running. If they want to launch it again the previous one will be brought to foreground.
If an app is used as an intent service, then there may be multiple instances for it. In this case the origin is the same for all running instances. However there's not fine control over this like Android. http://developer.android.com/guide/topics/manifest/activity-element.html#lmode |
Only one event page can be exist for an application. |
app:// URI scheme is instance based. The authority is an unique identifier that represents the instance of an application that is making use of the app: URI. |
Hosted app support |
<tizen:content/> tag is used to define hosted app entry URL. |
Less permissions. App cache support. |
Privileged app can only be a packaged application. App cache support. |
App widget |
AppWidget is a small application widget displayed on HOME screen. User can interact with app widget w/o launching the app. One AppWidget consist of one Box and one PD(optional). |
N/A |
N/A |
Native Plugin |
NPAPI plugin is supported for packaged app. |
Support NPAPI(deprecating), PPAPI, NaCL. |
N/A |
As Crosswalk will align with Runtime and Security Model for Web Applications spec, some existing Tizen WRT features will not valid for Crosswalk, while some others may need to be added or ported for Tizen platform.
- Runtime model lifecycle support with Tizen application core
- Web API binding with native system components
- system package management binding, including binding with pkgmgr, app settings with VCONF, application info registration
- app control and URI schemes support, export app capabilities and call or called by other apps(including native) through AUL
- design how will Security model be working with Chromium Sandbox and Tizen SMACK layer.
- AppWidget support