Closed Bug 1238450 Opened 4 years ago Closed 4 years ago

Autophone - deploy Nexus 6P phones

Categories

(Testing :: Autophone, defect)

defect
Not set

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:~$
default to interfaces wlan0, eth0 if none specified; fall back to netcfg; reject 127.0.0.1 and 0.0.0.0.

new test run:
https://treeherder.allizom.org/#/jobs?repo=mozilla-inbound&filter-searchStr=autophone&exclusion_profile=false&filter-tier=1&filter-tier=2&filter-tier=3&fromchange=f87d296b0528&tochange=a24d6c2b7525
Attachment #8709958 - Attachment is obsolete: true
Attachment #8710443 - Flags: review?(gbrown)
Attachment #8710443 - Flags: review?(gbrown) → review+
Blocks: 1241553
Status: ASSIGNED → RESOLVED
Closed: 4 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: 4 years ago4 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
You need to log in before you can comment on or make changes to this bug.