Page History

...

ID	Text
297	We anticipate that vendors will wish to introduce non-standardized metadata, either as a prototype for future standardization or to support vendor-specific additional requirements. It must be possible to include new metadata fields in an entry point, without coordination with a central authority.
	Comments:
	Extracted requirement:

ID	Text
301	For example, this could be achieved by namespacing new metadata fields using a DNS name (as is done in D-Bus), namespacing them with a URI (as is done in XML), or using the X-Vendor-NewMetadataField convention (as is done in email headers, HTTP headers and freedesktop.org .desktop files).
	Comments: GA: Yes. Needs discussion, to decide something. GA: Did anyone make notes from previous call discussion? I don't understand what people prefer here - make proposals, vote, and reach a conclusion. PW: Guru said he was taking notes, but they haven't materialised here yet. From what I remember, this question is determined by the choice of metadata format for entry points. So since we've decided to go with .desktop files, the namespacing must use the X-Vendor-NewMetadataField scheme. [App FW telco - 15-11-2016] : Agreed.
	Extracted requirement:

ID	Text
305	Because of the requirement that ordinary app bundles are not allowed to enumerate other app bundles or entry points, if a launcher is implemented as a user-installable app bundle (as is sometimes done on Android), it must have a special permissions flag allowing it to carry out that restricted action.
	Comments: GA: OK. Not sure if this is a requirement from any OEM (to have a use-installable launcher). It could be implemented using an app permission, or by having "native" privileged APIs not available to any app. [App FW telco - 15-11-2016] PW : e.g. third party call on system bus may not be allowed.As this needs fine grain access control. This can complicate or make things complex. GA : Agreed to go ahead with the existing requirement
	Extracted requirement:

ID	Text
309	Some entry points might be flagged to not be visible in menus. For example, an app that is a viewer for some file type such as PDF might register itself as a handler for files of that type, but might not have anything useful to do if it appears in menus otherwise.
	Comments: GA: This seems to be a policy question. Requirement is only to make this possible? GA: (I need another discussion on definition of entry point, visible vs background apps etc...) PW: It’s not really a policy question, it’s more of an implementation question for the app developer. In the case of an entry point for handling PDF files, if the app doesn’t do anything unless given the path to a PDF file, it’s not going to make sense to display that entry point in menus on any vendor’s system. JK: OK for another use case (e.g. hide an app icon from the launcher w/o removing) but agreed w/ Gunnar. The use case above is based on the assumption that an entry point to handling PDF shall be defined as other entry points having an icon, which needs discussion. [App FW telco - 15-11-2016] : This should be left to the policy handling
	Extracted requirement:

ID	Text
312	Entry point metadata must indicate whether the entry point is to be visible in menus.
	Comments:
	Extracted requirement:

ID	Text
313	The mechanism used by the launcher to list entry points may either include or exclude invisible entry points. If it does include those entry points, it must also provide the launcher with an indication that they are to be made invisible.
	Comments:
	Extracted requirement:

ID	Text
316	When the user selects an entry point, the expectation is that the program that implements that entry point should be launched.
	Comments:
	Extracted requirement:

ID	Text
318	If the program that implements the entry point is not already running, the system must run it. (See also life-cycle management.)
	Comments:
	Extracted requirement:

ID	Text
320	The program might implement more than one entry point. It must be told which entry point was launched, for example via command-line arguments or an inter-process communication call.
	Comments:
	Extracted requirement:

ID	Text
323	We do not anticipate that ordinary (non-launcher) app bundles would have a reason to launch specific entry points in this way: we expect that if app bundles need to communicate, they will do so via document launching, URI launching or data sharing. This does not preclude one executable in a bundle from running another executable in the same bundle directly.
	Comments:
	Extracted requirement:

ID	Text
328	Open question: Do ordinary app bundles need to be allowed to launch other bundles' entry points by name? If so, why?
	Comments:
	Extracted requirement:

ID	Text
330	Android does allow this, but Android does not appear to provide app confidentiality.
	Comments:
	Extracted requirement:

