788122 - API to get the available space and total space for app. installation

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

There is a V1 requirement for settings app to show device storage info.
I think on P.14 what we need is the storage info for app. installation.

Please refer to P.14 of the spec, http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Device_v2.pdf

The corresponding Gaia issue,
https://github.com/mozilla-b2g/gaia/issues/3968

Comment 1

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

We don't have the capability to do this in gecko right now, and I don't think we'll have time to implement this. We'll have to live without this for v1.

Comment 2

[Kai-Chih Hu [:khu]]

After confirming with Chris Lee, this would be in v1. He believe we do need this or users will have no idea how much storage is being used up. 

Without these APIs, it looks like page 14 and page 16 in the following document: 
http://people.mozilla.com/~lco/Settings_B2G/Release_1_Specs/R1_Device_v2.pdf
can't be done, am I right? 

If there has another way to implement or suggestion/comment, please share with us. Thank you very much.

Comment 3

[Doug Turner (:dougt)]

The wording in the pdf and UI is going to confuse things... 

We have the right APIs to support page 16.  The API is called device storage.  In the UI, it is called "Media Storage".

We do *NOT* have the right APIs to support page 14.  This is going to be some new API (probably just an extension of of mozIDOMApplicationMgmt).

Comment 4

[[:fabrice] Fabrice Desré]

We're not gonna add application-specific stuff for that in v1. And if understand correctly, page 14 deals with the free space on the /data partition as a whole. We're not just storing apps there, but the full gecko profile.

So if we really want to do page 14, we need a new API. If Jonas's comment #1 still applies, I don't understand how PMs expect stuff to happen just because they mark a bug blocking-basecamp+.

Comment 5

[Dietrich Ayala (:dietrich)]

Yep, the right move is to re-nominate (i flipped the flag) and cover in platform triage, and negotiate with the product team at the point for either dropping the feature or pushing the schedule for it.

Comment 6

[Andrew Overholt [:overholt]]

Seems like a blocker.

Comment 7

[Doug Turner (:dougt)]

Attachment: patch v.1

adds a new type "apps" which maps to /data on B2G devices, and <profile>/webapps on the rest.  This isn't very fine grain as there is other application data stored outside of these places, but is good enough for v.1

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 661371 [details] [diff] [review]
patch v.1

Review of attachment 661371 [details] [diff] [review]:
-----------------------------------------------------------------

We need to have an additional security check for getting access to this DeviceStorage. The easiest would probably be to hook in to the existing "webapps-manage" permission since being able to read/write to the apps folder is somewhat equivalent.

So no need to hook up any additional prompts, the existing prompt should be fine. Just add a call to permissionManager->testExactPermissionFromPrincipal(principal, "webapps-manager") to the getDeviceStorage if the type is "apps".

We also need to add equivalent checks in the parent process. Maybe even add checks there that ensure that the "apps" devicestorage is only used for read-only access. But maybe that can be done as a followup.

Comment 9

[Doug Turner (:dougt)]

happy to add it as a follow up, but why do we need additional security checks?  can't we just protected "device-storage:apps"

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I guess I don't know enough about how we do permissions for device-storage. What does an app need to do in order to get access to device storage? Enumerate something in the manifest? What happens if the user says "yes" to a prompt, i.e. what is granted at that time?

These questions off course are most applicable to how access is granted to the "apps" devicestorage with the patch as-is.

Comment 11

[Marco Chen [:mchen]]

Provides the mechanism used on Android.

1. Every installed application will be assigned a UID.
2. There is a group ID called sdcard_rw and media_rw.
3. Permission will be added into app manifest for SD card or media access right.
4. During installing app, once user accept the permission the assigned UID for this app will be added into sdcard_rw and media_rw.
5. So they can access these storage.

FYI.

Comment 12

[Doug Turner (:dougt)]

Right now, for device storage, we ask the content permission prompt for permission to do any action.  We use the string "device-storage:<storage type>".  Storage type is basically the string that is used in getDeviceStorage() call.

Web applications can ask for this permission in their manifest.  If the permission is not included in their manifest, a prompt is shown.



Because the browser could screw up and post a dialog for this API, i'll add a app-only security check in a followup.

I do not think we need to worry about read-only access here 'just' for apps.  I think we should extend r/w permission to all device storage objects - but that isn't going to happen for v.1.

Comment 13

[Doug Turner (:dougt)]

follow up - bug 791715.

Comment 14

[Doug Turner (:dougt)]

Marco, that isn't what we are doing yet.

Comment 15

[Doug Turner (:dougt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a19948eb6c26




if this is backed out for whatever reason, be sure to also backout bug 791715

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Sadness. The intent of my review comment was that they should have landed as a single patch :(

Comment 17

[Doug Turner (:dougt)]

i can back out and merge the patches if it is important.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It's not that important I guess.

Comment 19

[Graeme McCutcheon [:graememcc]]

https://hg.mozilla.org/mozilla-central/rev/a19948eb6c26