Closed Bug 790158 Opened 11 years ago Closed 11 years ago

APIs to get OS version, firmware version, and hardware version for device information


(Firefox OS Graveyard :: General, defect)

Gonk (Firefox OS)
Not set



blocking-basecamp +


(Reporter: khu, Assigned: shelly)


(Keywords: feature, Whiteboard: [LOE:S])


(1 file, 2 obsolete files)

In, page 6, we will need to get information about OS version, firmware version, and hardware version. First 2 items may be related to software update that Marshall is working on. This case is used to monitor the status to get all these information.
Assignee: nobody → slin
blocking-basecamp: --- → +
Weren't we solving this using a settings hack right now? This seems like an ok v1 solution.
Keywords: feature
I would go even further and suggest we just drop a file somewhere it can be XHR's or <script src=>'d.
... if we even need it outside of core gecko, which isn't clear yet.
Hi All,
First of all, after discussing with our Gaia team, we came to the conclusion of doing it with settings db, base on the point of an easier implementation. Any suggestion on that? Second, where or how should these info come from exactly?
To be more precised, it's a hack to IndexedDB of mozSettings, please reference bug 783021, however, maybe creating a dom property for it might be the long term solution?
Hi, how about to follow the design from Android.
Keep these info on Android Property.
Ex:, ro.bootloader...
Sounds a good idea to use Android property.
We don't have the android property api exposed to Apps though. But settings is exposed. Another option is to generate a .js file at build time that we can include in any certified app that wants to know the build data.
Attachment #661717 - Flags: feedback?(jones.chris.g)
Whiteboard: [LOE:S]
Comment on attachment 661717 [details] [diff] [review]
Add os version and hardware info to the mozSettings.

This looks like an OK hack to me, but originally I believe we tried to avoid having read-only information values in settings.

f? to gwagner/sicking to see if they have better ideas.  If not, I'm ok with this.
Attachment #661717 - Flags: feedback?(jones.chris.g)
Attachment #661717 - Flags: feedback?(jonas)
Attachment #661717 - Flags: feedback?(anygregor)
Attachment #661717 - Flags: feedback+
Is this only used by the Settings App?
I just want to make sure that we don't have grant multiple apps the settings permission because of this.
Comment on attachment 661717 [details] [diff] [review]
Add os version and hardware info to the mozSettings.

Review of attachment 661717 [details] [diff] [review]:

I agree, this is a hack that abuse the settings API. But I think it's an ok solution that we can live for now.

The only other alternative that I see is to generate a .js file at build time which provide version information and which can be included in any gaia app and <script> sourced wherever we need version info. I don't really have an opinion about which solution to use since I don't see any dramatic downsides with either approach.
Attachment #661717 - Flags: feedback?(jonas) → feedback+
Thanks for all your feedbacks. I made a slightly twist so that instead of hard-coding the os version in settings.js, it is being set in, which itself also keeps other app information. This is just to avoid modifying settings.js if we want to bump the version number.

Generating a .js file at built time sounds like a good way to go, but I think we still need to parse out the hardware info at run time, and do the work in settings.js.
Attachment #662483 - Flags: review?(jones.chris.g)
Attachment #661717 - Flags: feedback?(anygregor) → feedback+
Comment on attachment 662483 [details] [diff] [review]
Version 2: Set the os version in

Looks good!

We'll have some fun negotiations over b2g versioning, but that shouldn't block this at all.
Attachment #662483 - Flags: review?(jones.chris.g) → review+
Attached patch Added reviewer.Splinter Review
Thanks a lot!
This patch only updates the reviewer in comment and description.
Attachment #663313 - Flags: review+
Attachment #662483 - Attachment is obsolete: true
Attachment #661717 - Attachment is obsolete: true
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.