yashsingh1/xdaforums huggingface dataset:
[E 2015 Original Android Development] squid2:
Testers Needed

I've prepared a new CM 12.1 test build for otus with support for encryption. This took a lot more effort to make it work than is apparent at first. Anyway, getting encryption to work properly required some reworking of the init scripts among other things. I want to have these changes tested out of band before I merge them into the official nightlies. I want this build tested on both single SIM and dual SIM devices, with and without encryption enabled. The variant of otus I have doesn't support my mobile carrier, so I can't test RIL myself.

The three main questions I have for each of the four configurations (unencrypted single SIM, encrypted single SIM, unencrypted dual SIM, encrypted dual SIM) are:

Does the RIL (mobile radio) work?

Does WiFi work?

Does Bluetooth work?

Confirming that you were able to successfully encrypt your device would be helpful too. Be aware that encryption can take a while, and it might appear to be stuck at the boot animation for a few minutes while encrypting. Give it at least 10 minutes on the boot animation while encrypting before you give up.

Download link for test build with encryption support: https://www.mediafire.com/?xp5a5thwr1sdhju
[E 2015 Original Android Development] IronTechmonkey:
Goody. An excuse to test Android ROM encryption for the first time. In spite of the time encryption takes this is an easy and disposable test which I should be able to do within a day or 2.
[E 2015 Original Android Development] india_motoe2015:
Problem Solved.

I have solved my problem. It took a lot of time & a lot of menial effort [flashing, reflashing, changing settings etc. etc] & restrain to not throw the phone at the wall when I couldn't pin-point the cause.

Without adding too much drivel I want to point out that the cause of PlayStore FC was Xposed module called 'PlayStorePermissionsExposed'. After disabling the module, PlayStore functionality has been restored.

I am posting this for the purpose of documentation & as a pointer for someone else who's suffering from similar problem.

PS: Thanks to anyone who read & replied, especially IronTechMonkey, for your input. Much appreciated !
[E 2015 Original Android Development] IronTechmonkey:
You are welcome but had I known you were using Xposed, after clean flashing with no 3rd party factors was recommended, I might not have been as helpful;). Seriously that is a bit of a burn on people who helped you in the interest of the ROM. Still, it is good that you posted the solution so other will avoid the same non-ROM issue. Thanks.

[EDIT] OK... I was a bit of a hard-a$$ in that post but the logic is good. I also have to admit that the tone is in part because I just don't like Xposed. I've never used it, but have seen it repeatedly and repeatedly and repeatedly be the underlying cause of some issue that was chased as a ROM issue, as if Xposed was a native part of the ROM, only for it to be revealed later that it was factor and or cause. That is the down side of a powerful utility that makes changes without knowing exactly what those changes are. Also, during the buildup to the significant transition from Dalvik to ART as the default run time environment in Android, Xposed was one of the last things to become ART compatible and it kept hooking people into tweaks that were becoming increasingly incompatible with ART. So... I clearly have a beef with Xposed, please don't take it personally. I actually kick myself for not blaming Xposd immediately. :)
[E 2015 Original Android Development] IronTechmonkey:
Tested on Otus, Moto E, US, 3G, XT1511 single SIM device. Here are the results described in a work-flow, some of which is new to me and is presented this way in case the flow has a significant impact that I'm not understanding.

- Clean flash ROM only, with external SD removed, developer options enabled.

- Disable lock screen temporarily.

- Phone call OK

- Mobile data OK, with expected connection speed as measured by speedof.me.

- Wifi OK, with expected connections speed for gear used, as measured by speedof.me.

- BT enabled, seeming to take a few seconds longer than usual to turn on but I have no other devices with which to test actual connection.

- Connect to PC to backup internal SD because I don't know what encryption might do to that. Good grief, MTP mode is as ridiculous as ever. Copy process kept stopping but I think that is just because MTP is dumb as dirt.

- Enable pattern lock screen.

- Encrypting, reboot #1 fast, encrypting status screen fast (status bar was above 90% almost instantly), reboot, pattern lock presented with additional grid size selection requested, boots into OS. Whole process took about 10 minutes.

