From @Quallenauge on February 2, 2018 10:45

It should be tested:

The current firmware is able to launch at the device.
The current firmware should not have device specific errors (like missing firmware / configuration files, which are available for the L-version).

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#1

From @vladimiroltean on February 19, 2018 21:34

Together with Christian I started looking into the bootloader's source code to understand what exactly triggered the deletion of my (or should I say our) DRM keys.
In fact, I was monitoring my DRM L1 security level status quite closely, and I am quite confident that the moment I lost my DRM keys was exactly during the process of flashing back the stock image, in fastboot, for some tests.
Basically there are 2 places in app/aboot/aboot.c where the send_delete_keys_to_tz() function is called:

1. Now this pretty much says it all: we are looking at the void cmd_erase_mmc(const char *arg, void *data, unsigned sz) function. If you ask it to erase any other partition except userdata, it looks like "bam", you lose your encryption keys.

2550 #if VERIFIED_BOOT
2551 #if !VBOOT_MOTA
2552 »       if(!(strncmp(arg, "userdata", 8)))
2553 »       »       if(send_delete_keys_to_tz())
2554 »       »       »       ASSERT(0);
2555 #endif
2556 #endif

2. I don't quite understand this very well, so feedback is appreciated. Trigger dm-verity and enrage the gods of trust? Under what conditions can we enter reboot_mode == DM_VERITY_KEYSCLEAR?

4304 #if VERIFIED_BOOT
4305 #if !VBOOT_MOTA
4306 »       else if (reboot_mode == DM_VERITY_ENFORCING)
4307 »       {
4308 »       »       device.verity_mode = 1;
4309 »       »       write_device_info(&device);
4310 »       } else if(reboot_mode == DM_VERITY_LOGGING) {
4311 »       »       device.verity_mode = 0;
4312 »       »       write_device_info(&device);
4313 »       } else if(reboot_mode == DM_VERITY_KEYSCLEAR) {
4314 »       »       if(send_delete_keys_to_tz())
4315 »       »       »       ASSERT(0);
4316 »       }
4317 #endif
4318 #endif

Of course, losing my encryption keys would be too graphic a scene to be shown in this open-source bootloader code, that's why they are just sending the "delete keys" command to the trusted OS that's running in TZ (ARM TrustZone) so it can do the deeds.

Quite unfortunately for my, I deliberately backed up my /dev/block/mmcblk0p29 (keystore) partition and put it to cold storage for moments like this. As it turns out, what I had actually backed up was a zero-filled partition.

So, moral of the story: don't play with fastboot erase, kids! Also, dm-verity something :)
We should consider building the bootloader from source, simply remove the lines that delete the DRM keys (or maybe even disable verified boot altogether), and then distribute it as part of the firmware images (emmc_appsboot.mbn).

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#18

The activities that were opened when the tablet is in portrait mode have previews that are rotated by 90 degrees.
The activities that where opened with the tablet in landscape mode are stretched to 50% of the preview's height, and the upper half of the preview is black.

