Hi All,
We have many times debated how to handle engineering mode. Various
partners have so far been adding in custom solutions on their own
branches, but it would be good to find a better solution.
Below is one proposed solution, though I'm definitely open to other
ones. However the goals I'd like to accomplish are:
A) The commands that can be triggered in the service menu is going to
be fairly OEM specific and not something that makes sense to build
into Gecko as cross-device-cross-device code.
B) The smaller Gecko/Gaia changes needed by OEMs the better. This is
to simplify porting the implementation forward to future FirefoxOS
releases.
C) We would like to one day be able to roll out updates to phones
without requiring OEMs to reapply their own changes to the updated
release.
D) The back-end of the service menu needs to be at least partially
implemented in C++. I.e. some of the commands that can be triggered
can't be implemented using the currently exposed APIs, even including
certified APIs.
F) The service menu UI should be implemented as a separate FirefoxOS
HTML app. I.e. we don't want to use some other rendering mechanism
than what we already have. And we don't want to have to add a lot of
engineering mode code to any of the normal gaia apps.
G) There shouldn't need to be a user visible icon on the home screen
for launching engineering mode.
H) It would be ideal, though not strictly required, if it was possible
to launch engineering mode by using a key combination in the dialer
app since this is how OEMs are used to doing it today.
Based on that I recommend the following setup:
1) Add a gaia-setting for "key combination in dialer that triggers
service mode".
2) Change the dialer app to read this setting and wait for the correct
key combination to be triggered.
3) When the combination has been hit, let the dialer app launch an
activity called "internal-system-engineering-mode".
4) Change web activities to enforce that activity names starting with
"internal-system-" can only be initiated and handled by certified
apps.
5) Add a XPCOM interface and an XPCOM contract-id for engineering
mode. The interface would have functions for
getValue/setValue/message. See below
6) Create a certified-only WebAPI which handles the IPC and security
checks to enable an app to use the above XPCOM interface.
The XPCOM interface would look something like:
// Implemented by engineering-mode library
interface nsIEngineeringMode
{
DOMString getValue(in DOMString name);
void setValue(in DOMString name, in DOMString value);
void setMessageHandler(in nsIEngineeringModeMessageHandler handler);
}
interface nsIEngineeringModeMessageHandler
{
void handleMessage(DOMString message);
}
and the contract id would be something like
"@mozilla.org/b2g/engineering-mode;1"
And the WebAPI would look something like
interface EngineeringMode {
Promise<DOMString> getValue(DOMString name);
void setValue(DOMString name, DOMString value);
attribute EventHandler onmessage;
}
partial interface Navigator {
readonly attribute EngineeringMode engineeringMode;
}
Once we have this, it means that OEMs could implement engineering mode
by simply dropping a shared library in the Gecko profile which
implements the needed backend. Then preinstall a certified app which
handles the internal-system-engineering-mode webactivity. This app
could then use any existing certified API as well as new
EngineerinMode API, to implement the service menu.
Obviously this app would be marked as hidden as to prevent it from
showing up on the homescreen.
/ Jonas
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
