I’m also experiencing this issue a lot. However, I think that taking out the battery is not necessary and it’s enough to hold the power button for 13 seconds, as has already been reported multiple times in this topic.
To prevent other affected users from taking out the battery all the time, I changed the title of the topic.
As a request to all users who already posted here: Please report back in case this method is not working for you but only removing the battery is. If such cases pop up, I’ll change the title back.
I hope everyone is fine with that proposal.
As I do see a pattern and did some logging, I’m going to describe these in detail:
Actions triggering the issue
In my case, the issue is not (fully) reproducable, but I do indeed see a certain pattern. Namely, it is always related to launching apps that use internet connection or to internet itself. Though the phone doesn’t always crash immediately after such an action - sometimes it takes a minute or two until the crash actually happens. Examples of such actions triggering the crashes include:
- Launching F-Droid app
- Launching Lightning Browser
- Launching and activating Orbot
- Launching Transportr
- Launching IceCat Browser
- Disabling Wi-Fi (no app involved here)
- Enabling Wi-Fi (no app involved here)
Other apps such as calendar (not synchronized), camera, tasks etc. haven’t triggered this up to now. Sometimes, it also happens in a row (and then the back side of the phone gets quite hot):
- E.g. today it crashed once using IceCat and after the reboot I just enabled Wi-Fi and it immediately crashed again.
- Yesterday I wanted to use the internet only in two occasions and both times the phone crashed (again two times in a row in one of the cases).
- Three days ago it even happened 5 times in a row (during some testing concerning the crashes, see below).
This nearly led me to the conclusion that it might be reproducable, but I think it’s not. However, from my user experience (since using the phone daily) I’d guess that the chance to use internet on my phone without triggering a crash is far less than 50%. 
So it’s quite a big issue for me. Though, if it works once (i.e. the phone doesn’t crash during the launch of the first internet app), it then usually works for the rest of the day (until I power off the phone during the night).
Btw this doesn’t depend on the type of internet connection: It happens with Wi-Fi and with mobile data. Moreover, I also tested the phone without SIM and it happened there too (with Wi-Fi of course).
I am somewhat surprised that most of the people in this thread report frequencies of a handful of crashes in a month or a week whereas I’m experiencing them so often. I don’t know whether this is related to my system being highly customized:
- I’m using a rooted, self compiled FPOSOS (still 1.1.7 version),
- I disabled some system apps (Browser, Cell Broadcast, E-Mail, HTML Viewer, One Time Init, Pico TTS, SIM-Toolkit, VoiceDialer, QuickSearch)
- I’m using the built-in encryption,
- I’m using AFWall+, XPrivacy (hence XPosed as well), Orbot, some security apps.
Maybe one of the system apps shouldn’t be disabled (though I don’t know which one could be the culprit), but it’s rather implausible (at least to me) that the other three points could lead to system crashes. 
Starting to analyze the issue
Anyway, enough complaints from my side. 
Let’s get to hopefully helpful information: As mentioned above, I did some testing and adb logging as already proposed by @jaymanu in this thread (see below for how I did this). I just skimmed through the log files and only found the following noticeable lines:
21593 I/Choreographer( 2858): Skipped 154 frames! The application may be doing too much work on its main thread.
[...]
21602 I/Choreographer( 3062): Skipped 159 frames! The application may be doing too much work on its main thread.
which also occur in the following excerpt of the log file’s tail:
21591 I/DisplayManagerService( 2858): Display device changed: DisplayDeviceInfo{"Integrierter Bildschirm":
uniqueId="local:0", 1080 x 1920, 60.0 fps, supportedRefreshRates [60.0], density 440, 440.0 x 440.0 dpi,
appVsyncOff 0, presDeadline 17666667, touch INTERNAL, rotation 0, type BUILT_IN, state OFF,
FLAG_DEFAULT_DISPLAY, FLAG_ROTATES_WITH_CONTENT, FLAG_SECURE,
FLAG_SUPPORTS_PROTECTED_BUFFERS}
21592 V/ActivityManager( 2858): Display changed displayId=0
21593 I/Choreographer( 2858): Skipped 154 frames! The application may be doing too much work on its main thread.
21594 D/SurfaceFlinger( 229): Set power mode=0, type=0 flinger=0xb6482000
21595 D/qdhwcomposer( 229): hwc_setPowerMode: Setting mode 0 on display: 0
21596 I/PowerManagerService( 2858): Waking up from sleep (uid 1000)...
21597 I/DisplayPowerController( 2858): Blocking screen on until initial contents have been drawn.
21598 W/XPrivacy/XActivityManagerService( 2858): Sleeping=true
21599 W/XPrivacy/XActivityManagerService( 2858): Sleeping=true
21600 V/KeyguardServiceDelegate( 2858): onScreenTurnedOn(showListener = com.android.internal.policy.impl.PhoneWindowManager$2@254ba057)
21601 W/IInputConnectionWrapper( 3062): showStatusIcon on inactive InputConnection
21602 I/Choreographer( 3062): Skipped 159 frames! The application may be doing too much work on its main thread.
21603 D/wpa_supplicant(12296): wpa_driver_nl80211_driver_cmd SETSUSPENDMODE 1 len = 0, 4096
[...]
21682 I/WindowManager( 2858): Suppressed redundant power key press while already in the process of turning the screen on.
21683 W/WindowManager( 2858): Keyguard drawn timeout. Setting mKeyguardDrawComplete
21684 D/su (14995): sending code
21685 D/su (14997): client exited 0
21686 D/su (14996): child exited
This is indeed the end of the file - the abrupt cut shows the moment when the phone crashed. In another case, the file actually ended like this:
W/NetworkLog( 5254): External storage /storage/emulated/0/networklog.txt not available
W/Networ
I don’t know what I/Choreographer is and if this really causes the issue. In fact, I’m not really familiar with that kind of stuff, so I might have overlooked something and someone else might find more interesting lines. However, as you can see, the log file has 20.000 lines and thus I don’t want to include it here.
@keesj: Could this help to debug the issue? If the log files might be of any value to you, I could send them by e-mail.
How to do the logging
It might be helpful if other affected users do this as well to debug the issue. If you can trigger crashes and want to log them as well, here is how I did it (on Ubuntu Linux, should be similar on other OS’s):
- You need to have
adb installed on your PC (see here for Windows; under Ubuntu just install the package android-tools-adb).
- On the phone, open Settings > About phone and tap on Build number multiple times to activate the developer settings. Then go to Settings > Developer settings and enable USB debugging.
- Connect your phone to your PC via USB. Confirm the USB Debugging request on the phone screen and disable all entries in the connection mode menu.
- On the PC, open a terminal, check whether the phone gets detected and take a snapshot of the logcat before the crash:
adb devices adb logcat > Logs_before_FP2-Crash.log
Hit enter and then press “Strg+C” to stop it.
- Start the logging again (without interrupting it this time):
adb logcat > Logs_FP2-Crash.log
- Try to trigger the crash on the phone.
Afterwards, take a program designated to compare two text files to do exactly this with the two log files you produced. Jump to the end of the first log file and find the corresponding line in the second log file. Thereby, you’ll be able to identify a moment before the crash happened in the second log file and you’ll only have to look for interesting stuff behind that point.
Btw I noticed some additional strange behaviour directly after some of the crashes (I did it 4 times in a row):
- Once 4 phone partitions popped up as volumes on my PC screen directly after the crash.
- Once my PC OS crashed: the screen did not respond to any mouse or keyboard input (not even to Magic SysRq key) and I needed to reboot it via power button.
- Once both happened.
Anyway, I don’t know if all that really helps to track down the issue - I’m a bit sceptical as well. 