ID	Text
331	One possible use-case for a program launching a program outside its bundle would be to bring up the system settings. For example, Android apps that make use of location services often have a shortcut button to bring up the Location panel in the built-in Settings app, because the user-installable app would not be able to enable location itself, but its author wishes to make it easy for the user to do so.
	Comments:
	Extracted requirement:

ID	Text
336	However, a vendor-specific Settings app is part of the platform rather than being a user-installable app bundle, so the constraints applying to it and the APIs that can be used with it do not have to be the same as for app bundles.
	Comments:
	Extracted requirement:

ID	Text
339	This would also be easy to implement without launching the Settings app by name: the built-in Settings app could register for URI launching as the launcher of a URI scheme, similar to the way the iOS Settings app used to register the prefs URI scheme, and the user-installable app could launch a URI of that scheme.
	Comments:
	Extracted requirement:

...

Document launching

ID	Text
344	Some app entry points will provide handlers for particular file types.
	Comments: GN :
	Extracted requirement:

ID	Text
345	An entry point must be able to identify the file types that it can receive. For example, a document viewer might register itself to receive Microsoft Word documents, Open Document Text files, and PDFs.\|
	Comments:
	Extracted requirement:

ID	Text
348	We recommend that these are identified via IETF media types (also known as content types or MIME types), because the IETF media types are an extensible standard, are ubiquitous in existing operating system environments such as Windows, OS X, Android and freedesktop-based environments such as GNOME, and are part of key Internet technologies such as HTTP and email.
	Comments: GN : This needs to be translated into requirement. GA: IETF, but a human readable name also needed right? PW: We assume that there is a separate mapping from IETF media types to human readable names for the file types. This exists as the Shared MIME-Info database on Linux systems. [App FW telco - 15-11-2016] : Agreed
	Extracted requirement:

ID	Text
353	The app framework must be able to identify the format of a file on secondary storage (flash), for example via its extension or "magic number". Unidentified files must be considered to have a documented generic format, for example application/octetstream in the IETF media type system.
	Comments:
	Extracted requirement:

ID	Text
357	Open question: it has been suggested that app-bundles should be able to define their own new file types. Is this a requirement?
	Comments: GN :Could you provide a use case why such a requirement is needed? PW: This would be needed if an app needed to save files in a format which does not currently have a standard content-type, and then have those files launch it when they are selected in the file manager. i.e. The cases where an app needs to register a new entry in the MIME magic database. \\\\\\\\\\\\\\\\\\\\\\\\\\\ GA: IMHO the possibility to do it is a requirement. To allow it or not is OEM policy. PW: Agreed, if we want to allow it at all (see the discussion below). JK: Agreed [App FW telco - 15-11-2016] : Agreed.
	Extracted requirement:

ID	Text
359	This requirement seems unwise from the point of view of system integrity: if an appbundle can define its own file types with their own extensions and/or "magic numbers", then it can introduce a conflict with other app-bundles or even alter the interpretation of existing files.
	Comments: GN :Could you provide a use case why such a requirement is needed? PW: The use case for preventing this is to prevent applications from assigning conflicting content types to existing files. A file can only have one content type, and if the MIME magic database is coerced into assigning the wrong type for it, the file will end up being opened with the wrong application. \\\\\\\\\\\\\\\\\\\\\\\\\\\ GA: Let's dig deeper into the risks/opportunities of this. Mitigation for conflicts? Do you mean can be defined at run-time or can be defined in manifest? PW: MIME type associations would have to be defined in manifests. They cannot be defined at application run-time because the system needs to know the magic bytes for a file type before it can work out which application to launch it with. However, manifests are trusted to have been audited when the application was submitted to the vendor, so we should be able to trust that each manifest only defines MIME types for file formats under control of that application’s author. And hence we should be able to guarantee there are no conflicts. So overall, I think I disagree with this part of the document (that allowing new MIME types to be defined is a risk), and think we should be able to allow it safely. [App FW telco - 15-11-2016] : GA : Rephrase as a recommendation to the policy maker. PW - Agreed.
	Extracted requirement:

ID	Text
363	If this is implemented at all, we recommend that it should be tightly controlled by app-store curators.
	Comments: GA: Supplementary text / guideline. OK.
	Extracted requirement:

ID	Text
365	Choice of document handler: When a file is activated (for example by tapping its icon) from a non-app context such as the home screen, the app framework must locate the entry points that are able to handle that file. It must either choose one of those entry points for use, or prompt the user to choose one.
	Comments: GN : Ok
	Extracted requirement:

ID	Text
369	When a file is activated from the context of an app (the initiating app), for example if the user activates an attachment in an email app, the app framework must behave similarly. It may opt to follow a different policy for choosing the correct entry point in this case; for example, it might prompt the user for confirmation even if there is only one possible handler.
	Comments: GN : OK as Requirement
	Extracted requirement:

ID	Text
374	System vendors must be able to force a particular app to handle particular file types. For example, a vendor might wish to make their video player handle all videos.
	Comments: GN : OK as requirement.
	Extracted requirement:

ID	Text
376	If no handler is available for the selected file type, the app framework should arrange for a suitable fallback to be displayed. For example, it might show an error message, or it might launch its app store user interface with a search query for the handlers for that file type.
	Comments: GN : Error handling requirement and choice should be left to vendor/OE specific handling PW: I think the intention here is that the error handling is left as a policy decision for the vendor. [App FW telco - 15-11-2016] : Vendor specific. OK
	Extracted requirement:

ID	Text
380	No feedback to initiator: It should do this itself or by interacting with other system components instead of feeding back an error code to the initiating app (if any), because otherwise the initiating app would be able to use this as an "oracle" to gather information about the set of installed app bundles.
	Comments: GN : Ok as requirement.
	Extracted requirement:

ID	Text
384	User confirmation: If exactly one handler is available for the selected file type, the app framework may launch it directly, or ask the user for confirmation. If the user cancels a request for confirmation, the app framework should neither launch the handler nor feed back an error code to the initiating app.
	Comments: GN : Error handling requirement and choice should be left to vendor/OE specific handling PW: All behaviour apart from what is required here is left as a policy decision for the vendor. The features mandated in this line are needed for security — not feeding back an error code is required to prevent acting as an oracle for the number of apps installed which can handle the given content type, which is an indicator of which apps the user has installed (especially for uncommon content types). GA: The possibility of user confirmation seems to be repeated from previous text. Simplify? PW: Are you referring to line 369? I don’t think there’s any harm in explicitly repeating the possibility here. [App FW telco - 15-11-2016] OK
	Extracted requirement:

ID	Text
388	If more than one handler is available for the selected file type, the app framework may launch a preferred handler directly, or ask the user to make the choice. If the user cancels a request for app choice, the app framework should neither launch a handler nor feed back an error code to the initiating app.
	Comments: GN : Error handling requirement and choice should be left to vendor/OE specific handling PW: See my comment for ID 384. [App FW telco - 15-11-2016] OK
	Extracted requirement:

ID	Text
392	The app framework must arrange for the file's content to be made available in a location where the chosen app can read it (see sandboxing and security).
	Comments:
	Extracted requirement:

ID	Text
394	If the program that implements the entry point is not already running, the system must run it. (See also life-cycle management.)
	Comments: GN : Could this be a vendor specific. It could be that system has not reached a state / condition which is a prerequisite for the launch an any app. PW: We were assuming that the system would either pause the app launch until it is in a state to launch apps, or not allow entry points to be spawned until that time. i.e. That it can synchronise on its own state.
	Extracted requirement:

ID	Text
396	The program must be told that it was launched to open a file, and given the filename of the file to open, for example via command-line arguments or an inter-process communication call. The filename that it is given might differ from the original file that was activated, for example if the file had to be copied or linked across a privilege boundary to be made available in the program's sandbox. The program must be able to distinguish between this action and ordinary app launching.
	Comments: GN : What could be a requirement for App FW? PW: I suggest the final sentence becomes the requirement. [App FW telco - 15-11-2016] : OK
	Extracted requirement:

