Page History

...

NOTE: Initial IDs are assigned equal to the line number in the original document.

copy here

ID	Text
25	There are two commonly-used definitions of an "app": either a user-facing launchable program (an entry point) such as would appear in launcher menus, or a user-installable package or bundle such as would appear in an app store.
	Comments: GN - info - Within GENIVI scope, 'Managed Apps' and 'Native Applications' has been defined GA: A fair assumption is that a bundle will never contain both managed and native apps and an app is either native or managed. I think we are fine with the current definitions and they can be used in combination with the defintions here without any conflict between them. GA: A clear definition of "bundle" would help here (because of later usage e.g. entry-points) GM: Please clarify how this definition is related to "Managed Applications" and "Native Applications" as defined inside the GENIVI Reference Architecture GM: Also "package or bundle" should be better defined (notice that the GENIVI Compliance Specification already defines a "Package Manager") PW: ‘bundle’ is defined on line 27 as a concept similar to an app on Android, for example. The definition is refined over the course of the document. We could try and expand the summary here a bit. GA: This week 2016-11-08 it seems we said that Bundle = A collection of zero or more executable files, zero or more libraries and zero or more meta-data files (for the last case imagine for example a "Skinning/theming bundle containing Icon graphics and configuration files only.". In an app store what would be presented to the user as one app would technically be downloaded as one bundle of files.
	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:

ID	Text
601	One possible implementation is to disable input, send the previous app to the background, or display a placeholder while waiting for a launched app to become available, so that the app cannot appear while the user is halfway through another interaction with the previous app.
	Comments:
	Extracted requirement:

ID	Text
605	Another possible implementation is to track whether user continues to interact with the previous app, and if they do, keep the previous app in the foreground and place the newly launched app's window in the background when it appears.
	Comments:
	Extracted requirement:

ID	Text
608	To improve perceived responsiveness, the GUI shell might display an indication that a particular entry point or app is starting.
	Comments:
	Extracted requirement:

ID	Text
610	Startup notification (successful case): the GUI shell must be notified by the life-cycle manager when a particular entry point is starting. It must also be notified when the entry point becomes available, either explicitly (another notification from the lifecycle manager) or implicitly (a window is displayed by the appropriate app-bundle with the entry point's identifier as metadata) so that it can withdraw the indication.
	Comments:
	Extracted requirement:

ID	Text
615	To meet the app confidentiality requirement, these notifications must not be visible to other apps.
	Comments:
	Extracted requirement:

ID	Text
617	Startup notification (unsuccessful case): the GUI shell should be notified by the lifecycle manager when an attempt to start a particular entry point fails, so that it can withdraw the indication and display a warning instead.
	Comments:
	Extracted requirement:

ID	Text
620	To meet the app confidentiality requirement, these notifications must not be visible to other apps. If an app program crashes or otherwise exits unexpectedly, the system might restart it.
	Comments:
	Extracted requirement:

ID	Text
623	This must be rate-limited, to avoid infinite restart loops that could consume disproportionately many CPU cycles. For example, apps might be configured such that more than n restarts within t seconds will cause further attempts to restart the app to be abandoned. For responsiveness, we recommend that the restart counter and time are reset when the user specifically launches an entry point.
	Comments:
	Extracted requirement:

ID	Text
628	An app program might have costly graphical processing which its author wants it to stop doing while not visible.
	Comments:
	Extracted requirement:

ID	Text
630	Open question: Are these requirements regarding visibility applicable to the application framework, or to life-cycle management, or are they in the scope of the compositor or the combined system consisting of the compositor and GUI shell?
	Comments:
	Extracted requirement:

ID	Text
633	The app framework should send a notification to the app program at each transition from one or more windows visible to no windows visible, telling it that it has been moved to the background (become invisible).
	Comments:
	Extracted requirement:

ID	Text
636	The app may still paint its window(s) while in the background. Their new contents must be used in any context where the app's windows would briefly become visible, for example as thumbnails in an app-chooser.
	Comments:
	Extracted requirement:

ID	Text
639	The app framework should send a notification to the app program before each transition from no windows visible to one or more windows fully visible, telling it that it has been moved to the foreground (become visible).
	Comments:
	Extracted requirement:

ID	Text
642	Until the app can redraw itself, its last known window contents must be painted. The app framework will sometimes stop apps from running, most obviously due to user request or during device shutdown. It may also stop apps if they are running in the background and there is insufficient RAM for a user-requested operation such as starting a new app, similar to the behavior of background apps in Android.
	Comments:
	Extracted requirement:

ID	Text
647	The app framework should have a mechanism to send a request to the app process, asking it to terminate itself gracefully. (For example, systemd uses SIGTERM for the equivalent request to its managed processes.)
	Comments:
	Extracted requirement:

ID	Text
650	A well-behaved app process should respond to this request by saving its state and terminating. The app framework must detect its termination and consider this to be a successful stop.
	Comments:
	Extracted requirement:

ID	Text
653	The app process should update its last-used context as part of its response to this request, so that it can resume from the last-used context when started again.
	Comments:
	Extracted requirement:

ID	Text
655	If the app process does not terminate within a reasonable time (anticipated to be limited to a few seconds), the app framework must forcibly terminate it (kill it). It must not be possible for the app process to block this forcible termination. (For example, systemd uses SIGKILL for the equivalent request to its managed processes.)
	Comments:
	Extracted requirement:

ID	Text
659	If a stopped app is brought to the foreground, the app framework must arrange for it to be started with the last-used context.
	Comments:
	Extracted requirement:

ID	Text
661	If the app framework needs to remove (uninstall) an app bundle that has one or more running or paused programs, it must stop those programs before commencing removal. If those programs are paused, it must unpause each one before stopping it.
	Comments:
	Extracted requirement:

ID	Text
664	If the system has a relatively large amount of RAM but a relatively slow CPU, it might be desirable to pause app processes that been sent to the background, preventing them from executing code. For example, the implementation might use SIGSTOP.
	Comments:
	Extracted requirement:

ID	Text
667	The app framework should have a mechanism to send a request to the app process, asking it to prepare for being paused.
	Comments:
	Extracted requirement:

ID	Text
669	The app process may respond to this request by finishing or canceling a pending operation. It should not start new operations unless they are expected to be fast.
	Comments:
	Extracted requirement:

ID	Text
671	The app process should update its last-used context as part of its response to this request, so that if power is lost, it can resume from the last-used context when started again.
	Comments:
	Extracted requirement:

ID	Text
674	If the app process responds to this request, it may be paused at any time after it has sent the response.
	Comments:
	Extracted requirement:

ID	Text
676	If the app process does not respond to this request promptly (implementationdefined, but expected to be of the order of magnitude of a few seconds), it will be paused anyway.
	Comments:
	Extracted requirement:

ID	Text
679	If the app framework notifies an app that it will be paused, but then decides that it will not actually pause the app (for example because it is brought to the foreground), it must notify the app as though it had been unpaused.
	Comments:
	Extracted requirement:

ID	Text
682	The app must be careful to process these notifications in-order, so that if an unpause request arrives while it is still processing a pause request, the pause request is canceled. Paused apps can be unpaused, at which point they will continue to execute.
	Comments:
	Extracted requirement:

ID	Text
686	If the app is brought to the foreground, the app framework must unpause it first.
	Comments:
	Extracted requirement:

ID	Text
687	If a request is to be processed by the app process, for example for data sharing, document launching or URI launching, it must be unpaused first.
	Comments:
	Extracted requirement:

ID	Text
689	If the app framework needs to stop an app program that is paused, it must unpause that app, then stop it.
	Comments:
	Extracted requirement:

ID	Text
691	Whenever the app is unpaused, it must resume execution from the point at which it was paused, analogous to a laptop that has been placed in a "suspend to RAM" state. Shortly after it resumes execution, the app framework must either notify it that it has been unpaused, so that it can resume normal operation, or notify it that it is to be stopped, so that it can terminate itself gracefully.
	Comments:
	Extracted requirement:

ID	Text
696	The app must be careful to process these notifications in-order, so that if an unpause request arrives while it is still processing a pause request (perhaps one for which the app framework timed out and paused it before it had responded), the pause request is canceled.
	Comments:
	Extracted requirement:

ID	Text
700	Some design documents refer to the unpause operation as "restarting". We recommend avoiding that term, since it can mislead developers into believing that it refers to terminating the app, waiting for it to terminate, and starting it again, similar to systemctl restart.
	Comments:
	Extracted requirement:

ID	Text
704	Under some circumstances, other system components might forbid an app from being launched. For example, if an app is found to have a serious security vulnerability or contain malicious code, the system might mark it as forbidden.
	Comments:
	Extracted requirement:

ID	Text
707	Other system components must be able to mark an installed app as forbidden. Newly forbidden apps must be stopped immediately (if running or paused), and all attempts to run them must be rejected.
	Comments:
	Extracted requirement:

ID	Text
710	A bundle might be marked as forbidden because it contains a serious security vulnerability.
	Comments:
	Extracted requirement:

ID	Text
712	A bundle might be marked as forbidden because it has been found to contain malicious code.
	Comments:
	Extracted requirement:

ID	Text
714	A bundle might be marked as forbidden due to conditional access.
	Comments:
	Extracted requirement:

ID	Text
715	Open question: is there a requirement that we can mark bundles or entry points as forbidden under specific operating conditions, for example at speeds over 20mph or at night?
	Comments:
	Extracted requirement:

ID	Text
718	Whether a bundle is forbidden might be tracked per-user.
	Comments:
	Extracted requirement:

ID	Text
719	A parent might use a parental control interface to mark a bundle as forbidden for their child's user account, or to limit use time so that the bundle automatically becomes forbidden after 10 minutes of use per day.
	Comments:
	Extracted requirement:

ID	Text
722	In contexts where bundles or entry points are listed (for example by a launcher), the forbidden apps must be included in the list, with metadata indicating that they are currently unavailable. This enables vendors to make a UX decision whether to display forbidden apps (for example with a desaturated icon or a "forbidden" emblem indicating that they cannot be launched), or whether to hide them from the GUI altogether.
	Comments:
	Extracted requirement:

ID	Text
728	The system must be able to remove the forbidden state. After this has been done, the app may be run normally.
	Comments:
	Extracted requirement:

ID	Text
730	For example, if the app was forbidden due to a security vulnerability, the forbidden flag can be removed after upgrading it to a non-vulnerable version.
	Comments:
	Extracted requirement:

ID	Text
732	There could be multiple reasons why an installed app is forbidden. It must be considered to be forbidden if at least one of those reasons is still valid.
	Comments:
	Extracted requirement:

ID	Text
734	For example, if the app was forbidden due to a security vulnerability and also forbidden because its conditional-access license has expired, and an update has resolved the security vulnerability, the app must still be considered to be forbidden until a new license is obtained.
	Comments:
	Extracted requirement:

ID	Text
738	To avoid denial of service, unprivileged apps must not be able to mark apps as forbidden.
	Comments:
	Extracted requirement:

...

Last-used context

ID	Text
741	The system must allow each app to store a last-used context that encodes its user-visible state during its most recent use. The last-used context must be treated as private data.
	Comments:
	Extracted requirement:

ID	Text
744	If an app does not have any particular state, a reasonable fallback implementation is that its last-used context is the same as normal app launching. The extent to which state is saved is a quality-of-implementation issue for the individual apps: if a particular app does not save its state correctly, this is not considered a flaw in the app framework, as long as the app was given an opportunity to save its state.
	Comments:
	Extracted requirement:

ID	Text
749	Open question: do we want to require that the app is given the opportunity to save a snapshot of its window contents, so that they can be used by the GUI shell to represent the stopped app?
	Comments:
	Extracted requirement:

ID	Text
752	If we do, then they must be stored in a prescribed location/format to be understood by the GUI shell, whereas the rest of the last-used context does not have any particular requirement about the structure or even location of the last-used context.
	Comments:
	Extracted requirement:

ID	Text
755	Alternatively, this use-case could potentially be satisfied by having the GUI shell or compositor take a snapshot without the app's involvement.
	Comments:
	Extracted requirement:

ID	Text
757	As noted in Life-cycle management, the app program should be given the opportunity to save its last-used context before it is paused or stopped.
	Comments:
	Extracted requirement:

ID	Text
759	The app program may save its last-used context whenever its author wishes to do so. For example, a music player might save its last-used context after it starts playing each new track.
	Comments:
	Extracted requirement:

ID	Text
762	Long-running app programs should not save last-used context at arbitrary times (for example every 10 minutes), only when a significant event has occurred.
	Comments: JK: OK. Additionally, if an app is based on the external data/context (e.g. internet radio), it could not restore the last-used context. PW: Good point, we should add that.
	Extracted requirement:

ID	Text
764	The app framework must be able to notify app programs that now is a good time to save last-used context.
	Comments:
	Extracted requirement:

ID	Text
766	The app program may save its last-used context in response, but is not required to do so.
	Comments:
	Extracted requirement:

ID	Text
768	The app program should respond to this notification. If it does not, the app framework should wait for a reasonable time (anticipated to be a few seconds) and then proceed as though it had.
	Comments:
	Extracted requirement:

ID	Text
771	This is preferable to having long-running app programs save their state at an arbitrary time, because it gives the app framework the opportunity to influence the choice of arbitrary time. For example, the framework could notify the first app program, wait for a response, notify the second app program and so on.
	Comments:
	Extracted requirement:

ID	Text
775	When the app is launched without any particular parameters, it must have the opportunity to load its last-used context.
	Comments:
	Extracted requirement:

ID	Text
777	The app framework should give the app an indication of whether it is expected to load its last-used context or not.
	Comments:
	Extracted requirement:

ID	Text
779	Open question: do we expect this to be a boolean option (app should load LUC / app should not load LUC), or a tri-state (app should load LUC / app should not load LUC / app may decide)?
	Comments:
	Extracted requirement:

ID	Text
782	Whether/when the app actually loads its last-used context is a UX decision for the platform vendor and the app vendor.
	Comments:
	Extracted requirement:

ID	Text
784	When the app is launched for a specific purpose such as document launching or URI launching, that specific purpose takes precedence over the last-used context.
	Comments:
	Extracted requirement:

ID	Text
768	If the app is capable of having more than one simultaneous context (for example a web browser with multiple tabs or multiple windows), the purpose for which it was launched should take precedence (for example, a tabbed web browser should load the URI from URI launching as a new foreground tab). It may additionally load its lastused context (for example, a tabbed web browser might load all the tabs from its lastused context as low-priority background tabs).
	Comments:
	Extracted requirement:

ID	Text
792	The app framework should give the app an indication of whether, if possible, it is expected to load its last-used context in the background or not.
	Comments:
	Extracted requirement:

ID	Text
794	Whether/when the app actually loads LUC in this case is a UX decision for the platform vendor and the app vendor. The decision made here is not necessarily the same as the decision made during launching with no particular parameters.
	Comments:
	Extracted requirement:

ID	Text
797	The app framework must also be able to store its own last-used context, consisting of the visible (foreground) app programs, and optionally some or all of the app programs that were running and/or paused in the background.
	Comments:
	Extracted requirement:

ID	Text
800	On events such as a system reboot, the app framework may load its last-used context if desired. Whether to do this is a UX decision by the platform vendor. If it does:
	Comments:
	Extracted requirement:

ID	Text
802	The foreground app programs should be run, each with its own last-used context.
	Comments:
	Extracted requirement:

ID	Text
803	The background app programs may either be run with its last-used context, run with its last-used context and paused soon after, or left in the stopped state to be run with its last-used context later.
	Comments:
	Extracted requirement:

ID	Text
806	The app framework may use the background app programs' last known window contents as a placeholder for their app window.
	Comments:
	Extracted requirement:

ID	Text
808	Open question: is this something we want? If we do, we need either a requirement that the per-app LUC includes a snapshot of the window contents in a known location/format, or a requirement that the GUI shell or compositor can take the required snapshot.
	Comments:
	Extracted requirement:

...

Download management

ID	Text
813	Management of app-initiated downloads has been suggested as a topic that is potentially in the scope of the app framework. We feel that this should probably be considered to be an orthogonal topic, to be designed separately.
	Comments:
	Extracted requirement:

ID	Text
816	The platform should provide a HTTP download manager for use by apps. The download manager may also be used by platform components, but that is outside the scope of a standard interface.
	Comments:
	Extracted requirement:

ID	Text
819	It must be possible to have multiple downloads in parallel.
	Comments:
	Extracted requirement:

ID	Text
820	The system may have a limit on the maximum number of downloads that will proceed in parallel. If it does, additional downloads must be held in a queue, with one additional download resuming every time an active download finishes successfully or unsuccessfully. This limit may be user-configurable.
	Comments:
	Extracted requirement:

ID	Text
824	The system may start an arbitrary number of downloads in parallel, up to a specified bandwidth-usage limit. If it does, additional downloads must be held in a queue as above, with an additional download resuming when a heuristic indicates that there is enough bandwidth quota available. This limit may be user-configurable.
	Comments:
	Extracted requirement:

ID	Text
828	Pending downloads must be saved periodically, and should be saved before system shutdown, so that they can be resumed automatically on next startup if the server supports it.
	Comments:
	Extracted requirement:

ID	Text
831	Implementors should be aware that many servers do not support resuming HTTP downloads, either because they do not support the Range HTTP header properly or because an up-to-date session cookie is required.
	Comments:
	Extracted requirement:

ID	Text
834	The list of pending downloads and their progress and pause/resume states must be treated as private data:
	Comments:
	Extracted requirement:

ID	Text
836	Programs associated with an app bundle must be able to list, pause, resume and cancel the pending downloads that were started by that app bundle running as the same user.
	Comments:
	Extracted requirement:

ID	Text
839	The progress of each pending download must be updated regularly. If a program from the initiating app is running, it must be able to receive progress reports on that download without polling.
	Comments:
	Extracted requirement:

ID	Text
842	Programs associated with an app bundle must not be able to list, pause, resume or cancel the pending downloads that were started by a different app bundle.
	Comments:
	Extracted requirement:

ID	Text
844	Programs running as a user must not be able to list, pause, resume or cancel the pending downloads that were started by a different user.
	Comments:
	Extracted requirement:

ID	Text
846	The downloaded files themselves must be treated as private data:
	Comments:
	Extracted requirement:

ID	Text
847	When an app requests that a file is downloaded, it must either be downloaded into the private data area for that (user, app) pair, or into a temporary location that is not accessible by any app. When the download is completed, if it is in a temporary location, it must be moved into the private data area for that (user, app) pair.
	Comments:
	Extracted requirement:

ID	Text
851	It must not be possible for the app to trick the download manager into overwriting data outside its private data area, for example by creating a symbolic link and having the download manager traverse that symbolic link.
	Comments:
	Extracted requirement:

ID	Text
854	Programs associated with an app bundle must not be able to list, pause, resume or cancel the pending downloads that were started by a (non-app) platform component.
	Comments:
	Extracted requirement:

ID	Text
856	When a download that was initiated by an app finishes (successfully or unsuccessfully), the system must arrange for one of that app's entry points to be started (if not already running), unpaused (if paused), and notified about the status of the download. It has been suggested that the download manager should record a history of completed downloads per user, per app and/or per session.
	Comments:
	Extracted requirement:

ID	Text
862	Open question: What are the use cases for this feature?
	Comments:
	Extracted requirement:

ID	Text
863	If this is done, the user must be able to clear the history somehow. Without knowing the use cases for this history, we cannot say whether this should be functionality that is exposed to apps, or whether it should be considered to be a privileged action.
	Comments:
	Extracted requirement:

...

Installation management

ID	Text
867	Management of app bundle installation has been suggested as a topic that is potentially in the scope of the app framework. We feel that this should be considered to be an orthogonal topic, in the scope of the GENIVI Software Management 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
	Extracted requirement:

ID	Text
872	App bundles are expected to be user-installable, and may be updated on a schedule not matching the underlying platform.
	Comments: GN : OK
	Extracted requirement:

ID	Text
874	Installation: New app bundles can be installed, for example from an app store.
	Comments: GN : OK
	Extracted requirement:

ID	Text
875	It must be possible to install apps from removable storage media such as a USB thumb drive.
	Comments: GA: Optionally... I don't mind the capability being there, but not all systems will make this possible, presumably? PW: True, whether installing apps from removable media is allowed could be a vendor policy decision. Although if it’s not allowed, the system will most likely require an internet connection to install apps.
	Extracted requirement:

ID	Text
877	Upgrade: Installed app bundles can be replaced by a newer version.
	Comments: GN: OK
	Extracted requirement:

ID	Text
878	The system should check for upgrades periodically.
	Comments: GN : OK
	Extracted requirement:

ID	Text
879	All programs from the app bundle must be stopped (see Life-cycle management) before proceeding with the upgrade. They must be blocked from running until the upgrade is complete.
	Comments: GN : Can this be vendor specific? In android upgrade can happen while app being run. PW: That would make things a lot more complex, in terms of guaranteeing that the upgrade happened atomically so that the old version of a running app could not accidentally load a file from the new version. As I understand it, Android does kill the application at some point during the upgrade process. In any case, the application has to be restarted at some point in order to use the upgraded binaries.
	Extracted requirement:

ID	Text
882	If an app was installed from removable storage media, it must remain possible to upgrade it by other means (for example using an Internet connection).
	Comments: GN : OK
	Extracted requirement:

ID	Text
884	Rollback: When an app bundle is upgraded, the version that was available prior to the upgrade must be saved, together with the state of its private data and per-app data at the time of the upgrade. The user must be able to roll back to the saved version at any time.
	Comments:
	Extracted requirement:

ID	Text
888	Rollbacks are anticipated to be an unusual event, so the saved version may be compressed as a space/time trade-off, and its cached data may be deleted to minimize the storage cost.
	Comments:
	Extracted requirement:

ID	Text
891	All programs from the app bundle must be stopped (see Life-cycle management) before proceeding with the rollback.
	Comments:
	Extracted requirement:

ID	Text
893	Private and per-app data corresponding to the new version are not necessarily compatible with the saved version, so these must be rolled back too. Any changes made since the upgrade are lost.
	Comments:
	Extracted requirement:

ID	Text
896	Removal: The user must be able to remove an installed app bundle.
	Comments: GN : OK
	Extracted requirement:

ID	Text
897	All programs from the app bundle must be stopped (see Life-cycle management) before proceeding with the removal.
	Comments: GN : OK
	Extracted requirement:

ID	Text
899	The app bundle's private data and per-app data must be removed. This matches what is done on Android, and is necessary to prevent a "masque attack" in which a user is induced to install a malicious bundle of the same machine-readable name from a different origin (for example via social engineering), after which the malicious bundle would be able to gain access to the private and per-app data of the original bundle.
	Comments: GN : OK
	Extracted requirement:

ID	Text
904	Per-user data and per-device data must be unaffected.
	Comments: GN : OK
	Extracted requirement:

ID	Text
905	Open question: it has been suggested that there should be a requirement that apps must not download in parallel, with at most one app at a time actively downloading, and the rest queued.
	Comments: GA: Who suggests it and why? Let's discuss. I'm not sure this requirement is needed - isn't that controlled by the App Store and isn't it a (OEM) policy decision? PW: This is potentially an Apertis requirement, aimed at restricting the peak bandwidth a vehicle uses. It should probably be a vendor policy decision, yes.
	Extracted requirement:

ID	Text
908	Is this a requirement? This seems like something that should be a quality-ofimplementation decision for implementations: an implementation that expects to run on comparatively fast hardware might wish to maximize user convenience by carrying out downloads and installations in parallel, while an implementation that optimizes for implementor convenience or comparatively slow hardware might prefer to impose a limit of one download or installation at a time.
	Comments: GA: Agree, see above.
	Extracted requirement:

ID	Text
914	On a multi-user system, each user might wish to have a different set of apps installed. However, physically downloading and copying each app bundle for each user might be considered to be unacceptably inefficient.
	Comments:
	Extracted requirement:

ID	Text
917	When a user installs an app bundle that is not yet physically installed, the system must carry out the actual installation.
	Comments: GA: I'd like to discuss this. It pertains to Software download strategy, OEM policy, and I think it could be controlled by AppStore just as well the embedded system? PW: It pertains to the software download strategy, and the way that user accounts are separated and where apps are installed — if apps are installed in any kind of system-wide prefix, then the converse of this requirement is hard to meet. GA: I'd be just as happy leaving out this requirement - it adds little understanding in my opinion. PW: OK. It's basically determined by whether the bundles are installed system-wide or not.
	Extracted requirement:

ID	Text
919	When a different user is active, the system should behave as if that app bundle was not physically installed: it must not be run, its entry points must not be available for launching or data sharing, and so on.
	Comments: GA: Policy decision? But yes, agree the capability must be there. PW: This could be a policy decision — the choice here basically depends on whether the vendor has chosen for users to have strong privacy from other users. If they have weak privacy, it would make more sense for all installed apps to be listed in each user’s launcher.
	Extracted requirement:

ID	Text
922	As an exception to that general rule, privileged app management GUIs should be able to enumerate the app bundles that are physically installed, for example so that they can illustrate how storage space has been used.
	Comments: GA: OK
	Extracted requirement:

ID	Text
925	This could usefully be implemented by treating it as forbidden for the other users.
	Comments: GA: OK
	Extracted requirement:

ID	Text
926	When a user installs an app bundle that has already been physically installed by another user, the system must stop hiding the app bundle from that user. For example, it must now be made available for launching by that user, assuming there is no other reason why it would be forbidden.
	Comments: GA: For me this is implicit from the previous "store (code) only once" requirement (if we keep that one) PW: We wanted to make the user-visible effects of another user ‘installing’ the app explicit. GA: I understand but I think at the high evel" of requirements we now have, whether apps are "unhidden" or installed anew is an implementation detail. GA: I could live without this text as a requirement. PW: OK. I think the important requirement overall in this section is that if user A installs an app, user B (or their apps) must not be able to detect the app has been installed until they decide to install it themselves.
	Extracted requirement:

ID	Text
930	If a user has installed an app from a particular origin, then another user is not required to be able to install an app of the same name from a different origin.
	Comments: GA: Hmm. Same name means same identity? Let's dig into this a bit... PW: ‘Same name’ means same identifier, yes. Identifiers for apps are meant to be globally unique; we have been using a reverse-DNS notation for this, for example ‘org.example.MyCalendarApp’. GA: Let's change name to "application identifier" or similar - and put whatever we choose into the definitions table. PW: OK GA: But I think it could be solved by simply stating that application identifiers are unique, whether this is possible to enforce or not, it ought to be the fundamental idea, right? The requirement here sounds like a description of a strategy to handle an exceptional event, i.e. in case we ever encounter two apps with identical identifier, but it does not seem to cover every error case anyway: "another user" - what if the same user is requesting the second installation? Etcetera. PW: This section exists in response to the iOS masque attack. I guess the basic requirement is that application identifiers are globally unique, across all installation origins.
	Extracted requirement:

ID	Text
932	If a user has installed an app at a particular version, then another user is not required to be able to install a different version of that app.
	Comments: GA: Agree but it should be simple to understand. Basically just guarantee all users have the same version. (follows from "store only once" idea). PW: I think the wording is this way round so that it’s not disallowed for users to be running different versions of the same app — some implementations might allow this, and might strive for it in order to implement strong privacy between users. Apertis does not allow this: users must run the same version of each app.
	Extracted requirement:

ID	Text
934	If a user upgrades or rolls back an app, the app may be upgraded or rolled back for all other users.
	Comments: GA: Agree. Basically I a simple model is desired. Are users at all involved in which version of an app is being executed? PW: Do you mean in terms of being prompted about upgrades? I was assuming we would go with an Android-style model where the user is told which apps are going to be upgraded soon, and then the upgrade happens automatically unless the new version of an app requires the user to give it more permissions. That would require user intervention. However, as far as I am aware, no design work has happened on the user interaction for this yet. GA: This strategy I think is again OEM policy... So the possibility of doing this should be there, but it's not the only way. PW: Yes. This bullet point exists because it affects where and how apps are installed: whether the system needs to keep multiple versions of a single app around for different users. So the choice here significantly affects the application framework implementation, but shouldn't affect the design too much.
	Extracted requirement:

ID	Text
936	Open question: do we want to mandate that the physical installation of apps must be per-device, or leave that open?
	Comments: GA: Don't get it, please explain. AppStore/policy decision not affecting the device right? Or do you mean "store only once" requirement. PW: This is the ‘store only once requirement’ — installing apps per-device as opposed to per-(user, device). GA: OK, first of I would then rewrite "per-device" into something better. GA: Then I'm not sure. I waiver between thinking it is reasonable to assume every code is only stored once, vs. this being an implementation decision. If you have enough memory, and storing all applications inside a filesystem namespace that is unique to each user might still be a simple and effective option? Maybe even to the point of bundling all dependencies in app bundle... PW: I think this could indeed be an OEM decision. It significantly affects the implementation of an application framework, but shouldn't affect the design much.
	Extracted requirement:

ID	Text
938	A vendor might wish to include app bundles in the original factory state of the system, while subsequently allowing them to be upgraded and uninstalled by the user, in the same way that Google apps are typically handled on Android devices.
	Comments:
	Extracted requirement:

ID	Text
941	Preinstalled apps: it must be possible to preinstall app bundles on the system, while leaving them available for installation management (upgrade, rollback, removal) in the usual way.
	Comments:
	Extracted requirement:

...

Conditional access

ID	Text
945	App-store curators and app vendors might wish to provide publish apps on a time-limited basis. This is a complex topic and we recommend that it is considered separately. The Apertis Conditional Access design has some proposed requirements for this topic.
	Comments: GN : OK GA: I agree. Isn't this simply covered by some general mechanism in which OEMs can forcibly remove apps from the installation (security problem, time limited, or deprecated for any reason). Then it becomes OEM policy decision what to do with that possibility. Let's build in the requirements of keeping track of installation time and other such mechanisms (must be secure and not subvertible). PW: Agreed. For the Apertis conditional access design, we need: timestamp of installation or upgrade of a bundle; signature of bundle integrity from the app store; globally unique user, device, vehicle and bundle identifiers (note that there might be multiple Apertis devices in a single vehicle, and licensing could be separate for all of them); a way to work out when a trip ends in a vehicle (so it doesn't remove access to an app part-way through a trip).
	Extracted requirement:

...

Appendix: mapping to GENIVI Platform Compliance Specification 10.0

ID	Text
951	SW-APPFW-AM-001 Manifest file for Application: this is the bundle metadata, the app permissions, and the entry point metadata (including the details demanded by document launching and URI launching). Open question: Do we need an explicit statement of what else would go in here, like required API levels?
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
956	This appears to be taking an implementation detail (the manifest file) of the motivating requirements (framework must be able to []) and declaring it to be a requirement in its own right. We have attempted to re-state it in terms of requirements.
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
960	SW-APPFW-AM-002 Support for LUC: Last-used context
	Comments: GN : OK
	Extracted requirement:

ID	Text
961	SW-APPFW-AM-003 Failure handling in case of application doesn't respond on state change: Life-cycle management
	Comments: GN : OK
	Extracted requirement:

ID	Text
963	SW-APPFW-AM-004 Launch application from another application: this is document launching, URI launching and perhaps app launching.
	Comments: GN : OK
	Extracted requirement:

ID	Text
965	SW-APPFW-AM-005 Factory reset: Data management
	Comments: GN : OK
	Extracted requirement:

ID	Text
966	SW-APPFW-AM-006 Prohibit to start an application: see Life-cycle management and specifically Forbidden apps.
	Comments: GN : OK
	Extracted requirement:

ID	Text
968	SW-APPFW-AM-007 Activation of application, SW-APPFW-AM-008 Deactivation of application: What is activation?
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
970	SW-APPFW-AM-009 Support for activation of application (sic): from its descriptive text, this seems to actually be app launching.
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
972	SW-APPFW-AM-010 Support for switching the application (sic): from its descriptive text, this seems to actually mean stopping the application. Life-cycle management
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
975	SW-APPFW-AM-011 Support for pausing an application: Life-cycle management
	Comments:
	Extracted requirement:

ID	Text
976	SW-APPFW-AM-012 Support for resuming application: Life-cycle management
	Comments: GN : OK
	Extracted requirement:

ID	Text
977	SW-APPFW-AM-013 Support for stopping application: from its descriptive text, this is specifically stopping a paused application. Life-cycle management
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
979	SW-APPFW-AM-014 Application framework shall provide a mechanism to tell an application to change its state: the states specified are START (not running), BACKGROUND (running and in background), SHOW (running and in foreground), RESTART (from its descriptive state not actually a state, and not the systemd-style restart action either, but in fact the "resume" transition from PAUSE to either SHOW or BACKGROUND), OFF (what is the difference between this and START in terms of states?), and PAUSE (understood to be essentially SIGSTOP'ed). See Life-cycle management.
	Comments: GN : This being worked out.
	Extracted requirement:

ID	Text
987	These state names demonstrate some confusion between states and state transitions. We have specifically documented states, not transitions, and provided details of the allowed transitions.
	Comments: GN : This being worked out
	Extracted requirement:

ID	Text
990	SW-APPFW-AM-015 Application states: the states specified are either (INSTALLED, ACTIVATED, LAUNCHED, PAUSED) or (START, BACKGROUND, SHOW, RESTART, OFF, PAUSE) depending which column we believe. See Lifecycle management. It is unclear what these states mean, particularly ACTIVATED. We have described a different set of states in these requirements.
	Comments: GN : This being worked out
	Extracted requirement:

ID	Text
996	SW-APPFW-AM-016 Installed application info: this is the part of app launching that deals with listing what we can launch.
	Comments: GN : OK
	Extracted requirement:

ID	Text
998	SW-APPFW-AM-017 Access restriction for apps: this is our sandboxing and security. It's a big topic in its own right.
	Comments: GN : Agreed. This is discussed under access mechanism.
	Extracted requirement:

ID	Text
1000	SW-APPFW-AM-018 Support for different applications running in different runtimes: the application framework should support JVM- or HTML5-based runtimes. Stated in What's in an app.
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

ID	Text
1003	SW-APPFW-AM-019 Support for any number of applications: stated in What's in an app, under the assumption that this is referring to lack of arbitrary limits. If the intention is to cope with exceeding RAM by telling excess apps to shut down gracefully, that's harder but could be done. If the intention is to cope with exceeding flash space by "swapping out" apps to cloud storage or something, that's impractical for a device that might not have constant connectivity and should not be required.
	Comments: GN : This review comment is considered and updated the Requirement before the SAT approval for Miranda Compliance.
	Extracted requirement:

...

Appendix: mapping to Suma's proposed requirements

ID	Text
1011	App-FW-001 Protect the system against altering of any data by a malicious app: App integrity, System integrity, Per-user data, etc.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1013	App-FW-002 Protect the system against collecting and sharing of any data by a malicious app: App confidentiality, Private data, Per-user data etc.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1015	App-FW-003 Protect the system against usage of system resources etc.: Resource limits
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1017	App-FW-004 An application shall not [~gunnar.andersson: ] interfere with [~gunnar.andersson: ] the … … other application: App integrity, App confidentiality, Private data
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1019	App-FW-005 read, alter or delete non-application data: System integrity, Peruser data.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1021	As written, this requirement states that this must be forbidden entirely. We have assumed that the intention was to forbid it with exceptions where necessary for the app to do its job.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1024	App-FW-006 Users data are protected against access by another user: Private data, Per-user data
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1026	App-FW-007 deny access to APIs to which an App has not requested permission: Sandboxing and security
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1028	This requirement wrongly conflates APIs with privilege boundaries. There is never any reason to deny access to APIs that do not cross a privilege boundary, because such APIs cannot do anything that the app could not do itself.
	Comments: GN : Agreed.
	Extracted requirement:

ID	Text
1032	App-FW-008 per-app rollback: Rollback
	Comments: GN : under discussion
	Extracted requirement:

ID	Text
1033	App-FW-009 Shall support applications with UI or UI less: What's in an app
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1034	App-FW-010 Restore LUC: Last-used context
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1035	App-FW-011 information about mime type: Document launching Consideration has been given to possible ways to select file types, other than media types. We have included the recommendation that using anything other than IETF media types would be unwise.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1036	App-FW-012 Resource handling: Life-cycle management
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1040	App-FW-013 Inform apps about states: Life-cycle management
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1041	App-FW-014 shutdown: Life-cycle management
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1042	App-FW-015 Frozen state: Life-cycle management (we're calling it "pause" in this document)
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1044	App-FW-016 blacklist apps: We think this may be conflating two distinct behaviors. The first is to cope with apps that go into a crash loop, which must be rate-limited. The second is to have a way to stop apps executing altogether, which this document refers to as Forbidden apps.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1049	App-FW-017 apps with a validity period: Conditional access
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1050	App-FW-018 app requesting permissions every launch: App permissions. Note that we only really recommend this for permissions where there's nothing better we can do, like "unrestricted Internet access".
	Comments:
	Extracted requirement:

ID	Text
1053	App-FW-019 apps can communicate with other apps: Data sharing
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1054	App-FW-020 Content hand-over: Document launching, URI launching.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1055	App-FW-021 content type can be opened only by...: Document launching
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1056	App-FW-022 It shall be possible for an app to register a new content type: Adding media types
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1058	App-FW-023 Sharing a content to be transferred out of the system: (Androidstyle Sharing API): Sharing menu
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1060	App-FW-024 POI provider but no access to location data: implicit in sandboxing and security and app permissions. This requirement appears to be conjecturing that registering an app as a points-of-interest provider would cause it to have additional permissions somehow, but whether an app is registered as a points-of-interest provider should be entirely orthogonal to whether it has the permissions that would allow it to access location data.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1067	App-FW-025 to App-FW-032 Download manager: Download management
	Comments:
	Extracted requirement:

ID	Text
1068	App-FW-032 to App-FW-036 Internationalization: not mentioned here. As Gunnar says, this is a SDK API issue, not a platform services issue. It is entirely feasible to implement internationalization through a shared library provided by the platform (part of glibc in practice) and some data files in the app (gettext .mo files) without ever crossing a security boundary, and we recommend doing exactly that.
	Comments: GN : Agreed
	Extracted requirement:

ID	Text
1074	App-FW-037 installation of application bundles: Installation
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1075	App-FW-038 Native application: we are unsure how this is relevant to a
	Comments: GN : Not in the scope of Managed Apps handling.
	Extracted requirement:

ID	Text
1076	GENIVI design, since the interaction between vendor-supplied native apps and the vendor-supplied platform is presumably up to the vendor.
	Comments: GN : We need to cover those areas which are coomon and can be generalized.
	Extracted requirement:

ID	Text
1078	Terminology note: GENIVI's native applications are the same thing as Apertis' built-in applications. It is nothing to do with whether the app is written in native code compiled from C/C++. GENIVI applications that are not native applications are said to be managed applications, which are the same as Apertis' store applications.
	Comments:
	Extracted requirement:

ID	Text
1083	App-FW-039 Pre installed app vs. store downloadable apps: Preinstalled apps
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1084	App-FW-040a Install app from a storage device: Installation
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1085	App-FW-040b sync up with app store: We have interpreted this to mean that after installation from removable media, it must still be possible to upgrade via the Internet.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1088	App-FW-041 facilitate handling of permissions: app permissions
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1089	App-FW-042 provide data storage structure to an app: private data and optionally per-app data, per-device data, per-user data.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1091	App-FW-043 an app can't contain more than one program … or more than one agent/service: What's in an app
	Comments:
	Extracted requirement:

ID	Text
1093	There has been some resistance to this requirement, and we have written the requirements in this document to say that vendors may impose this limit, but the framework should not.
	Comments: GN : Agreed.
	Extracted requirement:

ID	Text
1096	App-FW-044 system extensions: What's in an app
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1097	App-FW-045 downloaded and installed only once (i.e. apps appear to be peruser but are really system-wide): Installation management
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1099	App-FW-046 queueing mechanism for app download (i.e. apps do not install in parallel): Software download limiting
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

ID	Text
1101	App-FW-047 App upgrades shall be checked periodically: Upgrade.
	Comments: GN: OK, type : Req mapping
	Extracted requirement:

JOIN/SIGN UP

GET INVOLVED

COLLABORATIVE PROJECTS

HISTORICAL

Events

Industry Events

COVESA Events

Contact Us

Child pages

Versions Compared

Old Version 8

New Version Current

Key

Last-used context

Download management

Installation management

Conditional access

Appendix: mapping to GENIVI Platform Compliance Specification 10.0

Appendix: mapping to Suma's proposed requirements