- Settings - Security - encryption indicates device is encrypted.

- Power off, power on. Boot takes about twice as long as the normal 2 minutes it takes when not encrypted.

- I neglected to test phone call but ancillary indicators like status icon, no SIM error looked good.

- Wifi OK, with expected connection speed for gear used as measured by speedof.me.

- Mobile data OK, with expected connection speed as measured by speedof.me.

- BT enabled, still seeming to take a few seconds longer than usual. I have no other devices with which to test actual BT connection, but this time I was able to see a neighbor's IMac in the blue tooth panel. I was not close enough to see that device in the first BT test.

- With device encrypted and connected to PC by USB I can access Internal SD but don't know what if any bearing encryption has on that.

- When entering TWRP to restore nandroid I had a bit of a scare when a lock screen with different grid size was presented over TWRP and I could not unlock it. I swiped to allow modifications then wiped and restored nandroid after which things seemed OK but some of my TWRP settings were returned to default, such as the option to "Keep system read only" and the display time-out and time zone.

In general It looks good, although there some things I need to learn about the effects of encrypting device on internal SD card and TWRP.

[EDIT] I'm not sure if this is an expected byproduct of using encryption or if I did something wrong (like accidentally wiping internal storage instead of cache after restore) but: the contents of the internal SD persisted through nearly the whole process, but by the time I returned to a nandroid backup it had been erased or formatted. Fortunately I made a copy of it before the test.
[E 2015 Original Android Development] squid2:
Thank you very much for your testing. It sounds like things are working properly on the Single SIM variant. Have any dual SIM users tried it out?
[E 2015 Original Android Development] IronTechmonkey:
It's too bad that flashing single sim device multiple times does not count as test for dual sim device because I've been flashing a lot this week.:D

11/4 nightly performing OK in general. Same old list of small issues including and that large potential gain in Wi-Fi time to connect, but I'll save that one for M, if it even occurs there.

11/4 also, so far experiencing no ill effect of a flurry of recent commits, and it includes google security patch level up to 11/1. Makes me wonder if this is the buildup to the next snapshot and if we'll get a snapshot. The ROM is certainly stable enough to be a snapshot.

Have not tested encryption although I don't know if the all the changes from the test build made it into official. I don't use encryption but could test if there is a need for it.

[EDIT] Just did notice one noteworthy change in behavior in the form of a noticeable delay for screen to light up when powered on after off-line charging. To reproduce:

- power off

- connect to wall charger

- confirm green battery charging indicator

- allow screen to power off

- disconnect from charger

- press & hold power button

= delay until screen lights. I did not test enough to see if the delay is longer or shorter depending on how long the power button is held but even if it is held for the normal duration that triggers power up (2-3 seconds) the screen still takes several seconds longer than usual to light and show bootloader unlocked warning.

I've seen 2 recent sets of commits that could relate to this. One is specifically for off-line charging http://review.cyanogenmod.org/#/c/116172/ and then there are these which relate to screen power off during boot and or shutdown http://review.cyanogenmod.org/#/c/114578/, http://review.cyanogenmod.org/#/c/114579/. May not be bad but definitely new, and certainly disconcerting in that moment when the the screen isn't lighting up when you expected.it to. Through subsequent power cycles without off-line charging it behaves more normally. Off-line charging is a seldom used feature on which the effects of those commits may not have been considered. I've seen weird things stem from off-line charging issues - like spontaneous reversion to dalvik after switching to ART in CM11/KK4.4.4.
[E 2015 Original Android Development] squid2:
Thanks for the continued reports. CM12.1 for otus is fairly solid and stable now I feel. I'll look into the post offline charge screen on delay thing you mentioned when I get time. The three commits you mentioned look like good guesses. It's minor but worth looking into if it's a nightly regression.

P.S. All the encryption related fixes from the earlier test build have been merged in along with a few more that you've probably seen.
[E 2015 Original Android Development] IronTechmonkey:
Thanks for the details. At this point I'm testing CM12.x only when there is something new worth trying... and I'm gad I did this time because the trouble with off-line charging runs deeper:

- First time connecting to PC after the previous off-line charging test.

- PC unexpectedly installs new drivers, which is first bad sign. (FYI - I have even more control and structure in my PC universe than in droid testing ;)).

- I cannot access external SD card via USB.

- USB debugging has become disabled and greyed out.

- Settings - Storage - menu - USB computer connection - has become set to the charge only setting.

Something has indeed gone off the rails in regards to that USB charging commit, as it seems to be forcing the change to the "charging only" USB setting. Afterwards I confirmed that, with the USB setting restored I was able to properly use adb to reboot from Lollipop to boot loader and then use mfastboot to reboot from bootloader back into Lollipop however there are some disconcerting aspect to this particular issue that make it a potential chasm into which serious issues might fall and not be noticed until they pop up later.

- The nature of the issue it's self; as it involves a problem that is crossing over between what are essentially 2 different boot options (off-line charging and regular Lollipop OS).

- What if USB debugging is required during that first boot after off-line charging was used? I suppose mfastboot might still work from boot loader but this is still not good.

- The fact that it was missed and the fact that it being missed was predictable. OK, this one is Johny Test Pilot's own beef with insufficient pre-flight testing. :)

[EDIT] Just reconfirmed: Off-line charging changes usb computer connection setting to "charging only" which in turn disables USB debugging. After using off-line charging both of those settings must be changed back manually.
[E 2015 Original Android Development] Santhosh M:
[MENTION=6485916]squid2[/MENTION] I had been hitting the same okhttp thing on my 8916 and did the same hack. But it moves to a new error like this

01-01 04:53:01.207 619 619 E dex2oat : Unexpected failure to resolve a method: void android.net.Network$2.<init>(android.net.Network)

01-01 04:53:01.207 619 619 F dex2oat : art/compiler/oat_writer.cc:627] java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack trace available

Do u have any idea about this ?

Regards

Santhosh
[E 2015 Original Android Development] squid2:
Thanks for digging into this. I'm suspecting the USB config change commit. I might need to add missing USB properties to the build.prop.

EDIT: I can confirm that after offline charging, the phone gets stuck in charge only mode and settings get messed up. Will try to fix tonight.
[E 2015 Original Android Development] squid2:
Charge Only Mode Issues

Thank you for reporting this issue [MENTION=5119654]IronTechmonkey[/MENTION]. It was a fairly serious regression. I've pushed the fix and it should be in the next nightly. In the interim, if your device gets stuck in charge only mode, use the TWRP file manager to delete the file /data/properties/persist.sys.usb.config
[E 2015 Original Android Development] IronTechmonkey:
Thanks. I'll keep an eye out for the fix in the changelog and give it a spin when it hits. I don't use off-line charging except in testing or emergency so it should not be a problem but it is good to know that fix. Thanks again.
[E 2015 Original Android Development] IronTechmonkey:
Clean flashed 11/6 to test off-line charging which seems partially fixed (the more important part). Off-line charging no longer switches "USB to computer"* setting to "charging only" incidentally disabling USB debugging, however there is still a disconcertingly long delay to power up. After USB charging then disconnect from charger; the power button must be held for 12 seconds before power up. I tested to confirm that this is not a case of power up being initiated at 3-4 seconds and lighting the screen later. The power button must be held for 12 seconds to start up. Normal power up even after off-line charging is 3 seconds, and forced reboot by pressing Power + Volume Down is only 7 seconds - which are consistent with past behavior across multiple devices and ROMS. At least the USB settings are not being changed, and the behavior of 12 second press to power up is consistent (that consistency had not been established in the previous round of testing) but some folks may think something is wrong after they've held power button for 5 seconds or so.
[E 2015 Original Android Development] squid2:
Hmm, I tried with the November 6th nightly and couldn't reproduce your delay. Here are my steps:

Turn off phone

Plug into wall charger

Watch it enter offline charging mode, show big battery charging animation

Let it charge for a minute

Unplug

Around 15 seconds after I unplugged, I pressed the power button to turn on the device

