Lenovo S650 update to VibeUI 2.0 1439

This post is a follow up on my older posts on Lenovo VibeUI KitKat ROM. I settled with version VibeUI 1.5 (1427) for about a year, in spite of hte following issues:

1. Waze always had a dark overlay on the map during navigation with eventual flickering, to the extent that is was completely unusable for navigation as the map was hardly visible. I am not aware of any workaround for this issue, other than using alternative navigation software.
2. Google Maps navigation is always crashing after a few minutes. The issue was narrowed down to affect newer versions, and downgrading to 8.0.0 proved to be a stable temporal workaround.
3. Security - in more particular, the lack of regular security updates and recently disclosed android related vulnerabilities frightened me at this stage.

Lenovo published a firmware update for S650 smartphones on the 25th of September last year, but at I did not see a compelling reason to install it right away, I was rather waiting for subsequent updates but they did not come. I decided to upgrade and yesterday night I found time for it.

The upgrade procedure

I cleaned up both internal and external storage, and made sure the following files are present to the external storage:

• VIBEUI_V2.0_1439_7.3.1_ST_S650_WC52.zip from vibeui.com
• 5-31_GApps_Minimal_4.4.2_signed.zip which I already had from my last download
• superuser.zip - com.koushikdutta.superuser which I also already downloaded earlier.

I took a backup of my call logs and text messages, copied important data to my computer, then booted into recovery and created a full TWRP backup. Read my previous posts for details on this step.

After wiping data, cache and dalvik cache partitions I installed the update from within TWRP recovery, then immediately applied superuser.zip. Before reboot, I opened a terminal from within TWRP, and manually mounted the system partition and deleted Chinese apps that I do not need:

mkdir /tmp/s
mount -t ext4 /dev/block/mmcblk0p5 /tmp/s
# change directory to /tmp/s/vendor/operator/app/ via TWRP menu as the built in terminal 
# does not allow you to do that
mv Len* .. # move LenovoPhonemgr.apk which I decided to keep this time
rm *.apk 
mv ../Len* . # move back the app
# change to /tmp/s/priv-app/ via TWRP
rm GameWorld_Phone.apk Youyue.apk
# change to /
umount /tmp/s

Once this was done, but before installing the google apps package, I rebooted the phone, and chose English language in the setup wizard. This was a bit tricky due to the many pop-ups, but still much easier without the Google setup wizard, which would have been run in Chinese had I installed Google Apps in one shot. After language selection and initial setup, I went back to recovery and installed google apps minimal. After booting the system the google setup wizard was greeting me in English...

Later I restored my call logs and text messages as well as application data of some of my key apps. This I had to do manually via and adb shell as Super Backup failed to restore application data even with root privileges granted. My approach was to do some setup of the critical apps manually, so the data files are were created by the app itself with appropriate permissions and ownership, then I overwrote the content of the necessary files with cat $BACKUP > $DATAFILE.

First impressions

Both Google Maps and Waze works fine with this app. I got used to the previous ROM and found stock theme and UI changes annoying. I quickly tailored the theme and launcher according to my preferences.

The Goolge Apps minimal package was outdated, which gave me some application crashed before and during updated, but once the new version of Google packages were installed, everything worked fine.

Unfortunately, according to Stagefright Detector the new version is even a bit more vulnerable than the previous one.

Stagefright

As mentioned above, this new ROM contains one more Statefright related vulnerability compared to VibeUI 1.5, and Lenovo does offer security patches, but not for this phone.

As a countermeasure, I disabled automatic retrieval of multimedia message, from the mail messaging app as recommended here and revoked MMS permissions from any other application. Of course I would be happier if Lenovo provided security updates regularly and more consistently across reasonably new mobile devices.

Firefox 37 and corporate intranet

After a recent update on Ubuntu 14.04.2 LTS, no connection to the beloved corporate expense reimbursement application could be established any more. Of course I realised this situation at a time when I urgently needed to use that application.

Background

Long time ago I have installed the Firefox extension SSL Version Control which allows me to use stronger encryption by defaults, while enables lowering the security level easily if needed. I quickly realised that requiring TLS 1.2 everywhere was not be a workable practice, so I settled with TLS 1.0 back then to get rid of at least SSLv3. Google for POODLE to learn more about the reasons.

