Finally discovered reason for Google Account Backup failing - Huawei Mate 20 X Questions & Answers
Google account backup to drive is failing on the Chinese variant AL00 (mine):
Code:
02-05 20:05:53.385 3111 3125 I Backup : [BackupHttpRequestUtil] Http Response Code: 200
02-05 20:05:53.390 3111 3125 W Backup : [BackupTransportCS] Server returned error, invalidating auth token. This is retried once.
02-05 20:05:53.391 3111 3125 W Backup : [BackupTransportCS] Network error: proposed backoff of 42742233ms considered too large, not retrying. Exception that caused this: ljx: Server failed authorization.
02-05 20:05:53.391 3111 3125 W Backup : error auth code : AUTH_TOKEN_INVALID
02-05 20:05:53.392 3111 3125 W Backup : [BackupTransportCS] Setting moratorium: 1549440353392
02-05 20:05:53.393 3111 3125 E Backup : [GmsBackupTransport] Error sending final backup to server:
02-05 20:05:53.393 3111 3125 E Backup : ljx: Server failed authorization.
02-05 20:05:53.393 3111 3125 E Backup : error auth code : AUTH_TOKEN_INVALID
02-05 20:05:53.393 3111 3125 E Backup : at com.google.android.gms.backup.transport.BackupTransportChimeraService.a(:[email protected]@15.0.90 (100408-231259764):98)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.k(:[email protected]@15.0.90 (100408-231259764):64)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.a(:[email protected]@15.0.90 (100408-231259764):192)
02-05 20:05:53.393 3111 3125 E Backup : at mks.call(Unknown Source:2)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.a(:[email protected]@15.0.90 (100408-231259764):124)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.performBackup(:[email protected]@15.0.90 (100408-231259764):3)
02-05 20:05:53.393 3111 3125 E Backup : at android.app.backup.BackupTransport$TransportImpl.performBackup(BackupTransport.java:676)
02-05 20:05:53.393 3111 3125 E Backup : at com.android.internal.backup.IBackupTransport$Stub.onTransact(IBackupTransport.java:142)
02-05 20:05:53.393 3111 3125 E Backup : at android.os.Binder.transact(Binder.java:675)
02-05 20:05:53.393 3111 3125 E Backup : at duo.onTransact(:[email protected]@15.0.90 (100408-231259764):3)
02-05 20:05:53.393 3111 3125 E Backup : at android.os.Binder.execTransact(Binder.java:739)
02-05 20:05:53.393 3111 3125 E Backup : [GmsBackupTransport] Encrypted init failed, -1000
02-05 20:05:53.397 3111 3125 I Backup : [GmsBackupTransport] Next backup will happen in 43199995 millis.
02-05 20:05:53.404 1206 3469 I PerformBackupTask: K/V backup pass finished.
So the server is rejecting authentication. I hear this is a common problem and Google are rolling out fixes for client devices. my concern though, is given Google is banned in China (or certainly restricted), I doubt AL00 devices will ever get this fix.
Has any of the AL29 (Global ROM) users managed to get account backup working.
NOTE: This is NOT the Google Sync - this is a DEVICE level backup not to be confused with the sync app on the phone that displays sync of contacts, apps, games, calendar and so on.
Tweetytek said:
Google account backup to drive is failing on the Chinese variant AL00 (mine):
Code:
02-05 20:05:53.385 3111 3125 I Backup : [BackupHttpRequestUtil] Http Response Code: 200
02-05 20:05:53.390 3111 3125 W Backup : [BackupTransportCS] Server returned error, invalidating auth token. This is retried once.
02-05 20:05:53.391 3111 3125 W Backup : [BackupTransportCS] Network error: proposed backoff of 42742233ms considered too large, not retrying. Exception that caused this: ljx: Server failed authorization.
02-05 20:05:53.391 3111 3125 W Backup : error auth code : AUTH_TOKEN_INVALID
02-05 20:05:53.392 3111 3125 W Backup : [BackupTransportCS] Setting moratorium: 1549440353392
02-05 20:05:53.393 3111 3125 E Backup : [GmsBackupTransport] Error sending final backup to server:
02-05 20:05:53.393 3111 3125 E Backup : ljx: Server failed authorization.
02-05 20:05:53.393 3111 3125 E Backup : error auth code : AUTH_TOKEN_INVALID
02-05 20:05:53.393 3111 3125 E Backup : at com.google.android.gms.backup.transport.BackupTransportChimeraService.a(:[email protected]@15.0.90 (100408-231259764):98)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.k(:[email protected]@15.0.90 (100408-231259764):64)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.a(:[email protected]@15.0.90 (100408-231259764):192)
02-05 20:05:53.393 3111 3125 E Backup : at mks.call(Unknown Source:2)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.a(:[email protected]@15.0.90 (100408-231259764):124)
02-05 20:05:53.393 3111 3125 E Backup : at mkh.performBackup(:[email protected]@15.0.90 (100408-231259764):3)
02-05 20:05:53.393 3111 3125 E Backup : at android.app.backup.BackupTransport$TransportImpl.performBackup(BackupTransport.java:676)
02-05 20:05:53.393 3111 3125 E Backup : at com.android.internal.backup.IBackupTransport$Stub.onTransact(IBackupTransport.java:142)
02-05 20:05:53.393 3111 3125 E Backup : at android.os.Binder.transact(Binder.java:675)
02-05 20:05:53.393 3111 3125 E Backup : at duo.onTransact(:[email protected]@15.0.90 (100408-231259764):3)
02-05 20:05:53.393 3111 3125 E Backup : at android.os.Binder.execTransact(Binder.java:739)
02-05 20:05:53.393 3111 3125 E Backup : [GmsBackupTransport] Encrypted init failed, -1000
02-05 20:05:53.397 3111 3125 I Backup : [GmsBackupTransport] Next backup will happen in 43199995 millis.
02-05 20:05:53.404 1206 3469 I PerformBackupTask: K/V backup pass finished.
So the server is rejecting authentication. I hear this is a common problem and Google are rolling out fixes for client devices. my concern though, is given Google is banned in China (or certainly restricted), I doubt AL00 devices will ever get this fix.
Has any of the AL29 (Global ROM) users managed to get account backup working.
NOTE: This is NOT the Google Sync - this is a DEVICE level backup not to be confused with the sync app on the phone that displays sync of contacts, apps, games, calendar and so on.
Click to expand...
Click to collapse
Basically Ppl outside of china never should buy chinese versions if they expecting google 100% support .. that's all
Works fine on my ROM
freeza said:
Works fine on my ROM
Click to expand...
Click to collapse
Yeah dat deodexed? But u have to do it over n over when new ota releases pain in ass..
PhoneTechShop said:
Yeah dat deodexed? But u have to do it over n over when new ota releases pain in ass..
Click to expand...
Click to collapse
What do you mean do it over?
Sent from my EVR-AL00 using Tapatalk
freeza said:
What do you mean do it over?
Sent from my EVR-AL00 using Tapatalk
Click to expand...
Click to collapse
debloating and deodexing .. or u have your own update support ?
PhoneTechShop said:
debloating and deodexing .. or u have your own update support ?
Click to expand...
Click to collapse
We have our own update strategy that's been working fine
freeza said:
We have our own update strategy that's been working fine
Click to expand...
Click to collapse
Can you tell us ?
Related
please help in call audio
Is anyone having this problem whilst building and testing roms , Can someone review this cat log and suggest a fix its for in call volume this is the problem: Code: 02-05 18:10:40.748 8670 8670 W System : ClassLoader referenced unknown path: /system/priv-app/Dialer/lib/arm 02-05 18:10:40.759 7021 7021 I InCall : CallList - onUpdate - [Call_2, ACTIVE, [Capabilities: CAPABILITY_HOLD CAPABILITY_SUPPORT_HOLD CAPABILITY_MUTE CAPABILITY_CANNOT_DOWNGRADE_VIDEO_TO_AUDIO], [Properties:], children:[], parent:null, conferenceable:[], videoState:Audio Only, mSessionModificationState:0, VideoSettingsCameraDir:-1), mIsActivSub:false] 02-05 18:10:40.759 7021 7021 I InCall : InCallPresenter - Phone switching state: INCALL -> INCALL 02-05 18:10:40.761 7021 7021 E QtiImsExtUtils: getImsPhoneId failed. Exception = org.codeaurora.ims.QtiImsException: ImsService is not running 02-05 18:10:40.761 7021 7021 E QtiImsExtUtils: getConfigForPhoneId phoneId is invalid 02-05 18:10:40.761 7021 7021 E QtiImsExtUtils: isCarrierConfigEnabled bundle is null 02-05 18:10:40.761 7021 7021 E QtiImsExtUtils: getImsPhoneId failed. Exception = org.codeaurora.ims.QtiImsException: ImsService is not running 02-05 18:10:40.761 7021 7021 E QtiImsExtUtils: getConfigForPhoneId phoneId is invalid 02-05 18:10:40.761 7021 7021 E QtiImsExtUtils: isCarrierConfigEnabled bundle is null 02-05 18:10:40.789 531 531 I hash_map_utils: key: 'volume_boost' value: '' 02-05 18:10:40.789 531 3072 I hash_map_utils: key: 'volume_boost' value: '' 02-05 18:10:40.792 7021 7021 E QtiImsExtUtils: getImsPhoneId failed. Exception = org.codeaurora.ims.QtiImsException: ImsService is not running 02-05 18:10:40.792 7021 7021 E QtiImsExtUtils: getConfigForPhoneId phoneId is invalid 02-05 18:10:40.792 7021 7021 E QtiImsExtUtils: isCarrierConfigEnabled bundle is null 02-05 18:10:40.792 7021 7021 E QtiImsExtUtils: getImsPhoneId failed. Exception = org.codeaurora.ims.QtiImsException: ImsService is not running 02-05 18:10:40.792 7021 7021 E QtiImsExtUtils: getConfigForPhoneId phoneId is invalid 02-05 18:10:40.792 7021 7021 E QtiImsExtUtils: isCarrierConfigEnabled bundle is null
Crash Debug on LineageOS 14.1
I just flashed my mobile with LineageOS 14.1 To my surprise I see the crashes that they dont show full stack trace. Only this: 01-03 22:44:01.189 12773 12807 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x42424242 in tid 12807 (hci_thread) Do I have to enable it somehow? I would expect to see something like this (this I remember from Cyanogenmod and Stock Android) 02-05 16:45:13.279 307 1231 F libc : Fatal signal 11 (SIGSEGV), code 1, fault addr 0x1 in tid 1231 (netmgrd) 02-05 16:45:13.351 6570 6570 F DEBUG : *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** 02-05 16:45:13.352 6570 6570 F DEBUG : CM Version: '14.1-20170131-NIGHTLY-osprey' 02-05 16:45:13.352 6570 6570 F DEBUG : Build fingerprint: 'motorola/osprey_retus_2gb/osprey_u2:6.0.1/MPI24.107-55/33:user/release-keys' 02-05 16:45:13.352 6570 6570 F DEBUG : Revision: '0' 02-05 16:45:13.352 6570 6570 F DEBUG : ABI: 'arm' 02-05 16:45:13.352 6570 6570 F DEBUG : pid: 307, tid: 1231, name: netmgrd >>> /system/bin/netmgrd <<< 02-05 16:45:13.352 6570 6570 F DEBUG : signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x1 02-05 16:45:13.352 6570 6570 F DEBUG : r0 b6b01f10 r1 00000001 r2 b6b06560 r3 00000040 02-05 16:45:13.352 6570 6570 F DEBUG : r4 b647f3fc r5 b6b06eac r6 b6b01f10 r7 b6b02d07 02-05 16:45:13.352 6570 6570 F DEBUG : r8 b5f07520 r9 b5f07500 sl 00000001 fp b6f7ea49 02-05 16:45:13.352 6570 6570 F DEBUG : ip 00000000 sp b647f000 lr b6af9ba5 pc b6af9bce cpsr 20070030 02-05 16:45:13.363 6570 6570 F DEBUG : 02-05 16:45:13.363 6570 6570 F DEBUG : backtrace: 02-05 16:45:13.363 6570 6570 F DEBUG : #00 pc 00007bce /system/vendor/lib/libnetmgr.so (netmgr_nl_decode_nlmsg+269) 02-05 16:45:13.363 6570 6570 F DEBUG : #01 pc 00020f7d /system/bin/netmgrd 02-05 16:45:13.363 6570 6570 F DEBUG : #02 pc 00033893 /system/bin/netmgrd 02-05 16:45:13.364 6570 6570 F DEBUG : #03 pc 00041b09 /system/bin/netmgrd 02-05 16:45:13.364 6570 6570 F DEBUG : #04 pc 0000bef9 /system/vendor/lib/libdsutils.so (stm2_process_input+632) 02-05 16:45:13.364 6570 6570 F DEBUG : #05 pc 0000c7dd /system/vendor/lib/libdsutils.so (stm2_instance_process_input+204) 02-05 16:45:13.364 6570 6570 F DEBUG : #06 pc 0001213d /system/bin/netmgrd 02-05 16:45:13.364 6570 6570 F DEBUG : #07 pc 00003f9f /system/vendor/lib/libdsutils.so 02-05 16:45:13.364 6570 6570 F DEBUG : #08 pc 000477d3 /system/lib/libc.so (_ZL15__pthread_startPv+22) 02-05 16:45:13.364 6570 6570 F DEBUG : #09 pc 00019b7d /system/lib/libc.so (__start_thread+6) Thanks,
marcinguy said: I just flashed my mobile with LineageOS 14.1... Click to expand... Click to collapse I don't have this device but, your best bet is to post this question within the following Official LineageOS thread for your device. https://forum.xda-developers.com/showthread.php?t=3466246 Good Luck! ~~~~~~~~~~~~~~~ I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
Thanks! Actually it is a general Question in regards to LineageOS 14.1. The device I use is S3 Neo+ GT-9301I I pasted sample output as I it remember from Motorola device. So on my device, as stated I just get: Code: 12-31 13:11:00.180 8059 8096 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 8096 (bt_workqueue) 12-31 13:11:00.181 209 209 W : debuggerd: handling request: pid=8059 uid=1002 gid=1002 tid=8096 12-31 13:11:00.220 8059 8096 F libc : failed to resend signal during crash: Operation not permitted 12-31 13:11:00.229 8335 8335 E DEBUG : unexpected waitpid response: n=8096, status=00000000 12-31 13:11:00.229 8335 8335 E : debuggerd: timed out waiting for signal 12-31 13:11:00.231 8335 8335 E : debuggerd: ptrace detach from 8096 failed: No such process 12-31 13:11:00.233 8335 8335 E : debuggerd: failed to kill process 8059: No such process 12-31 13:11:00.236 778 810 I BootReceiver: Copying /data/tombstones/tombstone_09 to DropBox (SYSTEM_TOMBSTONE) Any ideas? Where there is "Operation not permitted"? Ibuprophen said: I don't have this device but, your best bet is to post this question within the following Official LineageOS thread for your device. https://forum.xda-developers.com/showthread.php?t=3466246 Good Luck! ~~~~~~~~~~~~~~~ I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share. Click to expand... Click to collapse
Narrowed it down to this:
int rc = syscall(SYS_rt_tgsigqueueinfo, getpid(), gettid(), signal_number, info);
if (rc != 0) {
__libc_format_log(ANDROID_LOG_FATAL, "libc", "failed to resend signal during crash: %s",
strerror(errno));
_exit(0);
}
12-31 14:35:20.070 14851 14881 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 14881 (bt_workqueue)
12-31 14:35:20.070 16288 16288 W : debuggerd: handling request: pid=14851 uid=1002 gid=1002 tid=14881
12-31 14:35:20.100 14851 14881 F libc : failed to resend signal during crash: Operation not permitted
Wondering why it gets Operation not permitted?
marcinguy said:
Thanks!
Actually it is a general Question in regards to LineageOS 14.1.
The device I use is S3 Neo+ GT-9301I
I pasted sample output as I it remember from Motorola device.
So on my device, as stated I just get:
Code:
12-31 13:11:00.180 8059 8096 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 8096 (bt_workqueue)
12-31 13:11:00.181 209 209 W : debuggerd: handling request: pid=8059 uid=1002 gid=1002 tid=8096
12-31 13:11:00.220 8059 8096 F libc : failed to resend signal during crash: Operation not permitted
12-31 13:11:00.229 8335 8335 E DEBUG : unexpected waitpid response: n=8096, status=00000000
12-31 13:11:00.229 8335 8335 E : debuggerd: timed out waiting for signal
12-31 13:11:00.231 8335 8335 E : debuggerd: ptrace detach from 8096 failed: No such process
12-31 13:11:00.233 8335 8335 E : debuggerd: failed to kill process 8059: No such process
12-31 13:11:00.236 778 810 I BootReceiver: Copying /data/tombstones/tombstone_09 to DropBox (SYSTEM_TOMBSTONE)
Any ideas?
Where there is "Operation not permitted"?
Click to expand...
Click to collapse
Figured it out.
Had to modify debbugerd (bionic) and adjust selinux.
Now debuggerd can attach to the process and show the debug info and backtrace.
marcinguy said:
Narrowed it down to this:
int rc = syscall(SYS_rt_tgsigqueueinfo, getpid(), gettid(), signal_number, info);
if (rc != 0) {
__libc_format_log(ANDROID_LOG_FATAL, "libc", "failed to resend signal during crash: %s",
strerror(errno));
_exit(0);
}
12-31 14:35:20.070 14851 14881 F libc : Fatal signal 6 (SIGABRT), code -6 in tid 14881 (bt_workqueue)
12-31 14:35:20.070 16288 16288 W : debuggerd: handling request: pid=14851 uid=1002 gid=1002 tid=14881
12-31 14:35:20.100 14851 14881 F libc : failed to resend signal during crash: Operation not permitted
Wondering why it gets Operation not permitted?
Click to expand...
Click to collapse
Fairphone 2, Lineageos 14.1, Error VPN connection since latest LineageOS-Version
Hello, I'm using the Capsule app to establish a VPN connection into my employers's network, the authentication is done via certificates. My environment: Device: Fairphone 2 Recovery: TWRP OS: LineageOS 14.1 (Android 7.1.2) LineageOS-Version: 14.1-20180213-NIGHTLY-FP2 --> last version VPN connection works14.1-20180220-NIGHTLY-FP2 --> first version VPN connection does not works anymore Since 14.1-20180220-NIGHTLY-FP2, the VPN client throws this error message: 'failed to retrieve certificate from device store' below you can find more details copied out of the app's logfile. The error is reproducable: I always did TWRP backups before installing a newer lineage version. When restoring a version older than 20.02.2018, then VPN connection works. I can install update after update, till 14.1-20180220-NIGHTLY-FP2 all works fine. Could someone give some advice how this can be solved? Thanks in advance. App's log file: 03-03 23:04:38.132 11264 259 E NEMO.In Service Main: android.security.KeyChainException: java.security.UnrecoverableKeyException: Failed to obtain information about private key at android.security.KeyChain.getPrivateKey(KeyChain.java:390) at com.checkpoint.VPN.Service.b(SourceFile:1156) at com.checkpoint.VPN.Service.b(SourceFile:67) at com.checkpoint.VPN.Service$CCCDoer.handleMessage(SourceFile:706) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:154) at android.os.HandlerThread.run(HandlerThread.java:61) Caused by: java.security.UnrecoverableKeyException: Failed to obtain information about private key at android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStorePublicKeyFromKeystore(AndroidKeyStoreProvider.java:223) at android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStoreKeyPairFromKeystore(AndroidKeyStoreProvider.java:259) at android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStorePrivateKeyFromKeystore(AndroidKeyStoreProvider.java:269) at android.security.KeyChain.getPrivateKey(KeyChain.java:382) ... 6 more Caused by: android.security.KeyStoreException: Key not found at android.security.KeyStore.getKeyStoreException(KeyStore.java:659) at android.security.keystore.AndroidKeyStoreProvider.loadAndroidKeyStorePublicKeyFromKeystore(AndroidKeyStoreProvider.java:224) ... 9 more 03-03 23:04:38.137 11264 1 D NEMO.SyncController::handleMessage: got msg from service: type = CONNECT 03-03 23:04:38.138 11264 1 D NEMO.service says: CONNECT Failure: error_msg: 'failed to retrieve certificate from device store', error_code: '-1' 03-03 23:04:38.138 11264 1 D NEMO.In Connecting task activity:nCCCError(): failed to retrieve certificate from device store
Wifi P2P ("WiFi Direct") support - does anyone know of patches for this on Pie?
Wifi P2P ("WiFi Direct") support - does anyone know of patches for this on Pie?
Pretty much exactly as the subject line states.
When doing anything which brings up a P2P interface (right now, that's "cast" or "wifi direct" under settings / wifi / advanced):
Code:
02-05 22:44:33.565 10656 10744 I WifiP2pNative: P2P interface teardown completed
02-05 22:44:33.565 10656 10744 E WifiP2pService: Failed to setup interface for P2P
02-05 22:44:33.565 10656 10744 D WifiP2pNative: P2P InterfaceAvailableListener false
02-05 22:44:33.565 10656 10744 D WifiP2pService: Wifi enabled=true, P2P Interface availability=false
02-05 22:44:33.565 10656 10744 D WifiP2pNative: P2P InterfaceDestroyedListener p2p0
02-05 22:44:33.565 10656 10744 D WifiP2pNative: Ignoring stale interface destroyed listener
02-05 22:44:33.565 10656 10744 D WifiP2pNative: P2P InterfaceAvailableListener true
02-05 22:44:33.565 10656 10744 D WifiP2pService: Wifi enabled=true, P2P Interface availability=true, Number of clients=1
02-05 22:44:33.565 10656 10744 D WifiP2pService: Wifi enabled=true, P2P Interface availability=true
02-05 22:44:33.566 10656 10744 D WifiP2pNative: Setup P2P interface
02-05 22:44:33.566 10656 10744 D HalDevMgr: createIface: ifaceType=2, lowPriority=false
02-05 22:44:33.566 10656 10744 D HalDevMgr: getAllChipInfo
02-05 22:44:33.566 10656 10744 D HalDevMgr: getChipIds=[0]
02-05 22:44:33.567 23753 23753 D WifiSettings: onAccessPointsChanged (WifiTracker) callback initiated
02-05 22:44:33.567 10656 10744 D HalDevMgr: validateInterfaceCache
02-05 22:44:33.567 10656 10744 D HalDevMgr: createIfaceIfPossible: chipInfos=[{chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=0, ifaces[3].length=0)], ifaceType=2, lowPriority=false
02-05 22:44:33.567 10656 10744 D HalDevMgr: {.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]} expands to [[1, 0, 1, 0]]
02-05 22:44:33.568 10656 10744 D HalDevMgr: canIfaceComboSupportRequest: chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=0, ifaces[3].length=0), chipMode={.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, chipIfaceCombo=[[email protected], ifaceType=2, lowPriority=false
02-05 22:44:33.568 10656 10744 D HalDevMgr: compareIfaceCreationData: val1={chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=0, ifaces[3].length=0), chipModeId=0, interfacesToBeRemovedFirst=[]), val2=null
02-05 22:44:33.568 10656 10744 D HalDevMgr: new proposal accepted
02-05 22:44:33.568 10656 10744 D HalDevMgr: {.limits = [{.types = [1], .maxIfaces = 1}]} expands to [[0, 1, 0, 0]]
02-05 22:44:33.568 10656 10744 D HalDevMgr: canIfaceComboSupportRequest: chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=0, ifaces[3].length=0), chipMode={.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}, chipIfaceCombo=[[email protected], ifaceType=2, lowPriority=false
02-05 22:44:33.568 10656 10744 D HalDevMgr: Requested type not supported by combo
02-05 22:44:33.568 10656 10744 D HalDevMgr: compareIfaceCreationData: val1=null, val2={chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=0, ifaces[3].length=0), chipModeId=0, interfacesToBeRemovedFirst=[])
02-05 22:44:33.568 10656 10744 D HalDevMgr: executeChipReconfiguration: ifaceCreationData={chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=0, ifaces[3].length=0), chipModeId=0, interfacesToBeRemovedFirst=[]), ifaceType=2
02-05 22:44:33.568 10656 10744 D HalDevMgr: isModeConfigNeeded=false
02-05 22:44:33.568 10656 10793 D HalDevMgr: onIfaceAdded: type=2, name=p2p0
02-05 22:44:33.568 10656 10744 D HalDevMgr: createIfaceIfPossible: added cacheEntry={name=p2p0, type=2, destroyedListeners.size()=1, creationTime=89382364, isLowPriority=false}
02-05 22:44:33.569 10656 10744 D HalDevMgr: dispatchAvailableForRequestListeners
02-05 22:44:33.569 10656 10744 D HalDevMgr: getAllChipInfo
02-05 22:44:33.569 10656 10744 D HalDevMgr: getChipIds=[0]
02-05 22:44:33.569 23753 23761 W System : A resource failed to call close.
02-05 22:44:33.571 10656 10744 D HalDevMgr: dispatchAvailableForRequestListeners: chipInfos=[{chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=1, ifaces[3].length=0)]
02-05 22:44:33.571 10656 10744 D HalDevMgr: dispatchAvailableForRequestListenersForType: ifaceType=1
02-05 22:44:33.571 10656 10744 D HalDevMgr: dispatchAvailableForRequestListenersForType: ifaceType=0
02-05 22:44:33.571 10656 10744 D HalDevMgr: dispatchAvailableForRequestListenersForType: ifaceType=2
02-05 22:44:33.571 23753 23753 D WifiSettings: onAccessPointsChanged (WifiTracker) callback initiated
02-05 22:44:33.571 10656 10744 D HalDevMgr: isItPossibleToCreateIface: chipInfos=[{chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=1, ifaces[3].length=0)], ifaceType=2
02-05 22:44:33.571 10656 10744 D HalDevMgr: {.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]} expands to [[1, 0, 1, 0]]
02-05 22:44:33.571 10656 10744 D HalDevMgr: canIfaceComboSupportRequest: chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=1, ifaces[3].length=0), chipMode={.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, chipIfaceCombo=[[email protected], ifaceType=2, lowPriority=false
02-05 22:44:33.571 10656 10744 D HalDevMgr: Would need to delete some higher priority interfaces
02-05 22:44:33.571 10656 10744 D HalDevMgr: {.limits = [{.types = [1], .maxIfaces = 1}]} expands to [[0, 1, 0, 0]]
02-05 22:44:33.571 10656 10744 D HalDevMgr: canIfaceComboSupportRequest: chipInfo={chipId=0, availableModes=[{.id = 0, .availableCombinations = [{.limits = [{.types = [0], .maxIfaces = 1}, {.types = [2], .maxIfaces = 1}]}]}, {.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}], currentModeIdValid=true, currentModeId=0, ifaces[1].length=0, ifaces[0].length=1, ifaces[2].length=1, ifaces[3].length=0), chipMode={.id = 1, .availableCombinations = [{.limits = [{.types = [1], .maxIfaces = 1}]}]}, chipIfaceCombo=[[email protected], ifaceType=2, lowPriority=false
02-05 22:44:33.571 10656 10744 D HalDevMgr: Requested type not supported by combo
02-05 22:44:33.571 10656 10744 D HalDevMgr: Interface available for: ifaceType=2 = false
02-05 22:44:33.572 10656 10744 D HalDevMgr: Interface available listener dispatched: ifaceType=2, listener=com.android.server.[email protected]2c40602
02-05 22:44:33.572 10656 10744 D HalDevMgr: dispatchAvailableForRequestListenersForType: ifaceType=3
02-05 22:44:33.573 10656 10744 I android_os_HwBinder: HwBinder: Starting thread pool for default::[email protected]::ISupplicant
02-05 22:44:33.574 23753 23753 D WifiSettings: onAccessPointsChanged (WifiTracker) callback initiated
02-05 22:44:33.574 10656 10744 D SupplicantP2pIfaceHal: entering getInterface()
02-05 22:44:33.574 10656 10744 E SupplicantP2pIfaceHal: initSupplicantP2pIface got null iface
02-05 22:44:33.574 10656 10744 E WifiP2pNative: Failed to setup P2p iface in supplicant
02-05 22:44:33.574 10656 10744 D WifiP2pNative: Teardown P2P interface
02-05 22:44:33.574 10656 10744 D HalDevMgr: removeIfaceInternal: iface(name)=p2p0, type=2
02-05 22:44:33.574 10656 10744 D HalDevMgr: getChip: iface(name)=p2p0
02-05 22:44:33.575 10656 10744 D HalDevMgr: dispatchDestroyedListeners: iface(name)=p2p0
02-05 22:44:33.575 10656 10744 D HalDevMgr: dispatchAvailableForRequestListeners
02-05 22:44:33.575 10656 10744 D HalDevMgr: getAllChipInfo
Basically, system_server goes into a tight loop trying and failing repeatedly to bring up p2p0.
This is on Huawei, for what it's worth (Mate 8 - NXT-DL00C17 8.0.0.820; Mate 9 - MHA-AL00C00 8.0.0.374), though given that there are other changes which seem pretty general regarding the wifi HAL between 8.0 and 9.0, it seems likely that there are other things happening that are causing problems and I haven't quite figured it out yet.
For what it's worth: the reason for wanting this is because I've ported Miracast support from Oreo into Pie, and it works on devices I have here with P vendor (Mate 9 AL00C00 9.0.1.150; also apparently working on HMA), but since bringing up the WiFi P2P interface is broken, I can't get any farther with it than that.
Not sure if you resolved the issue yet but on C636 running 9.0.1.159 Miracast seems to work. I can share my phone screen to my Android TV box without problem.
itenos said: Not sure if you resolved the issue yet but on C636 running 9.0.1.159 Miracast seems to work. I can share my phone screen to my Android TV box without problem. Click to expand... Click to collapse Nah, on EMUI it's fine - in this case, its for AOSP Pie built for an EMUI 8 vendor, and there was a good amount of stuff that changed with the WiFi HAL on Pie that caused things to break besides for the bare minimum of functionality needed for wifi to work in the first place. (Hotspot was broken without a HAL being written to provide backwards compatibility behavior, WiFi Direct is broken in the same fashion, I think, but I'm not sure.) It's also fine if you're already on a Pie vendor - Miracast works fine here on AOSP (with patches to pull Miracast forward from Oreo, of course) on both the Mate 9 (AL00, 9.0.1.150), and the P10 (AL00, 9.0.1.160; C432, 9.0.1.165).
Question about wipe encryption in Google Nexus 6p
We all know that there are two types of file encryption, one is called "wipe" and the other is "inplace". I have a project and I have to test how to use wipe to encrypt. So I had a test about the ‘wipe’ encryption in pure lineageOS14.1 but unfortunately it failed. Here are my steps:* 1. Change the parameter "forcefdeorfbe" to "encryptable" in file fstab.angler then recompile the lineage source code to disable the forced encryption in Google Nexus 6P* 2. Get the root of the Nexus 6P (su root)* 3. Type the command in adb: vdc cryptfs enablecrypto wipe password qwer to use ‘wipe’ to delete all the files and then encrypt the system with the password set to ‘qwer’.* Then my cell phone restarted without the encryption that I had expected, here is my log of that error: 02-05 06:22:00.701 370 3185 I Cryptfs : Enabling support for allow_discards in dmcrypt.* 02-05 06:22:00.701 370 3185 I Cryptfs : target_type = crypt* 02-05 06:22:00.701 370 3185 I Cryptfs : real_blk_name = /dev/block/platform/soc.0/f9824900.sdhci/by-name/userdata, extra_params = 1 allow_discards* 02-05 06:22:05.740 370 3185 E Cryptfs : Cannot load dm-crypt mapping table.* 02-05 06:22:05.741 370 3185 I Cryptfs : Making empty filesystem with command /system/bin/make_ext4fs -a /data -l 58688269824 /dev/block/dm-0* 02-05 06:22:05.811 370 3185 I make_ext4fs: SELinux: Loaded file_contexts contexts from /file_contexts.bin.* 02-05 06:22:05.812 370 3185 I make_ext4fs: Creating filesystem with parameters:* 02-05 06:22:05.812 370 3185 I make_ext4fs: Size: 58688266240* 02-05 06:22:05.812 370 3185 I make_ext4fs: Block size: 4096* 02-05 06:22:05.812 370 3185 I make_ext4fs: Blocks per group: 32768* 02-05 06:22:05.812 370 3185 I make_ext4fs: Inodes per group: 8192* 02-05 06:22:05.812 370 3185 I make_ext4fs: Inode size: 256* 02-05 06:22:05.812 370 3185 I make_ext4fs: Journal blocks: 32768* 02-05 06:22:05.812 370 3185 I make_ext4fs: Label:* 02-05 06:22:05.812 370 3185 I make_ext4fs: Blocks: 14328190* 02-05 06:22:05.812 370 3185 I make_ext4fs: Block groups: 438* 02-05 06:22:05.812 370 3185 I make_ext4fs: Reserved block group size: 1024* 02-05 06:22:05.826 370 3185 I make_ext4fs: Created filesystem with 11/3588096 inodes and 271280/14328190 blocks* 02-05 06:22:05.826 370 3185 I make_ext4fs: error: file_write: write: No space left on device* 02-05 06:22:05.830 370 3185 D Cryptfs : Successfully created filesystem on /dev/block/dm-0* I read the function called cryptfs_enable_internal in the file cryptfs.c and there is a variable called "no_ui", it seems that this variable separated the process of encryption into two parts: the preparation before reboot and the real encryption after reboot. Although I don't think this variable should be used in this command when I want to use the ‘wipe’ command to wipe the cell phone and encrypt the cell phone. However, I still tried this:* vdc cryptfs enablecrypto wipe password qwer noui* The cell phone warned me that the data was corrupted and must have a factory reset.* So now I can only use "inplace" to encryt my cell phone, could you please give me some ideas about:* Is there anything wrong with my steps that makes the ‘wipe’ encryption never successful on my phone?