search

phonelab / cm-shamu.manifest

Repo manifest for Nexus 6 (shamu) based on CyanogenMod 13.0
0 stars 0 forks source link

Complete Data drop out after 36-48 hours #11

Closed saintsantos closed 8 years ago

saintsantos commented 8 years ago

Some people (myself included) have been experiencing a complete data loss on their device after having their data work fine for 36-48 hours. This is a very troubling bug that I'm currently looking into a solution for.

gchallen commented 8 years ago

Obviously this is a serious problem and a potential show-stopper for the CyanogenMod rollout. I'm going to pull @shaseley into this for help, but @jhshi should also be involved.

Here's what I suggest trying:

  1. @saintsantos claims that there is a Pure Nexus build that doesn't have this problem. He's going to run down the differences between it and what we are using. This could also be a potential fallback as an alternative ROM, although I'm prefer not to switch ROMs (again).
  2. @saintsantos is also going to contact both the CyanogenMod maintainer for the Nexus 6 and the Pure Nexus ROM maintainer to see about a fix.
  3. @shaseley is starting some test cases to see if we can figure out what tickles this problem. I'd trying both bulk downloads and repeatedly connecting and disconnecting from the Sprint network to see what gets us wedged faster. That may help with debugging. Also once we have few devices in this state we can inspect the logs for debugging.
  4. @saintsantos is getting in touch with Brian to see if the problem is on Sprint's end. Given that we have a few participant devices that are already in this state perhaps there's a problem on Sprint's end that he can identify. And once we have a few devices that we have wedged ourselves we can try debugging steps that he might suggest.

Let's track activity on this issue in this thread and schedule a call for this afternoon (8/17) to touch base again. Unfortunately I'll be in NYC for a few days starting tomorrow and not necessarily available for close consultation, at least on Saturday and Sunday, so hopefully we can get this sorted quickly.

jhshi commented 8 years ago

I haven't experience this issue on my phone. Started a super long Youtube video to see if I can trigger this.

shaseley commented 8 years ago

The file that I deleted: data/data/com.android.providers.telephony/shared_prefs/preferred-apn.xml

jhshi commented 8 years ago

Can you post the content of the prefered-apn.xml file of a phone that has broken LTE? This is the file of my Nexus 6 has NO LTE problems:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<long name="apn_id1310120115733141" value="1238" />
<long name="apn_id1" value="-1" />
</map>
shaseley commented 8 years ago

This is from one that's stuck:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

shaseley commented 8 years ago

Grrr.

<map> <long name="apn_id1310120115730616" value="1246" /> <long name="apn_id1" value="-1" /> </map>

jhshi commented 8 years ago

Looking at packages/providers/TelephonyProvider/src/com/android/providers/telephony/TelephonyProvider.java

jhshi commented 8 years ago

How to reproduce this issue exactly? I was not able to, even with multiple toggles of airplane mode.

shaseley commented 8 years ago

I don't have a sure-fire way to reproduce it. On the 3rd floor of Davis, just walking around is enough to cause the problem. With my device, toggling airplane mode a couple times was enough.

jhshi commented 8 years ago

What's the preferred-apn.xml content after you deleted the one that's broken and android regenerates again? Are these two different?

jhshi commented 8 years ago

@saintsantos : copy the apns-conf.xml file in the build you claim that has no LTE issues, to a broken phone's /system/etc/apn-conf.xml that's running our platform. And see if the issue is resovled.

jhshi commented 8 years ago

@saintsantos The apns-conf.xml file you added to /vendor/motoroal shamu was not copied: since /vendor/cm also has a rule to copy the file, the rule you added was ignored.

shaseley commented 8 years ago

Here's one that's currently working:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?> <map> <long name="apn_id1310120115730616" value="1238" /> <long name="apn_id1" value="-1" /> </map>

Just the value field is different.

jhshi commented 8 years ago

eh.. what's 1238 vs. 1246? I also have 1238 here and the LTE is working. So 1246 breaks LTE?

Can you dig into the java file I pointed and figure out what that value mean? I suspect the root cause is not here: it seems this telphony provider just find the apns-conf file and keep a pointer to it.

jhshi commented 8 years ago

And what's the list of *apn*xml files on the phone with broken LTE?

gurupras commented 8 years ago

We have LTE working stably so far. We replaced /system/etc/apns-conf.xml with one obtained from PureNexus sources. We also cleared out the preferred-apn.xml that @shaseley pointed out earlier. Doing both of these yields a setup that looks to be stable. I've been running this for the past half hour and my device remains on 3G inside Davis 338B and moves to LTE when I move outside and toggle in and out of airplane mode.

In parallel, we are also checking to see if the stock AOSP apns-conf.xml produces similar results.

jhshi commented 8 years ago

Yeah, I think the apns-conf.xml is the root cause here. I suggest everybody (@gurupras @shaseley @saintsantos ) try a different apns-conf.xml: aosp stock, purenexus, the one from /vendor/cm/. And see which one yields stable LTE connection.

Once we finalized on this. I'll fix the PRODUCT_COPY_FILES for apns-conf.xml file.

Clean that preferred-apn.xml file before testing.

jhshi commented 8 years ago

Who is using which apns file and what's the plan for testing?@gurupras @shaseley @saintsantos

I'd like to push out an OTA to fix this tonight or tomorrow.

saintsantos commented 8 years ago

I am using the cm APNs file, Scott has both the Working APN form earlier and the APN currently in the platform on two devices, and Guru has the working APN from earlier today.

On Wed, Aug 17, 2016 at 7:49 PM, Jinghao Shi < notifications@github.com [notifications@github.com] > wrote: Who is using which apns file and what's the plan for testing? @gurupras [https://github.com/gurupras] @shaseley [https://github.com/shaseley] @saintsantos [https://github.com/saintsantos]

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [https://github.com/phonelab/cm-shamu.manifest/issues/11#issuecomment-240583915] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AECqUNfKgglMdx_MrAwkZFVlml5axxwyks5qg54FgaJpZM4JmWqk] .

saintsantos commented 8 years ago

We were just planning to use the devices with data throughout the evening and see what happens.

On Wed, Aug 17, 2016 at 7:51 PM, Edwin Santos < saintsantos1341@gmail.com [saintsantos1341@gmail.com] > wrote: I am using the cm APNs file, Scott has both the Working APN form earlier and the APN currently in the platform on two devices, and Guru has the working APN from earlier today.

On Wed, Aug 17, 2016 at 7:49 PM, Jinghao Shi < notifications@github.com [notifications@github.com] > wrote: Who is using which apns file and what's the plan for testing? @gurupras [https://github.com/gurupras] @shaseley [https://github.com/shaseley] @saintsantos [https://github.com/saintsantos]

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub [https://github.com/phonelab/cm-shamu.manifest/issues/11#issuecomment-240583915] , or mute the thread [https://github.com/notifications/unsubscribe-auth/AECqUNfKgglMdx_MrAwkZFVlml5axxwyks5qg54FgaJpZM4JmWqk] .

jhshi commented 8 years ago

Fixed in 4.1.5

jhshi commented 8 years ago

Actually fixed in 4.1.7.