I still needed to occasionally allow SSLv3 from time to time in order to be able to use corporate web applications hosted on improperly configured servers - this is the reality of a huge US based enterprise in 2015, no comment.

In Firefox 34 (released in December 2014), SSLv3 was disabled by default, but could be easily enabled by end user either via the extension referred above or changing property security.tls.version.min in about:config as explained here.

Firefox 37, released right before April Fool's Day 2015, disabled insecure TLS version fallback as a security improvement. This means that nor the extension, nor setting the above mentioned configuration property to 0 would allow me any more connect to sites via SSLv3. It is suggested to set another property, security.tls.version.fallback-limit to 1 and file a bug noting the URL of the site where this is needed.

Obviously, I did not submit a but report to Mozilla with a link to our intranet expense reimbursement application. Apparently, setting fallback limit to 1 or 0 did do the magic. Needless to say at that point I was a bit annoyed and under time pressure.

The solution

To make the long story short, Firefox 37 by default does not even respect user-configurable whitelisting, but uses a hardcoded list of hosts. Disabling the use of the compiled-in whitelist allows the end user to provide a custom list of hosts where insecure TLS version fallback should be allowed.See bugs 1114816 and 1084025 for details.

I ended up with disabling the SSL Version Control extension and manually tweaking TLS fallback related properties as shown below.

security.tls.version.max = 3 # default value
security.tls.version.min = 1
security.tls.insecure_fallback_hosts = w3.***.com
security.tls.insecure_fallback_hosts.use_static_list = false
security.tls.version.fallback-limit = 1

Update: Two days ago, the host running the corporate expense reimbursement application was reconfigured to support TLS 1.0 (but not any newer version). The configuration properties above have been updated to reflect this change.

Generating PGP keys stronger than 4096 bit RSA

I will be transitioning from the pgp key I have been using for four years to a new one. The decision to move to a new one was taken four years ago, and recent news on privacy, applied cryptography and leaked information about practices of various authorities seem to resonate with my plans.

Four years ago I moved to a 4096-bit pgp key, and now, as I am about to generate a new one, the question about the preferred cryptographic algorithms and key sizes arises. Currently, GnuPG seems to support a maximum RSA key size of 4096. This post covers my process of generating a 8192-bit RSA key, and of course using SHA512, a hash function much stronger than SHA-1.

The limitation of GnuPG as shipped with Ubuntu 14.04

Many have written about the limitation of GnuPG to only support generating RSA keys up to 4096. This limitation is not imposed by the algorithm itself, but merely a decision of developers which may or may not be related to export regulations and similar legislation around the use of cryptographic technologies in the United States.

I will not go into any discussion on such legislative restrictions, and I will focus on technology stating that I am not a citizen of the US and any US law do not apply to me at my current location.

As GnuPG is open source free software, anyone can download the source, and alter the constant defining maximum key size to lift the current limitation. As there is no technical limitation why one could not generate 8196-bit, one can just change keygen.c and increase the key size limit, then compile and use the modified version. It is important to note here, than an unmodified GnuPG will works perfectly with a 8192-bit key, the only restriction is it will not offer one to create such keys out-of-the-box.

Avoiding recompilation without hacking binaries

There is a little known feature of GnuPG that allows one to generate 8192-bit keys without any modification. It supports unattended key generation that reads the configuration form an input file, and this esoteric feature is not subject to the limitation mentioned above.

$ cat params.txt
Key-Type: RSA
Key-Length: 8192
Subkey-Type: RSA
Subkey-Length: 8192
Name-Real: Tibor B****
Name-Email: tibor.b*****@gmail.com
Creation-Date: 20150101T000000
Expire-Date: 20191231T000000
Passphrase: !!!change it!!!
Preferences: S10 S9 S13 H10 Z3 Z2 Z1
%commit
%echo done
$ gpg --batch --gen-key params.txt

GnuPG 1.4.16, the version which ships with Ubuntu, gives the following error.

gpg: fatal: out of secure memory while allocating 4228 bytes

Enter GnuPG 2

Fortunately, GnuPG 2, which is the new modular version of GNU Privary Guard, is also packaged, one just has to install gnupg2, currently, version 2.0.22 ships with Ubuntu 14.04. GnuPG 2 does not have memory allocation issues and is able to generate the 8192-bit key.

Entropy

In order to increase the speed of key generation, I have installed the package rng-tools. This smart software allows one to use the hardware based true random number generator available on most modern PC chipsets and feed the kernel entropy pool. I have found this small utility to make an extremely big difference in accelerating key generation by drastically increasing the bandwidth of the random device, without trade-offs in security. I fail to see why this package is not part of the base installation of Ubuntu.

Transitioning to the new key

The process of transitioning to the new key has been described by others in sufficient detail, please see here for a good HOWTO.

Make sure to also update your gpg config, and read up on the current status of the cipher and digest algorithms supported by GnuPG. Pick your preferred ones wisely.

Ubuntu 14.04 - openconnect VPN and network manager

Openconnect VPN

After having reinstalled my thinkpad with Ubuntu 14.04, I noted that I could not connect to one of my client's VPN via GUI. The VPN authentication dialog simply did not pop up after clicking the VPN profile on the network manager indicator/applet. No error displayed, no useful information in syslog. The only line I could correlate with connection attempts looked like the one cited below. Note that this line in itself does not indicate any error, it is present during normal operation as well, the point here is that no other lines related to VPN were displayed at all.

Aug 31 14:43:43 gluon NetworkManager[997]: <info> VPN service 'openconnect' disappeared

The VPN itself is Cisco Anyconnect, and connecting to it via the commandline using openconnect worked fine. I use password based authentication in tandem with a hardware token generator, no client certificate involved in this configuration. All required packages are installed, and if I create another VPN profile in network manager with an invalid gateway URL, then I do get the authentication dialog displaying an error.

As this used to work properly on Ubuntu 12.10, I googled for regressions and found forum threads and this and another bug report but they have not helped to resolve my case.

To make the long story short, I found where network manager persists connection profiles, and when checking the VPN connection profile in question, I found it contained invalid file paths to certificates, which typically seem to be the result of handling the 'None' option in the wrong way.

sudo cat /etc/NetworkManager/system-connections/${VPN_PROFILE_NAME} | grep cert
usercert=/home/tibi/(null)
cacert=/home/tibi/(null)
authtype=cert
# simply delete the lines with invalid path
# and optionally set authtype=password, but actually it does not matter.

The malfunction seems to be the result of using the build-in import/export functionality. The exported connection profile simply contains (null) for the certificates if password based authentication is used, however, during import this value is simply appended to the user's home directory.

[openconnect]
Description=****
Host=vpn.****.hu
CACert=(null)
Proxy=
CSDEnable=0
CSDWrapper=
UserCertificate=(null)
PrivateKey=(null)
FSID=0

Anyway, I would have expected better visual feedback or error logging.

Optimus and Ubuntu 14.04

This post takes the reader through Nvidia Optimus related tweaks I applied on my Lenovo W530 after upgrading it to Ubuntu 14.04. I have dedicated a a series of 5 posts to the same topic on Ubuntu 12.10. Please take those previous posts as prerequisite knowledge, as I do not intend to repeat the detailed descriptions I have already provided. As outlined earlier, my goal is to get a very stable system with extended battery life, and the ability to connect an external projector to the VGA port and cover the following use cases (a verbatim copy of the enumeration from a previous post):

• Extend the desktop to the external monitor.
• Get a cloned output of the primary monitor to the external monitor with panning support - this means, that in the case the external monitor's resolution is smaller, a smaller viewport will follow the mouse and show a cropped clone of the desktop's content. The viewport will follow the mouse to show the area of interest.
• Run LibreOffice presentations with the external monitor showing the current slide and the primary monitor showing the presentation overview, notes and time.
• Never ever get X freezes or kernel lockups on suspend/resume with or without an external monitor connected.
• Switching to virtual terminals should always work in a bulletproof manner. The box is a workhorse, cannot allow hiccups.
• Might sound like a small detail, but a properly displayed usplash/plymouth is also important, not only for cosmetic purposes.