ID	Text
402	Programs should be careful not to treat documents received in this way as executable code, or assume that the source of the document is trustworthy. For example, macro languages in "office" document formats should be disabled, and if arbitrary code execution in a program can be triggered by a malformed document, this should be considered to be a security vulnerability.
	Comments: GN : OK.
	Extracted requirement:

ID	Text
407	We do not anticipate a need for the initiating app to be able to influence the choice of launched app.
	Comments:GN :OK, what requirement can be framed from this? PW: I don’t think there is a concrete requirement in either direction here. [App FW telco - 15-11-2016] : Info text
	Extracted requirement:

ID	Text
409	If the initiating app could influence the choice of launched app, a malicious app could potentially use this to break or undermine app confidentiality. For example, suppose org.example.Secret opens .secret files. If the app com.example.Spy wanted to determine whether org.example.Secret was installed, it could register an entry point com.example.Spy.SecretHandler which also opens .secret files, create a .secret document, and launch that document specifying org.example.Secret and com.example.Spy.SecretHandler (in that order) as the preferred handlers. If com.example.Spy.SecretHandler was launched, then com.example.Spy could be sure that org.example.Secret was not installed. Conversely, if com.example.Spy.SecretHandler was not launched, then com.example.Spy could infer that org.example.Secret was likely to be installed.
	Comments: GN : OK
	Extracted requirement:

ID	Text
420	Apertis Content Hand-over Use Cases contains some similar requirements-capture that was carried out for the Apertis platform.
	Comments: GN:OK
	Extracted requirement:

...

URI launching

ID	Text
423	Some app entry points will provide handlers for particular URI schemes such as https, mailto or skype.\|
	Comments: GN:OK
	Extracted requirement:

ID	Text
425	file URIs must not be included in this mechanism. Instead, they should be decoded into filenames and processed via document launching.
	Comments: GN:OK
	Extracted requirement:

ID	Text
427	An entry point must be able to identify the URI schemes that it can receive. For example, a multi-protocol voice-over-IP client might support receiving sip and xmpp URIs.
	Comments: GN : Can this be a requirement? PW: Yes. In general I think that anything phrased as ‘must’ in the document should become a requirement. [App FW telco - 15-11-2016] : GN : Its a part of manifest field, PW - Yes its a std key
	Extracted requirement:

ID	Text
430	When a URI is activated, the app framework must locate the entry points that are able to handle that URI and choose one for launching, much like file type handling. The same points about choice of handler, user confirmation, and lack of feedback to the initiating app apply equally here.
	Comments:
	Extracted requirement:

ID	Text
434	As with URI schemes, system vendors must be able to force a particular app to handle particular URIs. For example, a vendor might wish to make their built-in web browser handle all http and https URIs.
	Comments:
	Extracted requirement:

ID	Text
437	If the program that implements the entry point is not already running, the system must run it. (See also life-cycle management.)
	Comments: GN : Could this be a vendor specific. It could be that system has not reached a state / condition which is a prerequisite for the launch an any app. PW: See my comments on ID 394. [App FW telco - 15-11-2016] : OK
	Extracted requirement:

ID	Text
439	The program must be told that it was launched to open a URI, and given the URI to open, for example via command-line arguments or an inter-process communication call. The program must be able to distinguish between this action, document launching and ordinary app launching.
	Comments:
	Extracted requirement:

ID	Text
443	As with document launching, we do not anticipate a need for the initiating app to be able to influence the choice of launched app, but system components might need to do so.
	Comments:
	Extracted requirement:

ID	Text
446	Programs should be careful not to interpret URIs in a way that a malicious or compromised initiating app could use to violate integrity, confidentiality or availability. For example, telephone calls and text messages (SMS) could cost money, distract the driver, or divulge sensitive information to a third party. As a result, an app that acts as a tel: URI handler may respond to URI launching by offering the user a choice of actions to carry out (for example "call" and "send SMS" buttons, perhaps with a text input widget pre-filled with SMS text taken from the URI), but must not actually initiate the call or send the SMS until the user requests it.
	Comments: GN : How this can be achieved? or is this always routed through system UI. Can this be a vendor specific for how to handle? PW: I think this needs to be URI-scheme-specific for how to handle it. It could be vendor specific, but vendors will likely come up with the same approaches since the problems are fairly constrained. I don’t have any more suggestions for how this could be achieved beyond what’s in the examples. [App FW telco - 15-11-2016] : OK. PW : Need to extract req from this.
	Extracted requirement:

ID	Text
454	Similarly, if a URI scheme is designed in such a way that dereferencing a URI can cause content to be modified or deleted (an unsafe request in HTTP terminology), then the program interpreting the URI should ask the user before proceeding.
	Comments:
	Extracted requirement:

ID	Text
457	Apertis Content Hand-over Use Cases contains some related requirements-capture that was carried out for the Apertis platform.
	Comments:
	Extracted requirement:

...

Content selection

ID	Text
460	App programs might wish to interact with data stored in locations that are not naturally accessible to the app. For example, an attachment to an email would be private data for the email app as run by the user whose email account is accessing it. However, we would like to avoid such data passing through a per-device data storage area that is shared between all apps (similar to Android's /sdcard), because in practice data passed between programs will typically include sensitive data such as photos and documents.
	Comments: GN : OK type : REQ
	Extracted requirement:

ID	Text
467	The solution that is used in Apple's iOS and planned for the Flatpak system is to have an API call that creates a file-opening or file-saving dialog. While visually presented as if it was part of the requesting app, this dialog actually exists outside the app's security context (it is privileged), and it is able to browse all of the user's files. iOS calls this the Document Picker, while Flatpak calls it the Document Portal.
	Comments: GN : OKtype : INFO
	Extracted requirement:

ID	Text
472	The app framework should provide a way to ask the user to browse for a file to open for reading, similar in principle to the conventional "Open" dialog on desktop operating systems.
	Comments: GN : OKtype : Info
	Extracted requirement:

ID	Text
475	If the user does so, the framework must make this file available to the app program for reading.
	Comments: GN:OK type : REQ
	Extracted requirement:

ID	Text
477	If the user cancels this prompt, the framework must indicate this to the requesting app, and must not grant it any additional access to any files.
	Comments: GN : OKtype : REQ
	Extracted requirement:

ID	Text
479	The app framework should provide a way to ask the user to browse to a location in which to write a file, and simultaneously choose a name for that file.
	Comments: GN : OKtype : REQ
	Extracted requirement:

ID	Text
481	As above, depending on the user's choice, the framework must either provide a way for the app to write to that location and name, or indicate cancellation and not provide any additional access.
	Comments: GN : OKtype : REQ
	Extracted requirement:

ID	Text
484	If the user selects an existing file outside the app's sandbox, it must be overwritten atomically if the underlying filesystem supports that.
	Comments: GN : OK
	Extracted requirement:

ID	Text
486	The app framework may provide specialized versions of this functionality for specific file types, in particular images/photos.
	Comments: GN : What do yo mean by specialized versions? what probably can be covered? PW: For example, by providing an image preview in the file selection dialogue. This can be clarified in the text. [App FW telco - 15-11-2016] : GA : Replace functionality with more explicit info. PW : OK
	Extracted requirement:

...

Data sharing

ID	Text
489	The system might require the ability to enumerate the implementations of a particular service or set of functionality. In this document we will refer to that set of functionality as an interface. One use-case for this is that a global search facility within the platform needs to discover a list of background services (entry points) within app bundles that can provide search results in response to user queries entered into some global search UI; for example, a Spotify client could use the search term to match artists or songs.
	Comments: GN:OK type : UseCase
	Extracted requirement:

ID	Text
495	Suitably privileged components of the system must be able to enumerate the implementations of an interface.
	Comments: GN : OK
	Extracted requirement:

ID	Text
497	Suitably privileged components of the system must be able to communicate with the implementations of an interface.
	Comments: GN : OK type : REQ
	Extracted requirement:

ID	Text
499	If the system initiates communication with an implementation of an interface that is not already running, the app framework must arrange for the implementation (an entry point) to be started.
	Comments: GN : OK type : REQ
	Extracted requirement:

ID	Text
502	An app might also require the ability to enumerate the implementations of a particular interface. One example use-case here is that if an app will display a Sharing menu similar to the UX seen in Android, it needs to be able to list the apps with which files or data can be shared, in order to populate that menu. Due to the app confidentiality requirement, this should only be allowed if the interface in question is one whose implementors are aware that it will result in other apps being able to enumerate their apps. In this document we will refer to this as a public interface.
	Comments: GN : OK type : UseCase and info
	Extracted requirement:

ID	Text
509	An app with appropriate app permissions must be able to enumerate the implementors of a public interface.
	Comments: GN : OK type : REQ
	Extracted requirement:

ID	Text
511	Depending on the system and the interface in question, a special permission flag per public interface might be required to list the implementors, or that information might be available to every application.
	Comments: GN : OK type : REQ
	Extracted requirement:

ID	Text
514	An app with appropriate app permissions must be able to communicate with all of the implementors of a public interface, for example via an inter-process communication channel such as D-Bus.
	Comments: GN : OK
	Extracted requirement:

ID	Text
517	If an app initiates communication with an implementation of an interface that is not already running, the app framework must arrange for the implementation (an entry point) to be started.
	Comments: GN : similar to ID 499
	Extracted requirement:

ID	Text
520	The Apertis Interface Discovery design and Apertis Data Sharing design describe use-cases, requirements and proposed implementations for this topic in the Apertis system.
	Comments: GN : OK type : info
	Extracted requirement:

...

Sharing menu

ID	Text
523	One specific use-case for data sharing is a menu for sharing content with other users, for example via social media, email or real-time communications, similar to the Android Sharing menu.
	Comments: GN : OK type : UseCase
	Extracted requirement:

ID	Text
526	Two possible UXs for this facility are presented in the Apertis Sharing design. Each UX motivates rather different requirements for how this facility interacts with apps, and in particular its impact on app confidentiality.
	Comments: GN : OK type : info
	Extracted requirement:

ID	Text
529	Open question: Is this in the scope of the application framework? If it is, which UX do we intend to support?
	Comments: GN : Ux is not in the scope of App FW. However any interface that need to be exposed to UX should be taken care of. PW: UX is not in scope, indeed; but we need to know which of the UXs needs to be supported (both?), as it affects the underlying API. [App FW telco - 15-11-2016] : OK, agreed.
	Extracted requirement:

...

Life-cycle management

ID	Text
532	Under various circumstances (including those described in app launching, document launching, URI launching and data sharing), the system must be able to start a program provided by an app bundle.
	Comments: GN : OK GM : OK type : REQ
	Extracted requirement:

ID	Text
535	This topic overlaps with the functionality of the GENIVI Node Startup Controller, and more generally the GENIVI Lifecycle cluster. It should potentially be considered to be an orthogonal topic outside the scope of the App Framework design. Some requirements in this area are outlined here in the hope that they can be used to clarify the division of responsibilities.
	Comments: GN : OK GM : OK type : info
	Extracted requirement:

ID	Text
540	The possible states of a program in an app are as follows:
	Not installed
	Inactive (installed but not running)
	Running
	Paused The valid state transitions move linearly through that list in single steps, as follows:
	Not installed → inactive: install app bundle
	Inactive → running: start (launch), see this section
	Running → paused: pause, see this section
	Paused → running: unpause, see this section
	Running → inactive: stop (kill, terminate), see this section
	Inactive → not installed: remove app bundle
	Comments: GN : When in the Running state how the background or foreground of an app is handled? If this is left to the App how App FW will not about which apps been shown in foreground and which are in background? PW: It’s assumed that the foreground/background state of an application is basically orthogonal to its inactive/running/paused state, to the extent that inactive apps have no processes running; running apps can be in the background or foreground; paused apps can be in the background or foreground (but the (paused, foreground) state probably only makes sense transitionally). Multiple apps could be (running, foreground) if the vendor supported presenting multiple apps on the screen at once (i.e. a tiling window manager). type : REQ [App FW telco - 15-11-2016] : PW : this is covered in LCM f/w, GA, GN : Its a different philosophy. Here we need it at the App Level. agreed.
	Extracted requirement:

ID	Text
552	Transitions do not skip a step: for example, a paused app process cannot be stopped without first unpausing it, and an app bundle cannot be removed until all of its processes have been stopped.
	Comments: GN : OK GM : OK type : REQ
	Extracted requirement:

ID	Text
555	Open question: some GENIVI documents have the concept of "activating" a program, which appears to be distinct from launching it. Does this correspond to selection, similar to single-clicking an icon in a desktop environment where double-clicking would cause launching; or does it represent a transition away from an intermediate state where a newly installed app is unavailable until an activation, enabling or licensing step has been performed, similar to the concept of activating a Windows installation; or is it something else?
	Comments: GA: Please reference the document in question. PW: I’m not sure which document Simon was referring to. I’ll try to find out.
	Extracted requirement:

ID	Text
562	As a prerequisite for sandboxing and security, app processes must be identifiable.
	Comments: GN : OK GM : OK type : REQ
	Extracted requirement:

ID	Text
563	The app framework must be able to start processes, either directly or by asking a separate service manager such as the Node Startup Controller to start them.
	Comments: GN : Can this be a vendor specific? PW: I suspect the mechanism for starting processes will be vendor-specific. The requirement that the app framework must be able to start processes is a requirement for all vendors. type : REQ
	Extracted requirement:

ID	Text
565	Process tagging: each process executing code from an app bundle must be marked with the unique identifier of that bundle (for example by placing it in a suitably named cgroup or by running it under a suitable LSM context). Those processes and their child processes, whether running the same or a different executable from the app bundle or running an executable provided by the system, must not be able to enter a state where they are no longer identifiable as belonging to their bundle.
	Comments:
	Extracted requirement:

ID	Text
572	Depending on the vendor's UX design and the app author's UX design, the entry point might start in a default state, or it might start by restoring the last-used context. The app framework should be able to send a hint that indicates which of these modes is preferred (see the section on Last-used context).
	Comments: GN: OK
	Extracted requirement:

ID	Text
576	The application launch has various interactions with the graphical user interface. See Apertis Compositor Security design for more detailed requirements-capture for the interaction between the GUI shell and apps. The Apertis design assumes that the compositor and the GUI shell are combined, as was done in Apertis' Mildenhall reference UI and in GNOME's GNOME Shell. In a system where the GUI shell and compositor are separate, those requirements should be read as being requirements for the combined system consisting of the GUI shell and the compositor.
	Comments:
	Extracted requirement:

ID	Text
583	Processes may request that windows (surfaces, layers) are displayed. The GUI shell must be able to identify the app bundle to which a window belongs, so that it can instruct the compositor (layer manager) to display it (or not display it) according to its UX policy.
	Comments:
	Extracted requirement:

ID	Text
587	The GUI shell must be able to identify which windows belong to the same user-facing app, so that they can be associated visually, and so that it can prevent apps from setting up misleading situations like a dialog from one app drawn over another app's window.
	Comments:
	Extracted requirement:

ID	Text
591	The GUI shell might have an application-switcher similar to the one in Android. It must be possible to mark each app's collection of windows with a name and icon as is done in Android. This is important for the integrity of the UX — otherwise, it would be impossible for the user to tell which app is producing a given window, for example to see which app is responsible for an advertising popup (output integrity), or which app is requesting entry of a password (input integrity).
	Comments:
	Extracted requirement:

ID	Text
597	If application launching is in progress but no window has been displayed yet, the framework must avoid focus stealing: in other words, it must ensure that input intended to go to the previous foreground window in a particular screen area is not inadvertently directed to a window presented by the newly launched application.
	Comments:
	Extracted requirement:

JOIN/SIGN UP

GET INVOLVED

COLLABORATIVE PROJECTS

HISTORICAL

Events

Industry Events

COVESA Events

Contact Us

Child pages

Versions Compared

Old Version 7

New Version 8

Key

Document launching

URI launching

Content selection

Data sharing

Sharing menu

Life-cycle management