This is a bb+ feature required by hardware manufacturer. Basically, we need to hide a special testing app in the phone, which will only be invoked in the dialer via special code, like *123*4#. This testing app consists of list of items to test, each item tests a given hardware capability, e.g. Battery, LED, backlight, vibrator .... It will be used in the production line and hardware support shop only, so it doesn't have to be pretty. A private spac available that lists the precise list of items to test; it will be simply the same as the Android counterpart. Todos 1. Determine how to hide and launch this app. I assume this is a standalone app, as oppose to a dialog in the communication app because it will need the permission to all APIs. Any thought here, Vivien? 2. Determine whether the testing app can complete all the tests with Web APIs available. For example, in the GPS test, the Android counterpart shown # of satellites, which is information unavailable to Gaia with just Geolocation API. We should file bugs for each of it and judging their bb status. The contact window to device manufacturer is Keven Kuo. Assign to me temporary until we figure out who should own this feature.

Kevin, can you add in the full list of 'debug mode' functionality our partner is asking for? Thanks.

(In reply to Chris Lee [:clee] from comment #1) > Kevin, can you add in the full list of 'debug mode' functionality our > partner is asking for? Thanks. We are still verifying with the manufacturer on where the list, and the issues should live (i.e. publicly or privately).

Reassign to Steve Chung, who will be handling this feature. Please spawn dependent bugs for individual features if you need others' help. We had gone through the list of items: https://docs.google.com/spreadsheet/ccc?key=0AqdyyP5SH_VOdFgwejlOT2dfS3puY1hGelF5UGNuemc Kevin Hu will talk to manufacturer on some of the red items; bug coming for Gecko APIs that we think we could add before C3. Vivien, I am still waiting on your opinion on how to launch the test app.

For the launching, I think the dialer app could do what homescreen app do in the mean time. -- We would hardcode the code in dialer app. -- If the code has been dialed, dialer app will call |window.open()| to notify the system app -- The system app receives the mozbrowseropenwindow event but discard the iframe, and launch the engmode app instead.

Tim If is didn't answer before this is because I don't understand why this is a blocking-basecamp+ bug. There is a lot of TDB here that makes me worried.

Current ongoing engineer mode branch https://github.com/steveck-chung/gaia/commits/engineering-mode. Bluetooth and radio info page are not totally ready yet. I will ask for review after feedback from our partner(if they insist this engineering mode feature is necessary...)

(In reply to Vivien Nicolas (:vingtetun) from comment #5) > Tim If is didn't answer before this is because I don't understand why this > is a blocking-basecamp+ bug. There is a lot of TDB here that makes me > worried. Yeah, we have all the PMs in Taipei on our back to scale back this feature as much as we could. The best scenario would be they find a way to support/test their hardware w/o feature in FxOS; yet, it's better to be prepared than being too late!

Steve, if you could make sure to have a recent master head pushed as master branch to your fork, that'd make github's branch compare-tool useful. Are we OK with this app being hardcoded to English?

Hi Pike, Thanks for the information, I'll sync this branch to master later. I've confirmed the localization with PM and they thought there is no need to have a multi-lang engineering mode...

Steve, can you provide an update on what's happening with this feature?

Hi Dylan, We will have a meeting with PM Kevin/Joe and other related developers for this in these days. Our partner requires some test items that lack of web api, and they decided to keep this feature in another branch and merge back after 1/15 (They can wait for end of Jan or middle of Feb to integrate the engineeing mode support version). I think we can move this issue to blocking-b2g. Except for the missing test items, the rest of items is finished and testable in my local branch. The key point for landing this feature would be: 1) Clarify which missing test item is indispensable because we could not finish all the items partner listed before. They've agreed to eliminate the unnecessary items but we need a confirmation. 2) The ETA of these back-end web api. Implementing a testing page is a easy job but it need much more time to land a web api. I will update with brief meeting minutes after discussion, or you can also find Kevin/Joe for more details. Thanks.

We tested engineer mode function developed,and found some issues as below: *983*0#-battery:battery status should be named as "not charging"or"charging",and status should update automatically once connect or remove the charge,following the same behavior with android. *983*0#-LCD:pop up the page"app：//engineermode.example.com is now fullscreen",this will effect tester's operation. *983*0#-key:it will show volume bar when press volume up key or volume down key,this should be hided when do this operation *983*0#-LCD off:can not light screen automatically after test this item completely,need tester to suspend then resume device to check the test result. *983*0#-SD:It takes too long time to read SD card info,more than 5s;and there is problem with accuracy,example:one 2G sdcard,in Firefox version,show info"used:1.7GB,total:1.7GB,Available:24.8MB",but in android version show"used:1850MB,total:1875MB,Available:24MB" *983*0#-BT address:status does not change when open or close BT *983*0#-touchpaint test: 1)overlay display,"back" option with the title"Touchpaint test" 2)pop up the page"app：//engineermode.example.com is now fullscreen" when start testing,this will trouble tester's operation. 3)during the touchpaint testing step 2,need touch all the touch points one by one,but the behavior on other android phones we tested we can scroll the screen to complete the testing 4)It is hard to touch the point correctly because the checking-point on screen is too small *983*0#-FM:Insert headset,there is no any sound when tap the frequency listed *983*0#-Camera:Unable to switch back to previous menu after captured a picture,we can only press HOME key to back to homescreen,then enter engineer mode again via dial pad. *983*0#-senor:there is no any value display for proximity,and there is no prompt such as"light is OK" for light,so that it is not very well for prodcuts line. *983*0#-wifi MAC address:overlay display,option"back" with the tile *983*0#:there is no any item to check led,this is required as communicated before.

Thanks for the feedback. I'll reply inline: (In reply to Firefox_Mozilla from comment #12) > We tested engineer mode function developed,and found some issues as below: > > *983*0#-battery:battery status should be named as "not > charging"or"charging",and status should update automatically once connect or > remove the charge,following the same behavior with android. I'll refine the wording and the update the status dynamically in the next patch. > *983*0#-LCD:pop up the page"app：//engineermode.example.com is now > fullscreen",this will effect tester's operation. I'll try to find some hack to avoid this dialog...It's default behavior for requesting the full-screen > *983*0#-key:it will show volume bar when press volume up key or volume down > key,this should be hided when do this operation It seems not possible the hide the volume panel in current design... > *983*0#-LCD off:can not light screen automatically after test this item > completely,need tester to suspend then resume device to check the test > result. Because the screen will become no responding when screen off, I can change the behavior to make it enter the suspend mode directly if you are ok with that. > *983*0#-SD:It takes too long time to read SD card info,more than 5s;and > there is problem with accuracy,example:one 2G sdcard,in Firefox version,show > info"used:1.7GB,total:1.7GB,Available:24.8MB",but in android version > show"used:1850MB,total:1875MB,Available:24MB" I'll exam the storage calculation part. Thanks. > *983*0#-BT address:status does not change when open or close BT When entering BT address page, I will force to open the BT to get the address, so the status will be always open when entering the testing page. Would you prefer not to open the BT automatically? > *983*0#-touchpaint test: > 1)overlay display,"back" option with the title"Touchpaint test" It didn't happen on my device(unagi). Did you use otoro for testing? > 2)pop up the page"app：//engineermode.example.com is now fullscreen" when > start testing,this will trouble tester's operation. Please ref my reply above. > 3)during the touchpaint testing step 2,need touch all the touch points one > by one,but the behavior on other android phones we tested we can scroll the > screen to complete the testing I'm not sure about the 'scroll the screen'... Any example video? > 4)It is hard to touch the point correctly because the checking-point on > screen is too small I can enlarge the target for better testing experience. > *983*0#-FM:Insert headset,there is no any sound when tap the frequency listed FM test works on my device. This may also need your help for providing the device model and build number > *983*0#-Camera:Unable to switch back to previous menu after captured a > picture,we can only press HOME key to back to homescreen,then enter engineer > mode again via dial pad. It need a lot of changes in camera app for the scenario you want because we don't have hardware back key in OS. Since the test complete number will not reset when entering again, I will fix other issue first. > *983*0#-senor:there is no any value display for proximity,and there is no > prompt such as"light is OK" for light,so that it is not very well for > prodcuts line. I will add "XXX is work" if the api works. We can not get initial value of sensor, so proximity will display only when the status change(You can place your hand over the screen and the value will display) > *983*0#-wifi MAC address:overlay display,option"back" with the tile Please ref my reply above. > *983*0#:there is no any item to check led,this is required as communicated > before. We need web api for controlling led.

The partner agreed to have it ready after Jan 15th. So, minus this one. But, we need to have a draft plan by the end of today.

I will update the offline discussion I just had w/ cjones and thinker after lunch.

OK. So we have reached a decision to change our plan to deliver this feature: -- Given the fact that we will never ever ship a Gecko with every Web API possible, the eng mode page should live in Gecko as something like |about:engineering-mode|, instead of what Steve had right now (a packaged app with almost every permission). -- ril code will be employed to launch the page from dialer, no hacking logic in Gaia. -- B2G runtime will launch that page into another <xul:browser> that covers Gaia System app. This is now officially a Gecko bug :) We should pass the torch here. Steve, would you please whatever Gecko dev in the office that will work on this later to take your code? Also, we need to remove most of the unrelated Gaia logic and style before converting the current code into a page in Gecko.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #16) > -- ril code will be employed to launch the page from dialer, > no hacking logic in Gaia. My understanding is, this is a feature requested by partners and B2G will include this feature but is based on our need. So I have two questions about the proposal here: 1. Like mentioned above, it's unlikely to include every Web API in one product. So applies to mozTelephony. What happens when a device shipped without mozTelephony? For example, a tablet device, or some kind of "Firefox OS Inside" TV set. It's fine we want to trigger engineering mode in Gaia::Dialer, but it's another thing that we can only trigger this mode through mozTelephony. 2. That's a back door in fact. It's fine because that back door is actually what we want, but having a non-trivial back door is yet another thing for me. You only realize it's a back door after diving deep into RadioInterfaceLayer.js, and that makes me feel terrible. Why not making a specific API for this? You'll need a lot more none-public APIs for engineering mode. What about moving those factory-test only APIs into the same place?