Prime and Optimus support out of the box

As documented in the official wiki of the nouveau driver, Optimus support has improved much in the open source driver, and automatic power management of the discrete graphics chip is also documented to work properly with Linux kernel 3.13. This means, Optimus should work out of the box: the discrete graphics chip should be turned on when needed, and fully powered off automatically when idle for 5 seconds.

The following command listing can be used to quickly review the current state of the two graphics chips. As it can be seen, the discrete chip's status is DynOff meaning that automatic power management is active and the device is currently powered off. Further, xrandr lists all outputs - those wired to the integrated chip as well as those wired to the Nvidia GPU.

uname -a
Linux gluon 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
sudo cat /sys/kernel/debug/vgaswitcheroo/switch
0:DIS: :DynOff:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0
xrandr -q | grep conn # confirms that outputs wired IDG and also those wired to DIS are visible to X
LVDS2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
VGA2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
LVDS-1-1 disconnected
VGA-1-1 disconnected
DP-1-1 disconnected
DP-1-2 disconnected
DP-1-3 disconnected

When connecting an external display, DIS will be powered on automatically and outputs are detected and handled almost perfectly by Ubuntu out of the box (more on this later). However, once DIS has been powered on, it cannot be powered off, even if no external monitor is connected. Further, if DIS is not powered off, the Thinkpad cannot be suspended, which is a pain.

sudo cat /sys/kernel/debug/vgaswitcheroo/switch 
0:DIS: :DynPwr:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0
echo "OFF" | sudo tee /sys/kernel/debug/vgaswitcheroo/switch
OFF
sudo cat /sys/kernel/debug/vgaswitcheroo/switch 
0:DIS: :DynPwr:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0

Others have experienced slightly different behaviour, in particular DIS being powered on (DynPwr) at boot, the common phenomenon is the inability to power off DIS via the command line. The author has suggested disabling the new automatic power management feature to allow the user to explicitly power on and power off the devices as needed.

Disabling automatic power management of the Nvidia graphics chip

Adapting the suggestion to Ubuntu 14.04 involved editing bootloader configuration so it passes the additional argument nouveau.runpm=0 to the kernel.

sudo nano /etc/default/grub # find and edit the GRUB_CMDLINE_LINUX_DEFAULT as follows:
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nouveau.runpm=0"
sudo update-grub
sudo init 6 # reboot

Having rebooted the system, I verified that the configuration change indeed took effect. Power states DynPwr and DynOff disappeared, and manual power state switching could be successfully performed the same way as in Ubuntu 12.10.

cat /proc/cmdline # verify nouveau.runpm=0 was successfully passed to the kernel
BOOT_IMAGE=/boot/vmlinuz-3.13.0-35-generic.efi.signed root=UUID=2a924e40-1f12-4c5a-8f22-556d6e66ffa6 ro quiet splash nouveau.runpm=0 vt.handoff=7
sudo cat /sys/kernel/debug/vgaswitcheroo/switch # verify current power state
0:DIS: :Pwr:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0
echo "OFF" | sudo tee /sys/kernel/debug/vgaswitcheroo/switch # power off DIS
OFF
sudo cat /sys/kernel/debug/vgaswitcheroo/switch # verify power state again
0:DIS: :Off:0000:01:00.0
1:IGD:+:Pwr:0000:00:02.0

The surprise

Based on my knowledge of how outputs are wired on W530, my experiences on Ubuntu 12.10 and my observation in 14.04 so far I assumed that with DIS powered off, xrandr -q would not list the external VGA and DisplayPort outputs, or at least that connecting an external display to those outputs wired to the Nvidia chip would not do anything if the discrete GPU is powered off.

Contrary to my expectations, even if DIS is powered OFF, the external VGA and DiplayPort outputs are available to X, and hooking up an external monitor works the same way after this tweak as before. The Thinkpad can now be suspended, even with external outputs connected.