After holding the power button for 3 seconds, the screen came on and it booted up

Are you doing something differently?
[E 2015 Original Android Development] IronTechmonkey:
Nope, that's the test - as long as the screen went off on its own at step 4. Just repeated for good measure. Assuming you are also testing on XT1511, and now considering additional factors; I don't use any apps that should cause a thing like this and don't know what native settings changes could be factors (although i make a lot of them) but can give a true clean flash a test in later (after recharges of phone, mind and body).

[EDIT] ... and it was kindo dum of me to have waited until late in the process to test this bit D'oh!
[E 2015 Original Android Development] squid2:
I tried to leave it charging for longer this time, and I was able to reproduce the delay. It's minor, but I'll try to investigate the issue.
[E 2015 Original Android Development] IronTechmonkey:
Yar, and it reassuring that it is consistent. Thanks for taking a look.
[E 2015 Original Android Development] squid2:
I did some more experimenting and tried going back to older builds from a few weeks ago. The same 12 second delay from startup seems to be present on old builds too. Since it's not a nightly regression, has a low impact, and I have many higher priority things to deal with (I have a lot of projects on the go, not just otus CM), I can't afford to put too much time into it right now. I'll put it on the backburner for now and will revisit it when I have time to examine smaller details Nevertheless, thanks for the report.
[E 2015 Original Android Development] IronTechmonkey:
Yep. With no apparent I'll effect It doesn't rate that high. Thanks again.
[E 2015 Original Android Development] sagnik9:
With the November 6 build, I faced two random reboots while watching videos on YouTube

Since then I have not been able to recreate it to provide logs

I'm using the Dual Sim Indian Variant
[E 2015 Original Android Development] IronTechmonkey:
An excuse to test video stuff. This is likely a youtube or even worse a Boogle issue. Running the same 11/6 build here on US/single SIM/XT1511 with no issues in Youtube (which I usually keep frozen but thawed for this test). Other video; streaming in in web browser (Dolphin) and local media played in MX Player seem OK. BS Player can play video but often FCs on exit but that is almost certainly an app issue.
[E 2015 Original Android Development] EsromTech:
I had a random reboot yesterday, without even doing anything different, just turned on the screen to see the time at the moment he caught on the lock screen and 5 seconds then came the reboot.
[E 2015 Original Android Development] sagnik9:
I faced 2 more random reboots, one while listening to music and more while using the paytm app.

The screen freezes for 3-4 seconds and then the phone reboots
[E 2015 Original Android Development] IronTechmonkey:
No spontaneous reboots or FCs here on XT1511 except when testing a particular screen recording app which causes freeze/hard reboot, and a few apps that are no longer compatible and FC when run, but those issues can be reliably reproduced. Assuming your original flash was clean (even if later configured and with apps installed on it) and never for a second saw Xposed... are there any 3rd party utilities managing system settings, permissions, system apps frozen etc? Is there any way to force the issue to occur?

---------- Post added at 03:59 PM ---------- Previous post was at 03:51 PM ----------

That sounds a little like the freeze/crash (which I referred to just above) that occurs when I run a particular screen recording app, although in your case the cause is not obvious. The trick is to find out what common factor was at play in both of those cases.

[EDIT] There is a loose potential connection to the lock screen in both of your cases. One incident centering around the lock screen it's self and the other while listening to media (most media player have lock screen components). It's a loose connection indeed but there may be something to it.
[E 2015 Original Android Development] Casper1982:
When you change a theme, and reboot ... the status bar returns by default ...

It only works when the device is restarted.

It is a problem of cyanogenmod? or a problem with the theme manager?
[E 2015 Original Android Development] IronTechmonkey:
Firstly, and I apologize for starting here but so very many people are reporting false positive ROM issues that are actually caused by Xposed; If you are using Xposed then get rid of it and retest in a clean flash before doing anything else here, or post about it in an Xposed related thread.

As to the issue at hand, and assuming no Xposed: By definition this implies the presence of a 3rd party theme and or theme manager which, in the absence of more detailed information would be the first likely source of problems. Questions:

- When you say "Theme manager" do you mean CM's native themes applet or some 3rd party utility

- The status bar is displayed by default until some change has been made so why is there an expectation that the status bar would be hidden by default after applying a theme?
[E 2015 Original Android Development] IronTechmonkey:
countdown timer passes zero without sounding alarm

[MENTION=4730968]EsromG5[/MENTION] and [MENTION=5126672]sagnik9[/MENTION], I'm still curious about those spontaneous reboots - and not just so I can be a harda$$ and blame them on something outside the ROM :). I know such issues can be hard to pin down but if you manage to narrow down the cause I'd be glad to test for it... as long as Xposed is not involved ;)

Meanwhile... I'm still running the 11/6 nightly and just experienced the "countdown timer passes zero without sounding alarm" bug. In this bug the countdown timer will fail to sound alarm for 30 or more seconds after passing zero and or until screen is powered on. Here is the retired jira ticket for it https://jira.cyanogenmod.org/browse/CYAN-6137. In CM11 it was difficult but possible to reproduce it and get logs but I've been unable to force it and log it in CM12. Even with those logs, the cause was not isolated. In most reported instances the alarm did ring about 30 seconds after zero but in a few cases, including the one I saw today, it had counted several minutes past zero with no alarm sounding until the screen was incidentally turned on. Although this bug has only resulted in a few over-baked potatoes, alarms are a type of function where any failure undermines confidence. As usual, Tasker is my workaround (a countdown timer w/snooze function that plays a random music file) but I just wanted to throw the timer-passing-zero bug out there in case anyone else happens to see it.
[E 2015 Original Android Development] sagnik9:
Yes I was using Xposed, I'll test without Xposed and if that happens again I'll post it in the forum
[E 2015 Original Android Development] EsromTech:
[MENTION=5119654]IronTechmonkey[/MENTION]

I can not set the random reboot as cyanogen bug, because I'm also using Xposed (xuimod, minminguard and appsettings are the only modules that use)

Ma anyway, only to have Xposed already behind me questions, and I believe it can be rather that reason.

Regarding the timer, I'm using the latest nightly, can you tell me how do I get with this test? which way?
[E 2015 Original Android Development] IronTechmonkey:
You crazy kids and your Xposed:). Here is some advice: If using any 3rd party utility and experiencing an issue make sure you mention that 3rd party factors are present in the original report of the issue. Doing that would avoid causing people who are interested in testing the ROM from following false leads while allowing a parallel dialog about the interaction of the ROM and those 3rd part utilities.

As for the countdown timer. It may not be worth the trouble to test specifically but if you are interested: in the jira ticket I linked to earlier you can see a very detailed description of the issue and how to test for it in CM11. I only mention it so people have it on their minds in case it occurs to them.
[E 2015 Original Android Development] EsromTech:
actually I'm not a child, I have 25 years hahahaha

But actually I am not blaming the Roma for restarts, but when it was mentioned Xposed here following, there gave me because I also use, then disregard my bug report ...

I just glad now to build 20151109
[E 2015 Original Android Development] IronTechmonkey:
I was joking more about myself being a cranky old person (25 is soooooo young):)
[E 2015 Original Android Development] IronTechmonkey:
11/12 nightly looking generally OK. There is a nice new option in wifi settings to view only open networks. Also,for anyone who uses encryption, be advised: after the 11/12 nightly was released a commit to "Unbreak hardware-backed pattern lock + encryption" was released. By implication of this commit and what it fixes there has been an issue in recent nightlies that could lock you out of the ROM in some usage/settings scenarios when encrypted. If you are thinking of encrypting or changing authentication type while encrypted on an earlier nightly you might want to check out and understand the ramifications of this commit and or wait until it is in the ROM. http://review.cyanogenmod.org/#/c/119475/.
[E 2015 Original Android Development] Dexter_S:
Ok, this might sound a little dumb after all this time. But is there any way to assign particular numbers to one of the dual Sims. Like calling my friend, it is called via sim 1. The stock rom had a feature like this. This is so frustrating to select the sim for every call I make.