923444 - [User Story] Single variant: Power on operator animation runtime customization by SIM

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P1)

Description

[Marcelino Veiga Tuimil [:sonmarce]]

As an OEM, I want to be able to specify which device start up operator animation should be shown by default on the device based on the MNC/MCC setting from the SIM card inserted during the initial device power up in order to target customizations to locales without needing to use separate builds

Comment 1

[Marcelino Veiga Tuimil [:sonmarce]]

We have added acceptance criteria to be as follows:
* When a brand new device is started up for the fist time, default power on animation will be displayed
* Meanwhile a SIM card is not inserted or PIN code not entered for the first time, default power on animation will be used
* The first time a SIM card is inserted with PIN code entered, power on animation for its MCC/MNC will be set (if any)
* Replacing or removing SIM card later on will imply no change in power on animation configuration
* After a factory reset, power on animation configuration will follow same process as a brand new device

Also starting to use the new User Story field in Bugzilla.

Comment 2

[Marcelino Veiga Tuimil [:sonmarce]]

Add a new acceptance criteria:
* After configuring power on animation for a SIM card, remaining animations will be removed to save space

Comment 3

[Carmen Jimenez Cabezas]

Attachment: Proposed patch v1

This fixes the user story by loading the media from a system by default and from anothe app (operatorresources) if it exists.

Comment 4

[Cristian Rodriguez (:crdlc)]

Good morning Carmen, "operatorresources" is an app or a new role? Because I am wondering if we could set up that app with role = "system" instead of creating a new specific role "operatorresources". Just a question :)

Comment 5

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8363770 [details] [review]
Proposed patch v1

Dislike put this file in system app. Sounds like a customization request.
Yuren, any thought?

Comment 6

[(inactive after 6/18) Alive Kuo [:alive]]

You could replace the default power on video by adding a folder inside gaia, why not using this?
And where does content.json come from?

Comment 7

[Carmen Jimenez Cabezas]

(In reply to Cristian Rodriguez (:crdlc)  (PTO 01-22 to 01-23) from comment #4)
> Good morning Carmen, "operatorresources" is an app or a new role? Because I
> am wondering if we could set up that app with role = "system" instead of
> creating a new specific role "operatorresources". Just a question :)

It's an app. I had created a new role in case in the future the role had any implication other than the app not showing up on the homescreen. In any case I don't really care one way or the other, if you prefer I will erase the new role and use the existing system role.

Comment 8

[Carmen Jimenez Cabezas]

(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #6)
> You could replace the default power on video by adding a folder inside gaia,
> why not using this?
> And where does content.json come from?

This patch doesn't really change the way the default video is loaded or handled. The intent of this patch is allow to choose at run time the operator power on video. That selection is done based on the actual SIM used on the first boot with SIM. A single phone will come out of the factory with several videos/images stored (one for each operator that will possibly sell that particular phone) and at boot time the correct video will be configured to be shown from that on (and the other videos/images will be erased so they don't take any valuable storage space on the phone).

The way this is implemented is by storing each operator configuration (videos/images) on a different operator app (see bug 893800). Then at run time the correct app will be installed (the app contains just the graphic resources and the content.json file). The way the system app will behave is: if there's an operatorresources app installed, it will load the graphical resources from there (if they are included). Otherwise, it'll load the graphical resources from the current place (the default directory you're referring to).

I could have preloaded the resources for all the possible operators on the system app, but that would have bloated the system app unnecessarily and would have made it impossible to erase the never used resources.

At this point (for this bug) the only resources included on the app, but there are some other open user stories that will probably need to include more operator specific resources (sound...) and they'll go also into this app.

Comment 9

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

looks you use an app to handle runtime customization so this isn't a part of build system, Albert use another way to handle wallpaper, ringtones and default contacts, so we should use the same way for customization per sim card.

Comment 10

[Antonio Manuel Amaya Calvo (:amac)]

We've been talking offline (Carmen, Albert and myself) and we have a proposal to try to move this forward, although we still think the currently proposed solution is simpler (since it doesn't require any changes at build time, but it uses the currently defined build processes).

As a prerequisite:

* If it's possible, we don't want to pollute the system app with all the videos/imgs for all the operators that share a build. Note that this number, for some markets, can be as big as 10-12 operators that could have each a different poweron/poweroff animations (and sounds...)
* And we want to be able to store permanently only the video that's actually used. So the current solution, referred by Alive on comment 6 isn't a valid one.

What we're proposing to do is (going from build time to runtime):