(In reply to Vicamo Yang [:vicamo][:vyang] from comment #17) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #16) > > -- ril code will be employed to launch the page from dialer, > > no hacking logic in Gaia. > > My understanding is, this is a feature requested by partners and B2G will > include this feature but is based on our need. So I have two questions about > the proposal here: > > 1. Like mentioned above, it's unlikely to include every Web API in one > product. So applies to mozTelephony. What happens when a device shipped > without mozTelephony? For example, a tablet device, or some kind of "Firefox > OS Inside" TV set. It's fine we want to trigger engineering mode in > Gaia::Dialer, but it's another thing that we can only trigger this mode > through mozTelephony. > Let's not worry about that at this stage, as I already stated offline. > 2. That's a back door in fact. It's fine because that back door is actually > what we want, but having a non-trivial back door is yet another thing for > me. You only realize it's a back door after diving deep into > RadioInterfaceLayer.js, and that makes me feel terrible. Why not making a > specific API for this? You'll need a lot more none-public APIs for > engineering mode. What about moving those factory-test only APIs into the > same place? I've no opinion on this. Chris, Thinker?

I am thinking that, do we need to deliver Firefox OS 'with' engineering mode? I think that we can only provide this to the partner at the beginning. In this case, maybe we don't need to spend lots of time on Web APIs discussion because it won't need to be in our repository. In the long term plan, we can see what we can do to provide a general engineering mode and spend time to have better Web APIs. How about this?

At framework layer, two things need to be done for supporting this requirement 1. Provide a trigger to enter this (engineer)mode - such as special code in dialer 2. After enter this mode, provide a policy to create a web frame in core process, which can manipulate HAL(e.g. SetLight) module directly. What I really concern is #1. I think it should be better that OEM partner implements this kind of back door in their release branch. Kind of dangerous to put a hole in mainline from security perspective.

Just have a brief discussion with RIL devs. They supported Vicamo's idea that this back door mode should not be implemented in RIL. This engineering mode and other non-public api should be placed into a individual module. Sorry that I'm still not very clear about this method like how we determine and control the life cycle, how to communicate with gaia app(like camera) and #1 issue CJ mentioned above... Although we may be able to save more time by avoiding these APIs to public, it still take time to implement this architecture. Do we need to come out a solution during work week(confirm the architecture and find a proper gecko developer to start this), or we can decide it after work week?

Calling engineering mode from RIL or not does not prevent us to put relative features of engineering mode into a separated module. We always need to put a trigger of this back door (engineering mode) some where, it can be RIL or some other place. I means a trigger only, not include the implementation of the engineering mode. Whatever, there is always one module; RIL or any other one, would eat that piece of sh*t. So, I don't think it is a good reason to put/or not put the trigger at RIL. By the suggestion from CJ, we can leave the decision of the back door trigger to vendors. B2G provides a module for launching engineering mode app with chrome privilege. Vendors will put a trigger at somewhere; RIL or any other places, by him-self. The basic ideal is running engineering mode app (a page) at b2g process with chrome privilege, so engineering mode app could call any components or ctypes to do test features. For example, about:engineering-mode implements the engineering mode. Gecko provides a component that launch that page in a frame running at b2g process with chrome privilege. A vendor can change the content of about:engineering-mode to define their owned tests, and put a trigger some where; maybe RIL, to call the launcher component.

(In reply to Steve Chung from comment #22) > Just have a brief discussion with RIL devs. They supported Vicamo's idea > that this back door mode should not be implemented in RIL. This engineering > mode and other non-public api should be placed into a individual module. Please read Thinker's response in comment 23. > Sorry that I'm still not very clear about this method like > how we determine and control the life cycle, how to communicate with gaia > app(like camera) and #1 issue CJ mentioned above... We will have to implement a minimal camera app for that. Our idea here is to put the eng mode page in Gecko, and decoupled with Gaia. (ppl might ship a Gaia w/o Camera app)

About some issues, we can explain: 1. > *983*0#-BT address:status does not change when open or close BT When entering BT address page, I will force to open the BT to get the address, so the status will be always open when entering the testing page. Would you prefer not to open the BT automatically? //we hope it can force to open the BT when entering BT test page，then close the BT when exiting BT test page. In test page, BT address can shown correctly. 2. > *983*0#-touchpaint test: > 1)overlay display,"back" option with the title"Touchpaint test" It didn't happen on my device(unagi). Did you use otoro for testing? > *983*0#-wifi MAC address:overlay display,option"back" with the tile Please ref my reply above. //Above two issues, we use the Device V790 for testing. The overlay display can see in attachment. 3. > 3)during the touchpaint testing step 2,need touch all the touch points one > by one,but the behavior on other android phones we tested we can scroll the > screen to complete the testing I'm not sure about the 'scroll the screen'... Any example video? //About the 'scroll the screen'，you can see the attachment. Other Android phone, in the page, we can slide in square pattern around the screen to finish this testing. Not touch the point one by one. If also not quite understand, please propose again. 4. > *983*0#-FM:Insert headset,there is no any sound when tap the frequency listed FM test works on my device. This may also need your help for providing the device model and build number //Unfortunately, maybe headset's problem or other reasons, we can not reproduce it now. This issue can be not concerned about the first. 5. > *983*0#-key:it will show volume bar when press volume up key or volume down > key,this should be hided when do this operation It seems not possible the hide the volume panel in current design... //We discuss internal about it. This issue can not need to be modified. Thanks.

The requirement have since resolved w/o landing any code in Gecko & Gaia. Closing the bug.

(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #29) > The requirement have since resolved w/o landing any code in > Gecko & Gaia. Closing the bug. \^O^/