This can be easily seen by inspecting out/target/product/YTX703L/obj/PACKAGING/target_files_intermediates/lineage_YTX703L-target_files-*/META/boot_filesystem_config.txt and searching for selabel=u:object_r:unlabeled:s0.
This is also a very strong indicator, in my opinion, that nobody actually needs these symlinks (otherwise, SELinux would deny access to unlabeled files.

Treble compatibility requires that we dedicate a partition for userspace hardware support libraries and binaries. Let's use this thread to discuss our possibilities.
What we know so far:

• The device's partition table:

Number  Start (sector)    End (sector)  Size       Code  Name                                                                                                            [10/116]
   1          131072          303103   84.0 MiB    0700  modem                                                                                                                   
   2          393216          393217   1024 bytes  FFFF  fsc                                                                                                                     
   3          393218          393233   8.0 KiB     FFFF  ssd                                                                                                                     
   4          393234          394257   512.0 KiB   FFFF  sbl1                                                                                                                    
   5          394258          395281   512.0 KiB   0700  sbl1bak                                                                                                                 
   6          395282          396305   512.0 KiB   FFFF  rpm                                                                                                                     
   7          396306          397329   512.0 KiB   0700  rpmbak                                                                                                                  
   8          397330          401425   2.0 MiB     FFFF  tz                                                                                                                      
   9          401426          405521   2.0 MiB     0700  tzbak                                                                                                                   
  10          405522          406033   256.0 KiB   FFFF  devcfg                                                                                                                  
  11          406034          406545   256.0 KiB   FFFF  devcfgbak
  12          406546          439313   16.0 MiB    0700  dsp
  13          439314          442385   1.5 MiB     FFFF  modemst1
  14          442386          445457   1.5 MiB     FFFF  modemst2
  15          524288          524351   32.0 KiB    FFFF  DDR
  16          524352          527423   1.5 MiB     FFFF  fsg
  17          527424          527455   16.0 KiB    FFFF  sec
  18          655360          677887   11.0 MiB    FFFF  splash
  19          786432          788479   1024.0 KiB  FFFF  aboot
  20          788480          790527   1024.0 KiB  0700  abootbak
  21          790528          921599   64.0 MiB    FFFF  boot
  22          921600         1052671   64.0 MiB    FFFF  recovery
  23         1052672         1054719   1024.0 KiB  FFFF  devinfo
  24         1179648         1245183   32.0 MiB    FFFF  userstore
  25         1310720         8650751   3.5 GiB     FFFF  system
  26         8650752         9175039   256.0 MiB   FFFF  cache
  27         9175040         9240575   32.0 MiB    FFFF  persist
  28         9240576         9242623   1024.0 KiB  FFFF  misc
  29         9242624         9243647   512.0 KiB   FFFF  keystore
  30         9243648         9243711   32.0 KiB    FFFF  config
  31         9243712         9374783   64.0 MiB    FFFF  oem
  32         9437184         9437247   32.0 KiB    FFFF  limits
  33         9568256         9569279   512.0 KiB   FFFF  mota
  34         9569280         9571327   1024.0 KiB  FFFF  dip
  35         9571328         9636863   32.0 MiB    FFFF  mdtp
  36         9636864         9637887   512.0 KiB   FFFF  syscfg
  37         9637888         9646079   4.0 MiB     FFFF  mcfg
  38         9699328         9700095   384.0 KiB   FFFF  cmnlib
  39         9700096         9700863   384.0 KiB   FFFF  cmnlibbak
  40         9700864         9701631   384.0 KiB   FFFF  cmnlib64
  41         9701632         9702399   384.0 KiB   FFFF  cmnlib64bak
  42         9702400         9702911   256.0 KiB   FFFF  keymaster
  43         9702912         9703423   256.0 KiB   FFFF  keymasterbak
  44         9830400         9830911   256.0 KiB   FFFF  apdp
  45         9830912         9831423   256.0 KiB   FFFF  msadp
  46         9831424         9831439   8.0 KiB     FFFF  dpo
  47         9831440         9833487   1024.0 KiB  FFFF  userencrypt
  48         9833488         9845775   6.0 MiB     FFFF  countrycode
  49         9845776        61071326   24.4 GiB    FFFF  userdata

The current size requirements of our hardware support libraries:

$ du -sh out/target/product/YTX703L/system/vendor/
257M    out/target/product/YTX703L/system/vendor/

Currently the only possibility I see is to use a composite vendor partition, with partition 26 (cache - 256MB) as main and partition 31 (oem - 64MB) as secondary. Init scripts will take care that the secondary vendor partition is mounted inside the primary one.
The issue I see currently is that I'm not sure what support AOSP has for composite vendor partitions (it needs to be able to flash a vendor.img file).

Preamble

Devices with official status in lineage 15.1 needs to comply with
device-support-requirements.
It has to be checked if the implementation fulfills these requirements in order to get accepted.

Charter Version 2018.07.19

Welcome to the LineageOS Device Support Requirements. This document enumerates the requirements that must be met in order for devices to be deemed ship ready for LineageOS releases, beginning with Android Oreo.
To be considered ready, device maintainers MUST meet the requirements presented in this document, including any documents incorporated via reference.

The use of “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” is per the IETF standard defined in RFC2119.

Table of Contents

• Attaining exceptions
  • Process
• Hardware Support
  • Audio
  • RIL
  • Encryption
  • Wifi
  • USB
  • GPS
  • Bluetooth
  • Camera
  • Video Recording
  • Display
  • NFC
  • Fingerprint Sensor
  • IR
  • Accelerometer
  • Gyroscope
  • Proximity
  • Light
  • Other Sensors
  • Accessories
  • Hardware Deviations
• Software support
  • Lineage.mk
  • Lineage.Dependencies
  • Build Type
  • Kernel
  • SELinux Enforcing
  • Verity
  • Updater
  • FRP
  • SafetyNet
  • Root (su)
  • Non-PIE Blobs
  • Extract Files
  • CVE
  • Firmware Assert
  • exFAT Support
  • Additional Features
  • Software Deviations
• Quality of life
  • Commit Authorship
  • Copyrights
  • Workflow
  • JIRA
  • Licensing
  • Wiki
  • Stability
  • Battery
  • CPU Profiling
• Exceptions

Attaining exceptions

Process

• Device or software deviations from our core product (as described below) MUST be approved by no less than 3 Project Directors.
• Device or software exceptions SHOULD be made via change request to this repository.
• All device or software exceptions that are granted MUST be documented on the wiki for all affected devices.

Hardware Support

Audio

• All devices MUST support audio playback for media content.
• Phones MUST support in-call audio.
• Phones MUST support speaker audio.
• Tablet devices capable of in-call audio/speaker audio MUST support in-call/speaker audio.
• Devices SHOULD support any additional audio configuration inherent to their device (echo cancellation, extra mics, etc).
• All devices MUST support any other audio output supported by their stock OS (ex. Headphone jack, USB-C, BT).
• All devices with FM radio capabilities in their stock OS SHOULD support FM.

RIL

• All devices with RIL supported in their stock OS MUST support RIL for phone calls & data.
• All devices with RIL supported in their stock OS MUST support emergency calling with a SIM inserted (112/911).
• All devices with RIL supported in their stock OS SHOULD support emergency calling without a SIM inserted (112/911).
• Data only devices (defined as devices that have a ril but does not support telephony stack due to hardware/firmware restrictions) are EXEMPTED from phone & emergency dialing requirements.

Encryption

• All devices that supported hardware-backed encryption on their stock OS MUST support hardware-backed encryption.
• All devices that shipped stock as forceencrypt SHOULD default to forceencrypt enabled.
• All devices MUST support software encryption.

Wifi

• All devices with Wi-Fi supported in their stock OS MUST support Wi-Fi.
• All devices with Wi-Fi MUST report same MAC address as on stock OS.
• All devices with Wi-Fi hotspot capabilities MUST support Wi-Fi tethering.

USB

• All devices with a USB port MUST support file access via MTP.
• All devices with USB tethering supported on their stock OS MUST support USB tethering.
• All devices with a USB port & Data SHOULD support USB tethering.

GPS

• All devices with GPS supported in their stock OS MUST support GPS.

Bluetooth

• All devices with Bluetooth supported in their stock OS MUST support Bluetooth.
• All devices with Bluetooth MUST report same MAC address as on stock OS.
• All devices with Bluetooth SHOULD support Bluetooth tethering.
• All devices with support for Qualcomm® aptX™, aptX™ HD, or any future variant of aptX™, in stock (non-beta releases) OS SHOULD support those variant of aptX™.
• All devices without support for Qualcomm® aptX™, aptX™ HD, or any future variant of aptX™ in stock (non-beta releases) OS MUST NOT support those variants of aptX™.

Camera

• All devices with Camera supported in their stock OS MUST support Camera, in both front facing and rear camera configurations.
• All devices with Dual (or more) Rear Cameras SHOULD support all rear cameras.
• All devices with Dual (or more) Front Facing Cameras SHOULD support all front cameras.
• All Camera HAL versions accessible with the device's Camera HAL MUST comply with the Camera and Video Recording requirements.

Video Recording

• All devices with Video Recording supported in their stock OS MUST support Video Recording, in both front facing and rear camera configurations.

Display

• All devices with a built-in Display MUST support the Display at the same resolution and density as the stock OS.
• All devices that do not include a built-in Display MUST support Display output via the hardware’s supported outputs (ex. Android TV - HDMI).
• All devices that support additional non-USB display interfaces SHOULD support those display output methods.
• All devices that support a USB-out display in their stock OS SHOULD support this display output (ex. MHL/Miracast/OTG).
• All devices that support HDR10 playback in their stock OS SHOULD support HDR10 playback.

NFC

- [ ] All devices with NFC supported in their stock OS MUST support NFC

Fingerprint Sensor

- [ ] All devices with a Fingerprint Sensor MUST support the Fingerprint Sensor if the stock OS supports it with Marshmallow or higher Android versions.
- [ ] All devices with a Fingerprint Sensor SHOULD support the Fingerprint Sensor if the stock OS supports it for all other Android versions.

IR

- [ ] All devices with an IR blaster SHOULD support IR blaster.

Accelerometer

• All devices with an accelerometer MUST support the accelerometer.

Gyroscope

• All devices with a gyroscope MUST support the gyroscope.

Proximity

• All devices with a proximity sensor MUST support the proximity sensor.

Light

• All devices with a light sensor MUST support the light sensor.

Other Sensors

• All other sensors supported by a device’s stock OS SHOULD be supported in LineageOS.

Accessories

• All devices with proprietary accessories SHOULD support those accessories in LineageOS (ex. O-Click, Essential 360 Camera).

Hardware Deviations

Hardware deviations are defined as exemptions granted for hardware requirements above that worked in stock, but do not work in LineageOS.

• All hardware deviations from stock MUST be reported on the wiki page for the device, with a user understandable justification.

Software support

Lineage.mk

• Device trees MUST contain a lineage.mk file with device declaration of lineage_[devicename].

Lineage.Dependencies

• Device trees MUST support a lineage.dependencies file for breakfast command & roomservice to be functional.
• This file MUST NOT include any dependencies outside of the "LineageOS" organization.

Build Type

• All devices MUST be configured as userdebug releases.

Kernel

• All devices MUST NOT ship a prebuilt kernel.

SELinux Enforcing

• All devices MUST be configured for SELinux Enforcing.

Verity

• All devices MUST disable verity on the system image for userdebug builds.
• All devices SHOULD support verity on the vendor image.

Updater

• All devices with a shipping build of LineageOS MUST support upgrades via the native LineageOS Updater application & the recovery documented on the Wiki for that device.

FRP

• All devices with stock support of Factory Reset Protection (FRP) SHOULD support FRP when Google Applications are installed by the user.

SafetyNet

• All devices MUST NOT alter SafetyNet validation responses.

Binder

• All devices MUST use the 64-bit Binder API.

Root (su)

• All devices MUST NOT ship with su included.
• All devices MUST support su installation via LineageOS provided ‘Extras’ download.

Non-PIE Blobs

• Devices MUST NOT use non-PIE binaries.

Extract Files

• Devices MUST support a working extract files script in their device tree (or device tree dependencies) that reproduces an exact copy of the binaries required to build LineageOS from an existing LineageOS installation.
• Devices SHOULD use the global extract files script in vendor/lineage.
• If a device maintainer elects to not use the common extract script, the maintainer MUST ensure that the wiki page for their device has valid instructions for operating the custom extract script.

CVE

• Devices MUST support CVE patches for “high profile” exploits and vulnerabilities (if the media is reporting on it, then we must have it patched).
• [NOTE: This will become a MUST once CVE autopatcher is live & automated]
• Devices SHOULD receive regular CVE patches to the device kernel and dependencies.
• [To be in effect once CVE autopatcher is live & automated]
• Device maintainers MUST review and/or accept patches provided by the CVE autopatcher tool.

Firmware Assert

• All devices MUST assert on known to be working firmware versions if some firmware versions are known to be non-working.

exFAT Support

LineageOS operates under the assumption that OEM device licensing for exFAT is attached to the device, not software. LineageOS will comply with all requests for removal of exFAT support from OEMs, Microsoft or their representatives upon contact to [email protected].

• All devices with exFAT support on stock MAY support exFAT with (and only with) a kernel based implementation.
• All devices without exFAT support on stock MUST NOT support exFAT.

Additional Features

• All devices SHOULD support in-kernel (MDSS, MDNIE or similar) LiveDisplay colour adjustment.

Software Deviations

Software deviations are defined as exemptions granted for software requirements above that worked in stock, but do not work in LineageOS.

• All software deviations from other LineageOS devices of the same type MUST be approved by Directors (ex. if you want to remove Music app, get approval).
• All software deviations from other LineageOS devices of the same type MUST be reported on the wiki page for the device, with a user understandable justification.
• Device maintainers MUST ship Jelly or another LineageOS sourced web browser.

Quality of life

Commit Authorship

• All non-original commits MUST have proper authorship attribution from the source it was taken from or adapted from.

Copyrights

• All original contributions MUST be copyrighted as “(C) [YEAR] The LineageOS Project”.
• All LineageOS copyrights MUST only be additive to the copyright header.
• Do not remove copyrights from CyanogenMod, Cyanogen Inc or any other upstream.

Workflow

• Force pushing branches SHOULD be avoided.
• In the event of a force pushed branch, backup branches of the pre-forced HEAD MUST be made.

JIRA

• Device maintainer(s) MUST have a JIRA account for bug tracking and cross-team collaboration.
• Device maintainer(s) MUST routinely triage, answer and close JIRA reports.
• Device maintainer(s) SHOULD make their JIRA name match their maintainer name as displayed on the Wiki.

Licensing

• All Kernel contributions MUST be GPLv2.
• All Android contributions SHOULD be Apache 2.0 licensed.
• Any contribution to an existing Apache 2.0 project MUST fall under Apache Compliance Category A.
• Any contribution to an existing Apache 2.0 project MUST NOT be in Apache Compliance Category X.

Wiki

• All devices with a shipping build of LineageOS MUST have a wiki page with valid installation instructions.
• All devices with a shipping build of LineageOS MUST document Hardware Deviations from stock capabilities.
• All devices with a shipping build of LineageOS MUST document Software Deviations from other LineageOS releases of the same device type.

Stability

• Issues like the "screen of death" MUST NOT affect the device.
• The device MUST NOT have abnormal battery drain.
• Overclocked CPU Profiles MUST NOT be applied by default.

Recovery

• Maintainers MUST document for users on the Wiki a valid Recovery image by which to install LineageOS zip files.
• Devices that do not have traditional Recovery images MUST support & document another means of installation for LineageOS zip files.
• Maintainers SHOULD verify that Teamwin Recovery Project (TWRP) official distributions work for LineageOS installation.
• Failures in official TWRP recoveries should be raised with the TWRP team or remedied by the maintainer.
• Maintainers SHOULD provide a custom recovery link in Wiki documentation if TWRP does not officially support their device.

Exceptions

All currently granted exceptions should be listed in the following table. To request an exception, please submit a change to this repository.

This document is licensed CC-BY-3.0, with portions adapted from Google’s CDD requirements.

From @vladimiroltean on February 17, 2018 0:16

Dmesg is full of messages such as this one:

[ 3482.569025] ChromiumNet[5641]: syscall 384
[ 3482.569037] Code: e1a01002 e1a02003 e89c0078 ef000000 (e8bd00f0) 
[ 3482.569045] CPU: 1 PID: 5641 Comm: ChromiumNet Tainted: G        W    3.10.84-perf-g963993a-00043-g4fe9981-dirty #1
[ 3482.569052] task: ffffffc04aa369c0 ti: ffffffc087870000 task.ti: ffffffc087870000
[ 3482.569058] PC is at 0xe774f4ec
[ 3482.569062] LR is at 0xc944f643
[ 3482.569066] pc : [<00000000e774f4ec>] lr : [<00000000c944f643>] pstate: 20070010
[ 3482.569070] sp : 00000000c8fc0f08
[ 3482.569073] x12: 00000000c8fc0f18 
[ 3482.569077] x11: 00000000c950b5e4 x10: 0000000000000000 
[ 3482.569082] x9 : 00000000ffffffff x8 : 0000000000000001 
[ 3482.569087] x7 : 0000000000000180 x6 : 00000000c95cfb88 
[ 3482.569092] x5 : 0000000000000010 x4 : 0000000000000001 
[ 3482.569096] x3 : 0000000000000000 x2 : 0000000000000001 
[ 3482.569101] x1 : 0000000000000001 x0 : 00000000c8fc0f1f

What do they mean? Is there any performance/functionality impact?

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#10

init: /vendor/etc/init/[email protected]: 1: ignored duplicate definition of service 'gnss_service'
init: /vendor/etc/init/[email protected]: 1: ignored duplicate definition of service 'power-hal-1-0'
init: /vendor/etc/init/hostapd.rc: 3: ignored duplicate definition of service 'hostapd'

Also:

init: cannot find '/system/bin/hvdcp_opti', disabling 'hvdcp_opti': No such file or directory
init: cannot find '/vendor/bin/audiod', disabling 'audiod': No such file or directory

The firmware folder moved in Oreo from /system/etc/firmware to /vendor/firmware.
We didn't update the ramdisk symlink, that was originally observed in stock.
I don't know whether there is any side effect to this symlink being broken.

From @vladimiroltean on February 18, 2018 16:28

Proposed solution: search the iio subsystem (accelerometer sensor) for a device with wakeup irq to hook into. Disable the dt2w driver after a period of idle time, and then use the accelerometer's irq to re-enable dt2w.

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#16

From @Quallenauge on February 2, 2018 12:9

It seems the sony developers does a good job at handling their devices.
Take these trees (device/vendor) as template for the lenovo devices.
The device, which is closest to our device, seems the device-sony-tone.

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#4

From @vladimiroltean on February 17, 2018 0:6

That is to say, somebody must understand the following commits:

• lenovo: power: changes over CAF tag LA.BR.1.3.4-06610-8976.0
• lenovo: drivers/misc: changes over CAF tag LA.BR.1.3.4-06610-8976.0
• lenovo: drivers/usb: changes over CAF tag LA.BR.1.3.4-06610-8976.0

How much of the above commits is really needed? How much can be reverted? How does QC work? Are we missing any userspace components?

Also, I get some interesting messages at boot, that I'd like to be able to decipher:

[    8.338511] fusb301 8-0021: fusb301 not support
[    8.343016] fusb301: probe of 8-0021 failed with error -107
[    8.348632] fusb30x_probe start
[    8.351620] fusb302 2-0022: fusb30x_probe
[    8.355716] i2c-msm-v2 78b6000.i2c: NACK: slave not responding, ensure its powered: msgs(n:2 cur:0 tx) bc(rx:1 tx:1) mode:FIFO slv_addr:0x22 MSTR_STS:0x091343c8 OPER:0x00000010
[    8.371417] fusb302 2-0022: fusb_I2C_ReadData - Unexpected I2C error reading byte data. Address: '0x01', Return: '-107'.  Attempt #0 / 3...
[    8.383966] i2c-msm-v2 78b6000.i2c: NACK: slave not responding, ensure its powered: msgs(n:2 cur:0 tx) bc(rx:1 tx:1) mode:FIFO slv_addr:0x22 MSTR_STS:0x091343c8 OPER:0x00000010
[    8.399614] fusb302 2-0022: fusb_I2C_ReadData - Unexpected I2C error reading byte data. Address: '0x01', Return: '-107'.  Attempt #1 / 3...
[    8.412211] i2c-msm-v2 78b6000.i2c: NACK: slave not responding, ensure its powered: msgs(n:2 cur:0 tx) bc(rx:1 tx:1) mode:FIFO slv_addr:0x22 MSTR_STS:0x011383c8 OPER:0x00000010
[    8.427821] fusb302 2-0022: fusb_I2C_ReadData - Unexpected I2C error reading byte data. Address: '0x01', Return: '-107'.  Attempt #2 / 3...
[    8.440343] i2c-msm-v2 78b6000.i2c: NACK: slave not responding, ensure its powered: msgs(n:2 cur:0 tx) bc(rx:1 tx:1) mode:FIFO slv_addr:0x22 MSTR_STS:0x091343c8 OPER:0x00000010
[    8.456031] fusb302 2-0022: fusb_I2C_ReadData - Unexpected I2C error reading byte data. Address: '0x01', Return: '-107'.  Attempt #3 / 3...
[    8.468538] FUSB  fusb_IsDeviceValid - Error: Could not communicate with device over I2C!
[    8.476613] fusb302 2-0022: FUSB  fusb30x_probe - Error: Unable to communicate with device!
[    8.484997] fusb302: probe of 2-0022 failed with error -5
[    8.490460] fusb30x_probe start
[    8.493455] fusb302 8-0022: fusb30x_probe
[    8.502545] fusb302 8-0022: FUSB  fusb30x_probe - FUSB30X Driver loaded successfully!
[    8.506268] zou_hao: 4,28,40, 0,81,28,81*******
[    8.506270] ****

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#8

From @Quallenauge on February 12, 2018 22:0

The dolby atmos isn't working.

02-12 22:54:40.694  7024  7055 E ACDB-LOADER: ACDB -> Not correctly initialized!
02-12 22:54:40.694  7024  7055 W audio_hw_utils: audio_extn_utils_send_audio_calibration: No audio calibration for usecase type = 0
02-12 22:54:40.695  7024  7055 D audio_hw_primary: enable_audio_route: apply mixer and update path: low-latency-playback
02-12 22:54:40.695  7024  7055 D audio_route: Apply path: low-latency-playback
02-12 22:54:40.696  7024  7055 D audio_hw_primary: select_devices: done
02-12 22:54:40.698  7024  7055 D msm8916_platform: platform_set_channel_map mixer_ctl_name:Playback Channel Map12
02-12 22:54:40.698  7024  7055 D msm8916_platform: platform_set_channel_map: set mapping(1 2 0 0 0 0 0 0) for channel:2
02-12 22:54:40.741  7024  7056 D DlbCrossfadeProcess: process transitioning from PREROLL_ACTIVE state to FADE_TO_ACTIVE
02-12 22:54:40.765  7024  7055 D audio_hw_primary: start_output_stream: exit

....
02-12 22:54:40.819  7060  7060 F DEBUG   : backtrace:
02-12 22:54:40.819  7060  7060 F DEBUG   :     #00 pc 00017f4c  /system/lib/soundfx/libswdax.so (dolby::CrossfadeProcess::accumulate(short*, short*, short*, int, float, float)+27)
02-12 22:54:40.819  7060  7060 F DEBUG   :     #01 pc 000181ab  /system/lib/soundfx/libswdax.so (dolby::CrossfadeProcess::crossfade(dolby::BufferProvider*, dolby::BufferProvider*, bool)+418)
02-12 22:54:40.819  7060  7060 F DEBUG   :     #02 pc 000182a3  /system/lib/soundfx/libswdax.so (dolby::CrossfadeProcess::process(dolby::BufferProvider*, dolby::BufferProvider*)+210)
02-12 22:54:40.820  7060  7060 F DEBUG   :     #03 pc 00019073  /system/lib/soundfx/libswdax.so (dolby::EffectDap::process(audio_buffer_s*, audio_buffer_s*)+50)
02-12 22:54:40.820  7060  7060 F DEBUG   :     #04 pc 00001099  /system/vendor/lib/libeffects.so (Effect_Process+52)
02-12 22:54:40.820  7060  7060 F DEBUG   :     #05 pc 0002aa73  /system/vendor/lib/hw/[email protected] (android::hardware::audio::effect::V2_0::implementation::(anonymous namespace)::ProcessThread::threadLoop()+130)
02-12 22:54:40.821  7060  7060 F DEBUG   :     #06 pc 0000d121  /system/lib/libutils.so (android::Thread::_threadLoop(void*)+144)
02-12 22:54:40.821  7060  7060 F DEBUG   :     #07 pc 000474bf  /system/lib/libc.so (__pthread_start(void*)+22)
02-12 22:54:40.821  7060  7060 F DEBUG   :     #08 pc 0001af29  /system/lib/libc.so (__start_thread+32)

Copied from original issue: Quallenauge/Yoga-Tab-3-Plus-Issue-Tracker#6

Could we add adb and fastboot binaries, like it used to be in the good old days? So people could use it for there phones without a PC (e.g. ADB over LAN to remote control the terminal).
https://github.com/LineageOS/android_system_core/tree/lineage-15.1/adb
https://github.com/LineageOS/android_system_core/tree/lineage-15.1/fastboot

Would it be possible somehow to build them automatically with the ROM? Alternatively we could just include the prebuild binaries..