However, if an external display was active at the time the laptop was suspended, compiz crashed once the system resumed. This is a minor glitch resulting in a prompt to submit a bug report, and compiz is automatically restarted and fully functional even in this case. To be on the safe side, I would disconnect external displays before suspending - this seems to make sense anyway.

Disabling the discrete GPU on boot by default to save power

In order to save power, I disabled the Nvidia GPU during the boot process. I wanted X to be started with both IDG and DIS powered on, to make sure all outputs are properly detected. Customising /etc/rc.local is the approach I settled with, as this file is run after all other services, including X, have been started. This script does not do anything on a clean install, so all one needs to do is to insert one line before exit 0:

echo "OFF" > /sys/kernel/debug/vgaswitcheroo/switch
exit 0

External VGA working almost perfectly

In general I can confirm a lot of progress related to Optimus since 12.10. Outputs are detected out of the box, no need for a second X servers, special Xorg configuration and hybrid screenclone or other voodoo magic. The desktop can be extended to the external VGA, resolution and other parameters all configured using the GUI.

I observed one issue while testing LibreOffice presentations with the external monitor showing the current slide and the primary monitor showing the presentation overview. The current slide, rendered to the external VGA in fullscreen mode did not properly update. At first sight it seems to always be 1 slide behind compared to the LCD of the thinkpad, but moving the cursor over this area of the screen made the area around the cursor refresh, unveiling parts the actual current slide (XDamage came to my mind).

This issue I have not yet resolved. I do not have an external monitor at home, so I will have to wait and squeeze the investigation into my schedule during working hours.

Update: Workaround

I have settled with launching watch -n xrefresh before starting my presentation, and terminating it once I am done. This essentially forces a full refresh every second which yields acceptable experience. Not optimal, but just good enough.

Ubuntu 14.04 on an SSD

I recently upgraded my Lenovo W530 thinkpad to 14.04. As this is my primary workstation which I consider mission critical, one objective was to perform a clean install and restore my development and office environment as quickly as possible. I have set myself a target of 2 hours. The only thing considered a risk was Lotus Notes, which had to be migrated and upgraded at the same time. This post covers disk related settings I applied, and can be considered as a follow up on my two years old 'Ubuntu 12.10 on an SSD'.

I have installed Ubuntu via an UEFI bootable USB key, and during installation, reused the SSD and kept the present partition scheme.

$ sudo gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 500118192 sectors, 238.5 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 3E979DF9-E126-4EB8-AAF1-D17DEAD86D1E
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 500118158
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          133119   64.0 MiB    EF00  EFI System
   2          133120        67241983   32.0 GiB    0700  Linux filesystem
   3        67241984        75630591   4.0 GiB     8200  Linux swap
   4        75630592       500118158   202.4 GiB   0700  Linux filesystem

During the installation process, all partitions except the EFI System partition have been reformatted. Later, I applied some changes to mount options.

To discard or not to discard: that is the question

Well, almost. Whether to discard or not should not be a question: in order to ensure the longevitiy of an SSD, the operating system has to communicate when unused blocks to the drive, so it can employ proper wear leveling. When to discard is the question one should ask himself, there are currently two options which are commonly used:

• Discard as the block becomes free, that is, as part of the file delete operation. This is a mature, very safe option supported by most filesystem drivers, but impacts the performance, especially when many small files are deletes.
• Discard all blocks that have become unused in one shot, on a scheduled basis, typically weekly. This concept is supported by some filesystem drivers (but e.g. VFAT does not support it) and is considered more performant in general, however, it can cause data loss issues on some SSDs if performed when I/O load is high. The current implementation is known to be safe on Intel and Samsung SSDs. Read more on this here

The default behavior in Ubuntu 14.04 is to run fstrim weekly via cron. The command only performs trimming on Intel and Samsung SSDs by default, and simply exits if any other SSD is found. My SSD is from Lenovo (P/N: 0A65620), and is a rebranded Samsung PM830 self encrypting disk featuring FIPS certified hardware based full disk encryption with AES-256. A quick test confirmed that my SSD is recognised as a supported device, so specifying the discard for ext4 partitions is not needed any more.

