Closed Bug 788122 Opened 8 years ago Closed 8 years ago

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

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+)

RESOLVED FIXED
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: rudyl, Assigned: dougt)

Details

(Whiteboard: [LOE:S])

Attachments

(1 file)

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
blocking-basecamp: --- → ?
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.
blocking-basecamp: ? → -
blocking-kilimanjaro: --- → +
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.
blocking-basecamp: - → +
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).
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+.
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.
blocking-basecamp: + → ?
Assignee: nobody → doug.turner
Seems like a blocker.
blocking-basecamp: ? → +
Attached patch patch v.1Splinter Review
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
Attachment #661371 - Flags: review?(jonas)
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.
happy to add it as a follow up, but why do we need additional security checks?  can't we just protected "device-storage:apps"
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.
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.
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.
follow up - bug 791715.
Marco, that isn't what we are doing yet.
Whiteboard: LOE:s
Whiteboard: LOE:s → [LOE:S]
https://hg.mozilla.org/integration/mozilla-inbound/rev/a19948eb6c26




if this is backed out for whatever reason, be sure to also backout bug 791715
Sadness. The intent of my review comment was that they should have landed as a single patch :(
i can back out and merge the patches if it is important.
It's not that important I guess.
https://hg.mozilla.org/mozilla-central/rev/a19948eb6c26
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.