At build time:
1 Define a new tag on variants.json for the operator poweron/poweroff/sound/possibly other resources.
2 This tag will point to a local directory. The directory MUST have a contents.json file, a manifest.webapp file (and of course, the needed graphical resource files). The content of the contents.json file must be something like:
{
  "poweron": {
    "video": '/resources/power/carrier_power_on.mp4',
    "image": '/resources/power/carrier_power_off.jpg'
  },
  "poweroff": {
    "video": '/resources/power/carrier_power_off.mp4',
    "image": '/resources/power/carrier_power_off.jpg'
  }
}

Where all the fields are optional.


3 The build process will add to the FTU customization file something like

{ "214-001":
   {"operatorresources": {
     "poweron": {
      "video": 'app://myappname/resources/power/carrier_power_on.mp4',
      "image": 'app://myappname/resources/power/carrier_power_off.jpg'
    },
    "poweroff": {
      "video": 'app://myappname/resources/power/carrier_power_off.mp4',
      "image": 'app://myappname/resources/power/carrier_power_off.jpg'
    }
  } 
}

That is, it'll add the content of the contents.json file for each operator to it's own section on the file.
4. The manifest.webapp file for each operator resource directory MUST have the type set to privileged and it MUST have a origin field (set to the same value used on the contents.json file):

type: "privileged",
origin: "app://myappname"

5. The build process will generate a zip with the content of the configured resource directory, for each mcc/mnc.
6. The build process will add a operator variant app configuration for the application built at 5.

And that ends the changes of the build process.


Gaia changes (runtime):

1. communications/ftu: A new customizer will be created for the operatorresources. The customizer will just add a setting with the content of the correct customizer field (correct == content for the current MCC/MNC)
2. system: The system app will read the content of the new setting. If the setting exists, it'll use the URLs provided on the setting. If the setting doesn't exist, or a given value doesn't exist (there's no a poweroff.video value, for example) it'll use the default value (the same one that it uses now).


As I said at the start, this is more complicated that was proposed originally, but it's also more consistent with the other operator customizations.


What do you think?

Comment 11

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Sorry I clicked save change without comments, I will reply it later.

Comment 12

[(inactive after 6/18) Alive Kuo [:alive]]

I believe you could not access URL stuff of other app like "app://yourapp.gaia-mobile.org/yourlogo.mp4" in system app.
The proposal doesn't work.

I have no time to get understood your actual need though...but I don't think put all logo in one single app work. Why do you really need a standalone app? Is there any code in the app other than resource?

Comment 13

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #10)
> ...
> 
> At build time:
> 1 Define a new tag on variants.json for the operator
> poweron/poweroff/sound/possibly other resources.
> 2 This tag will point to a local directory. The directory MUST have a
> contents.json file, a manifest.webapp file (and of course, the needed
> graphical resource files). The content of the contents.json file must be
> something like:
> {
>   "poweron": {
>     "video": '/resources/power/carrier_power_on.mp4',
>     "image": '/resources/power/carrier_power_off.jpg'
>   },
>   "poweroff": {
>     "video": '/resources/power/carrier_power_off.mp4',
>     "image": '/resources/power/carrier_power_off.jpg'
>   }
> }
> ...
looks like a relative path with GAIA_DISTRIBUTION_DIR, so in this cae, we need put manifest.webapp in GAIA_DISTRIBUTION_DIR/resource/manifest.webapp and contents.json, right?

looks confusion, if we really need to use an app to store multimedia files, this app should be generate by build script.

but I talked to Alive and he said we shouldn't access another app by app://..

Comment 14

[Carmen Jimenez Cabezas]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #12)
> I believe you could not access URL stuff of other app like
> "app://yourapp.gaia-mobile.org/yourlogo.mp4" in system app.
> The proposal doesn't work.

You can do this currently if the origin app has the webapps-manage permission. The patch I uploaded for review does that already and is working, in fact.

> I have no time to get understood your actual need though...but I don't think
> put all logo in one single app work. Why do you really need a standalone
> app? Is there any code in the app other than resource?

No, the only content of the app is the resource. The need is described at the user story. Basically:

* The current OEM mode when building phones is personalize them at build time for the operator that's going to sell that specific device unit. That operator personalization is called a variant.
* That means that a phone manufactured for operator A cannot be sell by operator B, because it'll carry only the logos, sounds, contacts, apps,... for operator A.

What the [Single Variant] user stories do is define the necessary changes to allow a OEM to build a phone unit that can be sell by any of a set of operators. The actual personalization will be done at run-time (as opposed to build time). One of those personalizations, which is the one actually tackled in this bug is the poweron and poweroff animations and images.

The way this work currently on Gaia is that the animations can be specified at run time and are copied into the system app. But while that approach can work for single variant, it's not very... effective... copying 10-12 animations into system when only ONE of them will be actually used (and we cannot delete the others). That's why I proposed loading the operator resources on an independent app, and installing *only* the app for the operator whose SIM is used at the first boot. That's what the patch I uploaded do, and (on a more modular way) what Antonio proposal does.