sudo fstrim -v /home
/home: 179466240 bytes were trimmed
sudo fstrim -v /
/: 59457536 bytes were trimmed

Still, partitions with VFAT or other filesytems without fstrim support should be mounted with the discard option.

Swap

I tuned the OS via sysctl variables to use swap only if really needed, as described in 'Ubuntu 12.10 on an SSD'.

# transient changes until reboot
echo 1 | sudo tee /proc/sys/vm/swappiness
echo 50 | sudo tee /proc/sys/vm/vfs_cache_pressure

# persistent changes
cat <<EOF | sudo tee -a /etc/sysctl.conf
vm.swappiness=1
vm.vfs_cache_pressure=50
EOF

Further tweaks

I configured tmpfs to be mounted over /tmp in just the same way I did with Ubuntu 12.10, limiting the maximum size of the temporary filesystem to 25% or RAM, and adding mount options for security.

cat <<EOF | sudo tee -a /etc/fstab
tmpfs /tmp tmpfs nosuid,nodev,size=25% 0 0
EOF

Below is a verbatim copy of the bottom lines of the post 'Ubuntu 12.10 on an SSD', it still applies.

As a closing note, end-user behaviour also matters much. I try to pay attention to creating transient files under /tmp - if you compile a lot, this matters much. One should find a healthy balance between being SSD-aware and being too paranoid about it. I investigated methods to decrease disk writes caused by syslog - many suggest to mount a tmpfs over /var/log which would mean all your logs are lost when you reboot, making any kind of audit or post mortem debugging impossible. I ended up sticking to the commit=120 mount option after some calculations. You should do the math and enjoy your disk. As with any kind of disk, check the SMART attributes from time to time, and make sure you have take backups on a regular basis.

Lenovo S650 VibeUI update 1427

This post is a follow up on my recent posts on Lenovo VibeUI KitKat ROM, which is a major step forward with many advantages, however, I experienced anomalies with 3 Google provided applications on this ROM.

1. Google Authenticator generates invalid TOTP tokens, which I have describes in detail last month. My workaround I settled with was to permanently switch to FreeOTP, an open source TOTP app that, besides working properly on the new ROM, feels superior to Google Authenticator.
2. Google Maps navigation is always crashing after a few minutes. The issue was narrowed down to affect newer versions, and downgrading to 8.0.0 proved to be a stable temporal workaround.
3. Hangouts on the new ROM always exited when attempting to join a video call, audio-only calls were working fine. This issue remained unresolved as I preferred to use my thinkpad for video calls - and I do not consider hangout video calls critical anyway.

Lenovo published a firmware update for S650 smartphones on the 3rd of July, I downloaded and installed it over night out of curiosity.

The upgrade procedure

First, I downloaded the update itself and recent version of google apps minimal package. I made sure the following files are copied to the external storage:

• S650_S916_VIBEUI_V1.5_1427_2_ST_0CF6.zip from vibeui.com
• 5-31_GApps_Minimal_4.4.2_signed.zip
• superuser.zip - com.koushikdutta.superuser

I took a backup of my call logs and text messages, then booted into recovery and created a full TWRP backup. Read my previous posts for details on this step.

After wiping data, cache and dalvik cache partitions I installed the update from within TWRP recovery, then immediately applied superuser.zip. Before installing the google apps package, I manually freed up some space on the system partition by deleting apps that I do not need:

