Closed
Bug 788122
Opened 11 years ago
Closed 11 years ago
API to get the available space and total space for app. installation
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(blocking-kilimanjaro:+, blocking-basecamp:+)
RESOLVED
FIXED
People
(Reporter: rudyl, Assigned: dougt)
Details
(Whiteboard: [LOE:S])
Attachments
(1 file)
5.20 KB,
patch
|
sicking
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•11 years ago
|
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: --- → +
Comment 2•11 years ago
|
||
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: - → +
Assignee | ||
Comment 3•11 years ago
|
||
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•11 years ago
|
||
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•11 years ago
|
||
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 | ||
Updated•11 years ago
|
Assignee: nobody → doug.turner
Assignee | ||
Comment 7•11 years ago
|
||
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.
Assignee | ||
Comment 9•11 years ago
|
||
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.
Comment 11•11 years ago
|
||
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.
Assignee | ||
Comment 12•11 years ago
|
||
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.
Assignee | ||
Comment 13•11 years ago
|
||
follow up - bug 791715.
Assignee | ||
Comment 14•11 years ago
|
||
Marco, that isn't what we are doing yet.
Assignee | ||
Updated•11 years ago
|
Whiteboard: LOE:s
Updated•11 years ago
|
Whiteboard: LOE:s → [LOE:S]
Attachment #661371 -
Flags: review?(jonas) → review+
Assignee | ||
Comment 15•11 years ago
|
||
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 :(
Assignee | ||
Comment 17•11 years ago
|
||
i can back out and merge the patches if it is important.
It's not that important I guess.
Comment 19•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a19948eb6c26
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•