Comment 15

[Carmen Jimenez Cabezas]

(In reply to Yuren Ju [:yurenju][:小朱] from comment #13)

> looks like a relative path with GAIA_DISTRIBUTION_DIR, so in this cae, we
> need put manifest.webapp in GAIA_DISTRIBUTION_DIR/resource/manifest.webapp
> and contents.json, right?

No, it's not exactly that. I think it'll be easier with an example:

On the variants.json file, for a given mcc-mnc:
...
operatorresources: "/this/is/a/local/path",
...
The /this/is/a/local/path local directory must have the following contents:

manifest.webapp
contents.json
resources/

Basically, /this/is/a/local/path will hold the contents of the resource app for the configured operator.

And from this, at build time, the resource apps for each operator will be created.

> 
> looks confusion, if we really need to use an app to store multimedia files,
> this app should be generate by build script.
> 

Yes, That is exactly what Antonio said on point 5 of his proposal. The differents resources Apps for the differents operators (differents mmc-mnc) will be created at build time.

> but I talked to Alive and he said we shouldn't access another app by app://..

Yes, we can access to another app by "app://", system app already had the "webapps-manage" permission that allows loading resources from another app (e.g. the videos).
The uploaded patch already did it, it did read the content.json file from another app (app://operatorresource) and it loaded the video from another app (app://operatorresource/<fullNameVideo>)

Just as a reminder, we need the operator resources on another app so we can delete the resources that are never used and free space on the phone.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

(In reply to Carmen Jimenez Cabezas from comment #14)
> The way this work currently on Gaia is that the animations can be specified
> at run time and are copied into the system app. But while that approach can
> work for single variant, it's not very... effective... copying 10-12
> animations into system when only ONE of them will be actually used (and we
> cannot delete the others). That's why I proposed loading the operator
> resources on an independent app, and installing *only* the app for the
> operator whose SIM is used at the first boot. That's what the patch I
> uploaded do, and (on a more modular way) what Antonio proposal does.

Sorry, but I still don't understand why the proposal works to
1. Reduce build time
2. Reduce disk space used
3. Install an app while FTU?

Comment 17

[Carmen Jimenez Cabezas]

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #16)
> Sorry, but I still don't understand why the proposal works to
> 1. Reduce build time

The objective of this patch is not reduce build time. in fact, with the change Yuren requested the build will take more time because it has more things to do. But this is unavoidable if we have single variant builds. Builds that don't use single variant configuration should not be affected at all.

> 2. Reduce disk space used

At this moment, there are two videos and two images per operator. If we have, for example, 10 operators that share a single variant build this means we have 36 files more than needed, because we will only need the files of a single operator.

If we can erase the files that will never be used then we will free storage space on the phone. To be able to do this, the resources for each operator must be on an independent app and on the data partition.

> 3. Install an app while FTU?

This is already done in bug 893800. This solution reuses the functionality implemented on that bug.

I will do a new PR with the solution we have described on comment 10. 

With this alternative system only need to read a settings to know which animation it should load.

Comment 18

[Carmen Jimenez Cabezas]

Attachment: Proposed patch v2

This implements the solution described in comment 10

Comment 19

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 8367433 [details] [review]
Proposed patch v2

Changing the review to my official bugzilla account.

Sorry folks, this went under the my radar, doing the review now!

Comment 20

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 8367433 [details] [review]
Proposed patch v2

r+ to the ftu part.

Just left one comment, non blocking.

Thanks Carmen!

Comment 21

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8367433 [details] [review]
Proposed patch v2

Don't let me make hard decision on holiday :)
If vivien has no concern about this I won't.

Comment 22

[Carmen Jimenez Cabezas]

Is there anything I can do here to speed up the revision?

Comment 23

[Carmen Jimenez Cabezas]

Alive, as you already know what this patch is supposed to do, could you take the review again? Thank you

Comment 24

[Fernando Jiménez Moreno [:ferjm]]

Comment on attachment 8367433 [details] [review]
Proposed patch v2

Thanks Carmen! The system part looks good to me, I only left a few minor comments.

I would still like to get confirmation from system owners before merging this.

Comment 25

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8367433 [details] [review]
Proposed patch v2

Please organize the code using SettingsHelper.

Comment 26

[Carmen Jimenez Cabezas]

Alive, I made the change you requested on comment #25.
Please could you review it again? Thanks

Comment 27

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 8367433 [details] [review]
Proposed patch v2

Please make sure test passes.

Comment 28

[Carmen Jimenez Cabezas]

https://github.com/mozilla-b2g/gaia/commit/ec17a3ae9deb9e377093c13aaaaddd270e69b505