mount /system
rm /system/vendor/operator/app/*.apk 
# BaiduSearch.apk DuomiMusic.apk GaodeMap.apk Lakala.apk LenovoPhonemgr.apk MobileQQ.apk 
# ReadingJoy.apk SinaWeather.apk SinaWeibo.apk SohuNews.apk SohuTv.apk Tmall.apk UCBrowser.apk
rm /system/app/BaiduInput.apk
rm /system/priv-app/GameWorld_Phone.apk
rm /system/priv-app/Youyue.apk
umount /system

Once this was done, but before installing the google apps package, I rebooted the phone, and chose English language in the setup wizard. I found this much harder to do if google apps was installed in one shot, before the initial boot & setup as the google setup wizard (in Chinese) was interfering with the native setup process... After language selection and initial setup, however, I went back to recovery and installed google apps minimal. After booting the system the google setup wizard was greeting me in English...

Later I restored my call logs and text messages as well as application data of come of my key apps.

First impressions

This updated fixed the Google Hangouts crash issue.

Unfortunately, Google Maps is still crashing after a few minutes of navigation. This issue, however, can be resolved by downgrading to version 8.0.0 of Google Maps, so it is not a show stopper.

Collecting debug info

As the Google Maps crash was very easy to reproduce, I decided to collect logs via ADB logcat and narrow down the data the lines related to the crash:

$ cd android-sdk-linux/platform-tools
$ ./adb logcat -c
$ ./adb logcat > /tmp/logcat14.txt
$ # wait until Google Maps navigation crashes, then immediately Ctrl-C

Taking an initial view on the data one realises the information is simply too much for human eyes. I started grepping for "com.google.android.apps.maps", then identified the process ID which was 31858, and digging deeper I realised that navigation made the GL_THREAD die with SIGSEGV, that is, a segmentation fault. I ended up applying cropping unrelated logs from before the crash and after the diagnostics had completed, and also filtered out some noice with the following command, which yielded an output that can be processed manually and that demonstrated the 3 phases that android performs to collect data for diagnostics on application (native) crashes.

$ grep -A 100000000 "Fatal signal 11" /tmp/logcat14.txt | grep -B 100000000 "native_crash should" \
| grep -v "AlarmManager" | grep -v "PowerManager" > /tmp/logcat_filtered.txt
$ less -S /tmp/logcat_filtered.txt
F/libc    (31858): Fatal signal 11 (SIGSEGV) at 0x00000016 (code=1), thread 715 (GL_THREAD)
F/libc    (31858): Send stop signal to pid:31858 in void debuggerd_signal_handler(int, siginfo_t*, void*)
D/AEE/AED (  133): $===AEE===AEE===AEE===$
D/AEE/AED (  133): p 0 poll events 1 revents 0
D/AEE/AED (  133): not know revents:0
D/AEE/AED (  133): p 1 poll events 1 revents 0
D/AEE/AED (  133): not know revents:0
D/AEE/AED (  133): p 2 poll events 1 revents 1
D/AEE/AED (  133): aed_main_fork_worker: generator 0x12ca0d0, worker 0xbedb5918, recv_fd 15
D/AEE/AED (  133): p 3 poll events 1 revents 0
D/AEE/AED (  133): not know revents:0
D/AEE/AED (  133): p 4 poll events 1 revents 0
D/AEE/AED (  133): not know revents:0
I/DEBUG   ( 1047): handle_request(15)
I/DEBUG   ( 1047): check process 31858 name:droid.apps.maps
I/DEBUG   ( 1047): tid 715 abort msg address is:0
I/DEBUG   ( 1047): BOOM: pid=31858 uid=10112 gid=10112 tid=715
D/SurfaceFlinger(  139): ffi_3d_jank timespan = 33.007385 jankCount = 1
I/DEBUG   ( 1047): [OnPurpose Redunant in preset_info] pid: 31858, tid: 715, name: GL_THREAD  >>> com.google.android.apps.maps <<<
I/DEBUG   ( 1047): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
I/DEBUG   ( 1047): Build fingerprint: 'Lenovo/sofina/S650:4.4.2/KOT49H/VIBEUI_V1.5_1427_2_ST_S650.:user/release-keys'
D/ADB_SERVICES(28073): adb fdevent_process list (11) (20) 
I/DEBUG   ( 1047): pid: 31858, tid: 715, name: GL_THREAD  >>> com.google.android.apps.maps <<<
I/DEBUG   ( 1047): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000016
I/DEBUG   ( 1047):     r0 0000000c  r1 00000000  r2 4412ec00  r3 00000000
I/DEBUG   ( 1047):     r4 5f8c4d72  r5 62987e58  r6 64092a98  r7 000010f8
I/DEBUG   ( 1047):     r8 418a0900  r9 4251a500  sl 62987e40  fp 407aee6c
I/DEBUG   ( 1047):     ip 00000000  sp 62a85c30  lr 418a4b94  pc 418a4c00  cpsr 00070010
I/DEBUG   ( 1047): 
I/DEBUG   ( 1047): backtrace:
I/DEBUG   ( 1047):     #00  pc 00027c00  /system/lib/libdvm.so
I/DEBUG   ( 1047):     #01  pc 0002f2f0  /system/lib/libdvm.so (dvmMterpStd(Thread*)+76)
I/DEBUG   ( 1047):     #02  pc 0002c7d4  /system/lib/libdvm.so (dvmInterpret(Thread*, Method const*, JValue*)+188)
I/DEBUG   ( 1047):     #03  pc 00062ef9  /system/lib/libdvm.so (dvmCallMethodV(Thread*, Method const*, Object*, bool, JValue*, std::__va_list)+340)
I/DEBUG   ( 1047):     #04  pc 00062f1d  /system/lib/libdvm.so (dvmCallMethod(Thread*, Method const*, Object*, JValue*, ...)+20)
I/DEBUG   ( 1047):     #05  pc 000575c5  /system/lib/libdvm.so
I/DEBUG   ( 1047):     #06  pc 0000d600  /system/lib/libc.so (__thread_entry+72)
I/DEBUG   ( 1047): 
I/DEBUG   ( 1047): stack:
I/DEBUG   ( 1047):          62a85bf0  5f8c4d60  /data/dalvik-cache/data@app@com.google.android.apps.maps-1.apk@classes.dex
I/DEBUG   ( 1047):          62a85bf4  41901ad7  /system/lib/libdvm.so
I/DEBUG   ( 1047):          62a85bf8  64092a98  
I/DEBUG   ( 1047):          62a85bfc  5f8c4d60  /data/dalvik-cache/data@app@com.google.android.apps.maps-1.apk@classes.dex
I/DEBUG   ( 1047):          62a85c00  4193ded8  /system/lib/libdvm.so
I/DEBUG   ( 1047):          62a85c04  64092a98  
I/DEBUG   ( 1047):          62a85c08  64092ac0  
I/DEBUG   ( 1047):          62a85c0c  5f8c4d72  /data/dalvik-cache/data@app@com.google.android.apps.maps-1.apk@classes.dex
I/DEBUG   ( 1047):          62a85c10  62987e58  
I/DEBUG   ( 1047):          62a85c14  64092a98  
I/DEBUG   ( 1047):          62a85c18  000010f8  
I/DEBUG   ( 1047):          62a85c1c  418a0900  /system/lib/libdvm.so
I/DEBUG   ( 1047):          62a85c20  62987e68  
I/DEBUG   ( 1047):          62a85c24  425b39e0  /dev/ashmem/dalvik-heap (deleted)
I/DEBUG   ( 1047):          62a85c28  407aee6c  /system/lib/libft2.so
I/DEBUG   ( 1047):          62a85c2c  4189f880  /system/lib/libdvm.so
...
D/dalvikvm(  696): create interp thread : stack size=128KB
D/dalvikvm(  696): create new thread
D/dalvikvm(  696): new thread created
D/dalvikvm(  696): update thread list
D/dalvikvm(  696): threadid=88: interp stack at 0x63ee3000
D/dalvikvm(  696): threadid=88: created from interp
D/dalvikvm(  696): start new thread
D/dalvikvm(  696): threadid=88: notify debugger
D/dalvikvm(  696): threadid=88 (Error dump: data_app_native_crash): calling run()
...
D/AES     (  696): ExceptionLog: notify aed
D/AES     (  696):     process : com.google.android.apps.maps
D/AES     (  696):      module : com.google.android.apps.maps v801010122 (8.1.1)
D/AES     (  696): 
D/AES     (  696):       cause : data_app_native_crash
D/AES     (  696):       pid : 31858
W/AES     (  696): native_crash should be processed by aee already

As highlighted above, downgrading Google Maps to 8.0.0 or turning to alternatives (Waze for online, MapFactor for offline navigation) gets around this issue. My motivation for collecting and filtering logs was rather curiosity that the intention to spend much time debugging and tinkering with this closed source application.