JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project |
...
ID | Text |
---|---|
297 |
|
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 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
313 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
320 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
330 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
331 |
|
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: |
...
ID | Text |
---|---|
344 | Some app entry points will provide handlers for particular file types. |
Comments: GN : | |
Extracted requirement: |
ID | Text |
---|---|
345 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
348 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
357 |
|
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 |
|
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 |
|
Comments: GN : Ok | |
Extracted requirement: |
ID | Text |
---|---|
369 |
|
Comments: GN : OK as Requirement | |
Extracted requirement: |
ID | Text |
---|---|
374 |
|
Comments: GN : OK as requirement. | |
Extracted requirement: |
ID | Text |
---|---|
376 |
|
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 |
|
Comments: GN : Ok as requirement. | |
Extracted requirement: |
ID | Text |
---|---|
384 |
|
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 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
394 |
|
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 |
|
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 |
|
Comments: GN : OK. | |
Extracted requirement: |
ID | Text |
---|---|
407 |
|
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 |
|
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: |
...
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 |
|
Comments: GN:OK | |
Extracted requirement: |
ID | Text |
---|---|
427 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
434 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
437 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
443 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
446 |
|
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: |
...
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 |
|
Comments: GN : OKtype : Info | |
Extracted requirement: |
ID | Text |
---|---|
475 |
|
Comments: GN:OK type : REQ | |
Extracted requirement: |
ID | Text |
---|---|
477 |
|
Comments: GN : OKtype : REQ | |
Extracted requirement: |
ID | Text |
---|---|
479 |
|
Comments: GN : OKtype : REQ | |
Extracted requirement: |
ID | Text |
---|---|
481 |
|
Comments: GN : OKtype : REQ | |
Extracted requirement: |
ID | Text |
---|---|
484 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
486 |
|
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: |
...
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 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
497 |
|
Comments: GN : OK type : REQ | |
Extracted requirement: |
ID | Text |
---|---|
499 |
|
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 |
|
Comments: GN : OK type : REQ | |
Extracted requirement: |
ID | Text |
---|---|
511 |
|
Comments: GN : OK type : REQ | |
Extracted requirement: |
ID | Text |
---|---|
514 |
|
Comments: GN : OK | |
Extracted requirement: |
ID | Text |
---|---|
517 |
|
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: |
...
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: |
...
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: |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
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 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
572 |
|
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 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
587 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
591 |
|
Comments: | |
Extracted requirement: |
ID | Text |
---|---|
597 |
|
Comments: | |
Extracted requirement: |