Closed Bug 1238450 Opened 9 years ago Closed 9 years ago

Autophone - deploy Nexus 6P phones

Categories

(Testing Graveyard :: Autophone, defect)

defect
Not set
normal

Tracking

(firefox46 affected)

RESOLVED FIXED
Tracking Status
firefox46 --- affected

People

(Reporter: bc, Assigned: bc)

References

Details

Attachments

(7 files, 1 obsolete file)

We have purchased 8 Nexus 6P phones for use in Autophone testing. It is necessary to use rooted devices in Autophone. In the past, we have either used exploits to root the OEM version of Android shipped on devices or have flashed AOSP builds on to the devices. I have attempted to build and flash an "angler" build onto a Nexus 6P without success. That device still boots but does not get past the "android" screen though shell access is available. It appears that a number of people have had issues creating useful AOSP builds for Nexus 6P. I have 3 ideas on how to proceed. 1. Google builds Android using Ubuntu LTS (14.04) while I did my builds using Fedora 23. I can attempt to perform the AOSP build on Ubuntu 14.04 and see if that build works better on the device I have already attempted to flash. 2. I can attempt to use the instructions at http://forum.xda-developers.com/nexus-6p/general/guides-how-to-guides-beginners-t3206928 under "7. How To Root - Traditional". This involves a modified boot.img plus SuperSU. I had hoped to not use third-party code but may have to do so if AOSP is not a solution. 3. I can try to find a exploit which will allow me to change the ro.debuggable property to 1 which would allow the use of factory Android builds. Android 6.0.1 fixes a security related issue with Media on Android 6.0 but I have never been comfortable using these due to their lack of provenance. I would appreciate any opinions on how to proceed. I've managed to get my "test" Nexus 6P into a state where I can no longer flash the factory image and don't want to mess up any further devices.
Another possibility is: 4. Install cyanogenmod 13 https://download.cyanogenmod.org/?device=angler
#1. building and flashing on Ubuntu 14.04.03 had the same result as building on Fedora. :-(
I successfully rooted both of the 6Ps I brought using #2 with 6. system less rooting. Issues with 6P: * need to chmod some directories that are pushed since they are created with permissions 700 and root ownership. I have a local patch for worker.py. * get_ipaddress in adb.py does not work for the 6Ps since netcfg is not available. :-/. Need to work up a patch to get the ip address from ifconfig if netcfg is not available. I'll root the remaining 6 I have at home and ship them to MV next week after more testing to see if there are any other issues. I've put these into production running the local tests since they can not run the remote ones due to the inability to detect if the network is up or down.
This handles the permissions for autophone_check_path and for the local pages. I'll leave this open for the ip address fixes.
Attachment #8709120 - Flags: review?(gbrown)
Attachment #8709120 - Flags: review?(gbrown) → review+
Comment on attachment 8709958 [details] [diff] [review] bug-1238450-adb-v1.patch Review of attachment 8709958 [details] [diff] [review]: ----------------------------------------------------------------- Minor concerns for you to consider... - if 'interfaces' is not specified and 'getprop wifi.interface' returns nothing, this won't check any interfaces - what if 'ifconfig' is not available on a device? Could you use the old, netcfg method as a backup, when no ip can be obtained from ifconfig (or vice versa)?
Attachment #8709958 - Flags: review?(gbrown) → review+
(In reply to Geoff Brown [:gbrown] from comment #7) > Comment on attachment 8709958 [details] [diff] [review] > bug-1238450-adb-v1.patch > > Review of attachment 8709958 [details] [diff] [review]: > ----------------------------------------------------------------- > > Minor concerns for you to consider... > - if 'interfaces' is not specified and 'getprop wifi.interface' returns > nothing, this won't check any interfaces true, but that would only bite us with a cellular connection? I could try to enumerate all interfaces except lo and try them. Seems prone to error though. > - what if 'ifconfig' is not available on a device? It is available on my nexus one, nexus s, nexus 4, nexus 5, nexus 6, nexus 6p, nexus 7 and samsung galaxy s iii. ;-) > Could you use the old, netcfg method as a backup, when no ip can be obtained > from ifconfig (or vice versa)? I suppose I could, but is it getting us anything in return really? In the event that getprop wifi.interface doesn't return anything, then netcfg would be able to detect the interface which was up, though not on nexus 6p. When would we have a network connection without using wifi? If you think it is a good idea, I can do a follow up patch to add that back.
I can't find a physical device that gives me trouble, but for the Android 4.3 emulator: gbrown@mozpad:~$ adb shell getprop wifi.interface gbrown@mozpad:~$ adb shell netcfg lo UP 127.0.0.1/8 0x00000049 00:00:00:00:00:00 eth0 UP 10.0.2.15/24 0x00001043 52:54:00:12:34:56 sit0 DOWN 0.0.0.0/0 0x00000080 00:00:00:00:00:00 gbrown@mozpad:~$ adb shell ifconfig gbrown@mozpad:~$ adb shell ifconfig eth0 eth0: ip 10.0.2.15 mask 255.255.255.0 flags [up broadcast running multicast] gbrown@mozpad:~$
ah! definitely forgot about the emulator. Do you have an android 6.0 emulator handy?
I do indeed! 6.0 emulator: gbrown@mozpad:~$ adb shell getprop wifi.interface gbrown@mozpad:~$ adb shell netcfg /system/bin/sh: netcfg: not found gbrown@mozpad:~$ adb shell ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope: Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 TX bytes:0 eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::5054:ff:fe12:3456/64 Scope: Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:25 errors:0 dropped:0 overruns:0 frame:0 TX packets:29 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1876 TX bytes:2117 Interrupt:13 Base address:0x3000 DMA chan:ff gbrown@mozpad:~$ adb shell ifconfig eth0 eth0 Link encap:Ethernet HWaddr 52:54:00:12:34:56 inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 inet6 addr: fe80::5054:ff:fe12:3456/64 Scope: Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:41 errors:0 dropped:0 overruns:0 frame:0 TX packets:43 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3088 TX bytes:4066 Interrupt:13 Base address:0x3000 DMA chan:ff gbrown@mozpad:~$
Attachment #8709958 - Attachment is obsolete: true
Attachment #8710443 - Flags: review?(gbrown)
Attachment #8710443 - Flags: review?(gbrown) → review+
Blocks: 1241553
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
talos results are looking good- I would like more data before making a finalized statement- this is promising though:) Lets keep moving forward.
Flags: needinfo?(jmaher)
We could start running talos on nexus-6p-1 and nexus-6p-2 in production to get more data.
I wrongly used an empty list if netcfg raised an error.
Attachment #8713513 - Flags: review?(gbrown)
Comment on attachment 8713513 [details] [diff] [review] bug-1238450-netcfg-output-v1.patch Review of attachment 8713513 [details] [diff] [review]: ----------------------------------------------------------------- Oops.
Attachment #8713513 - Flags: review?(gbrown) → review+
Depends on: 1244144
Blocks: 1244144
No longer depends on: 1244144
Van replaced the faulty usb3 card in autophone-1 and moved the devices which had been moved after the failure back to autophone-1. In addition, nexus-6p-{3..7} have been attached and nexus-s-2,4,6,10 and nexus-7-2 removed and placed in the fedex box under the table. The following is r=self change to the manifests to show the new locations and test manifests. I added nexus-6p-{3..7} to try for all tests until we can determine how they perform. https://github.com/mozilla/autophone/commit/25db9c37687e26c36b26623b304d3ae31c0a4358
This adds the Nexus 6P devices to general testing, adds more coverage for a number of unit tests which we should be able to handle. Some will be orange but we can decide later if they should be disabled, fixed or what.
Attachment #8734161 - Flags: review?(jmaher)
Attached file dump-manifests.py
Comment on attachment 8734161 [details] [diff] [review] bug-1238450-deploy-6p.patch Review of attachment 8734161 [details] [diff] [review]: ----------------------------------------------------------------- looking forward to the increased load!
Attachment #8734161 - Flags: review?(jmaher) → review+
I screwed up and didn't pull master before merging and ended up with a merge commit. https://github.com/mozilla/autophone/commit/fbd702086672c9aecce117d9feb8ad62cdf47094 https://github.com/mozilla/autophone/commit/766f715e0802cdee6801e99257a7f2e0480f5343 deployed ~ 2016-03-27 08:00:00
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Accidentally enabled webappstartup on Aurora/47 where it is no longer supported. This fixes it. https://github.com/mozilla/autophone/commit/df713a5e4fbe052d5bbf3432fd4efc7eaa787e8d
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: