Hello!
My Nord 2 will be plugged in 24/7 because I use it for E2E testing. I need to optimize battery so it wont swell up.
Is there any working solutions for doing it? Or is there a way to put battery charging to idle so main power will be drawn from usb.
I tried Magisk ACC plugin, but it seems it is not running. Shell has supperuser power on magisk
ADB shell:
"acc
/system/bin/sh: <stdin>[2]: acc: inaccessible or not found
accd,
/system/bin/sh: <stdin>[3]: accd,: inaccessible or not found"
Also same error in ACC app, magisk have given supperuser access for that app:
"/system/bin/sh: <stdin>[3544]: acc: inaccessible or not found"
when i execut acc.sh in /data/adb/vr25/acc/ folder then i cant get ACCD running there. Well it runs for a minut then turns off
"
Advanced Charging Controller v2021.8.31 (202108310)
Copyright 2017-2021, VR25
GPLv3+
(i) accd is not running
1) Language
2) All commands
3) Documentation
4) Start/restart daemon
5) Stop daemon
6) Export logs
7) Charge once to #%
8) Uninstall
9) Edit config.txt
a) Reset battery stats
b) Test charging switches
c) Check for update
d) Flash zips
e) Battery info
f) Exit
#? b
(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...
(!) [/proc/mtk_battery_cmd/current_cmd 0::0 0::1 /proc/mtk_battery_cmd/en_power_path 1 0] won't work
(i) Press any key to continue..."
Hi, I'm the developer of acc.
Have you tried a slow charger or USB charging?
Refer to README > Troubleshooting.
This is a kernel/adapter issue.
Edit
Just noticed that you're not using the latest acc release.
Since you're facing issues, upgrading is a must.
Regardless, don't skip the documentation.
I am using PC USB connection for charging. Should ACC daemon allways run? It works for a minute and then stop. Do you mean oneplus nord 2 battery charging management have same kernel issue as you mentioned in ACC thread?
I have tested different versions to be sure. v2021.8.31 came from Magisk for first.
AccA is latest 1.0.35 Daemon/API 202109200
New ver.:
Advanced Charging Controller v2021.9.20 (202109200)
Copyright 2017-2021, VR25
GPLv3+
(i) accd is not running (PID 12046)
1) Language
2) All commands
3) Documentation
4) Start/restart daemon
5) Stop daemon
6) Export logs
7) Charge once to #%
8) Uninstall
9) Edit config.txt
a) Reset battery stats
b) Test charging switches
c) Check for update
d) Flash zips
e) Battery info
f) Undo upgrade
g) Exit
#? b
(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...
(!) [/proc/mtk_battery_cmd/current_cmd 0::0 0::1 /proc/mtk_battery_cmd/en_power_path 1 0] won't work
This is usually a kernel and/or power adapter issue.
The daemon should be running to control charging.
The #1 reason for it to stop is total charging switch failure.
That is, all charging switches fail to respond.
In that case, it finds no reason to keep running.
Share a log archive (acc -le) and the output of acc -p.
Where can i get those logs? From /data/adb/vr25/acc-data/logs/ ? Might it be acc-logs-OP515BL1.tar.gz file?
Somehow "pull" and "cp" are not working on me with adb shell. Is there any better tools for pulling files and logs? There is many tools witch are not working with my phones and cant find root folders, google is to big.
@VR25 Hi! I attached all logs from ACC-data logs folder. Will it help?
CapnRene said:
@VR25 Hi! I attached all logs from ACC-data logs folder. Will it help?
Click to expand...
Click to collapse
Perfect!
I found potential charging switches.
Test the following commands one by one and report the ones that work:
su -c acc -t /sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0
su -c acc -t /sys/devices/platform/charger/enable_sc 0 1
su -c acc -t /sys/devices/platform/charger/enable_sc 1 0
su -c acc -t /sys/devices/virtual/oplus_chg/battery/stop_charging_enable 0 1
su -c acc -t /sys/firmware/devicetree/base/charger/usb_charger_current_suspend 0 1
Note
One/some of the commands may trigger a reboot.
That's not a big deal. Just move to the next on the list.
First line got response:
OP515BL1:/ # su -c acc -t /sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0
(!) Charger must be plugged to continue...
(i) Alright, this may take a minute or so...
(i) [/sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0] works
- battIdleMode=true
As i understand i need to change switch now to get it working?
su -c acc -s s="/sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0"
You should be all set after running that.
The next release will include the new switch.
Edit
Since the device will be plugged in 24/7, you may want to run `acc 3920` to set it up.
Essentially, this will keep the battery voltage between 3870-3920 millivolts.
3920 is said to be the sweet spot for longevity.
Not 100% sure did it work, need to test it a litte to be sure. It seems it updated log
OP515BL1:/ # su -c acc -s s="/sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0"
/system/bin/acc[580]: export: 1: is not an identifier
(i) Alright, this may take a minute or so...
(i) /data/adb/vr25/acc-data/logs/acc-logs-OP515BL1.tar.gz
My bad
It should have been
su
acc -s s="/sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0"
VR25 said:
My bad
It should have been
su
acc -s s="/sys/devices/virtual/oplus_chg/battery/mmi_charging_enable 1 0"
Click to expand...
Click to collapse
It worked! Ty! I set my swich to turn on 59% and off 60% for optimal ressult.
It seems that those are not working or maybe i have made some mistake somewhere:
shutdown capacity
charge current
charge voltage
CapnRene said:
It worked! Ty! I set my swich to turn on 59% and off 60% for optimal ressult.
It seems that those are not working or maybe i have made some mistake somewhere:
shutdown capacity
charge current
charge voltage
Click to expand...
Click to collapse
From the documentation:
# shutdown_capacity (sc) #
# When the battery is discharging and its capacity/voltage_now_millivolts <= sc and phone has been running for 15 minutes or more, acc daemon turns the phone off to reduce the discharge rate and protect the battery from potential damage induced by voltage below the operating range.
# sc=-1 disables it.
# [Beta] if the file /data/adb/vr25/acc-data/warn exists, accd posts Android shutdown warning notifications at sc + 5% or sc + 200 mV.
The last two features are not supported by all devices.
I'm yet to see a MediaTek device that supports at least one of the those.
Please ask further questions in the actual forum, so that other users can help you whenever I'm unavailable.
Related
Good day...
Im wanting to connect a USB camera to my ViewSonic G Tablet... I have 3 different USB models. When I plug them in (individually,) I get the /dev/video0 device but I don't seem to be able to use the device...
Why a second camera? I'm thinking I can use my G Tab in my car with a USB camera connected for a Baby Cam (since the baby faces the other way so I can't see and most of my traveling is at night so the normal mirror won't work unless I blind the poor child...) -- In theory, it could be used as a backup camera as well. (Same effect)
The internal camera works, but I don't need to see myself, I'd rather see something behind me.
Ideas?
I've scoured the Forums in more detail... Several ask the questions and someone made it work on the Nook, but it looked Nook specific. =/
Is there a more appropriate place to ask? This would affect all Android Devices that have a USB Host Port...
Now, the G Tablet, VEGAn mod at least... has the UVC Driver for WebCams. When I plug a camera in I get the /dev/video0 device (which doesn't exist until I plug in a camera.) - could it be permissions or is the driver not fully implemented?
The mplayer app that was released sets the root path to /sdcard so I can't point it at /dev/video0... I've tried to use the stream part, but it just exits the video - no error that I can see...
adamsoutherland said:
Now, the G Tablet, VEGAn mod at least... has the UVC Driver for WebCams. When I plug a camera in I get the /dev/video0 device (which doesn't exist until I plug in a camera.) - could it be permissions or is the driver not fully implemented?
Click to expand...
Click to collapse
The device appearing is a good first sign. Can you get me a dmesg output after you've plugged the webcam in? Run a Terminal Emulator app, then type in the window:
Code:
$ [B]dmesg > /mnt/sdcard/dmesg.txt[/B]
The mplayer app that was released sets the root path to /sdcard so I can't point it at /dev/video0... I've tried to use the stream part, but it just exits the video - no error that I can see...
Click to expand...
Click to collapse
Is this app an Android port of the standard mplayer for Linux? If yes, then it will use the V4L (Video 4 Linux) API to grab video frames, and if you can start it on the command line (or supply an input file name), then you can try "tv://" as the input file name.
Run this command first, though, to give everybody read-write access to /dev/video0:
Code:
$ [B]su[/B]
# [B]chmod 666 /dev/video0[/B]
I'm attaching a dmesg prior to plugging in the camera, and one after... I'm also inserting the text of the "diff" in the post...
Code:
[ 189.574313] usb 1-1.1: new high speed USB device using tegra-ehci and address 3
[ 189.657223] usb 1-1.1: New USB device found, idVendor=18ec, idProduct=3299
[ 189.664506] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 189.671944] usb 1-1.1: Product: USB2.0 PC CAMERA
[ 189.677125] usb 1-1.1: Manufacturer: ARKMICRO
[ 189.685907] usb 1-1.1: configuration #1 chosen from 1 choice
[ 189.695760] uvcvideo: Found UVC 1.00 device USB2.0 PC CAMERA (18ec:3299)
[ 189.708989] uvcvideo: UVC non compliance - GET_DEF(PROBE) not supported. Enabling workaround.
[ 189.732392] input: USB2.0 PC CAMERA as /devices/platform/tegra-ehci.2/usb1/1-1/1-1.1/1-1.1:1.0/input/input7
[ 190.318832] SO340010: gpio_val=0xc0a50000, button_val = 0xdbaf0002
[ 190.445387] SO340010: gpio_val=0xc0a50000, button_val = 0xdbaf0000
and this:
Code:
/data/data/berserker.android.apps.sshdroid/home # ls -lh /dev/vid*
crw-rw---- 1 0 1006 81, 0 Sep 2 18:22 /dev/video0
I've also done this:
Code:
/data/data/berserker.android.apps.sshdroid/home # chmod 666 /dev/video0
/data/data/berserker.android.apps.sshdroid/home # cat /dev/video0 /mnt/sdcard/test.mpg
cat: read error: No such device
/data/data/berserker.android.apps.sshdroid/home # ls -lh /dev/vid*
crw-rw-rw- 1 0 1006 81, 0 Sep 2 18:22 /dev/video0
/data/data/berserker.android.apps.sshdroid/home #
The mplayer was an APK from someone on the forums... I've opened it up only to find a "mplayer.so" as I thought it might contain the mplayer binary... (I don't have a machine (with sufficient space) to load the Android SDK at the moment...) (It's on my todo list.)
Am I right to try "cat /dev/video0" before I find the proper mplayer or event ffmpeg binary? (It generally works in linux when I do it...)
PS - I have 3 WebCams, I can give you a dmesg of each one if you need it... They all appear to do the same thing (they are by different manufacturers... iMicro, Sabrent and Agama.) -- also note that these 3 web cams work in Linux (each slightly different, but they work.)
adamsoutherland said:
The mplayer was an APK from someone on the forums... I've opened it up only to find a "mplayer.so" as I thought it might contain the mplayer binary... (I don't have a machine (with sufficient space) to load the Android SDK at the moment...) (It's on my todo list.)
Click to expand...
Click to collapse
Attach the APK so I can have a look at it.
Am I right to try "cat /dev/video0" before I find the proper mplayer or event ffmpeg binary? (It generally works in linux when I do it...)
Click to expand...
Click to collapse
I'm surprised that that works even on standard Linux! You have to setup the frame capture parameters first using ioctl()s before you can start reading data from /dev/video0. Even after that, you get raw frame data, and not mpeg video from the device.
PS - I have 3 WebCams, I can give you a dmesg of each one if you need it... They all appear to do the same thing (they are by different manufacturers... iMicro, Sabrent and Agama.) -- also note that these 3 web cams work in Linux (each slightly different, but they work.)
Click to expand...
Click to collapse
Attach all the 3 webcams to your desktop machine, check that each one works and get me a dmesg and a lsmod command output for each one. I want to see what drivers are loaded for each one. We'll have to load the same drivers on the gTablet too after compiling them.
Code:
[I]Attach Camera1 and make sure its working, then,[/I]
desktop$ [B]dmesg > dmesg1.txt[/B]
desktop$ [B]lsmod > lsmod1.txt[/B]
[I]Attach Camera2 and make sure its working, then,[/I]
desktop$ [B]dmesg > dmesg2.txt[/B]
desktop$ [B]lsmod > lsmod2.txt[/B]
[I]Attach Camera3 and make sure its working, then,[/I]
desktop$ [B]dmesg > dmesg3.txt[/B]
desktop$ [B]lsmod > lsmod3.txt[/B]
Caveats: Even if we get all the drivers to load on the gTablet (the V4L drivers, the main camera driver, and, possibly, its support drivers), we still have the problem of displaying the video stream on Android. While I'm happy to write whatever systems code is required, writing the Java UI code for the Android app is beyond my ken. We'll have to ask someone else (try in the main Android development forums on XDA, or, ask user herbert1 here who's helped out before with custom Java apps) once we've checked that we can read data from the V4L device (I'll send you a test prog which'll output .jpg files once every second once we have the drivers sorted out).
It would be great if someone has already ported mplayer for Android.
I'm attaching the APK I found...
Side note:
After looking deeper at 'cat /dev/video0'; it does not work with these webcams... I think this works on my TV Cards that natively displayed mpeg2 video (it's been a while).
See the attached dmesg-*.txt and lsmod-*.txt. Each is named after the company logo on the camera. (I can get the model numbers if the dmesg isn't enough.) Between each dmesg I rebooted the linux box for clarity. (They can all work at once, but I get confused on what is doing what.)
The command I used to test:
Code:
ffmpeg -f alsa -i hw:0,0 -f video4linux2 -s 320x240 -i /dev/video0 test-agama.mpg
(Each of these cameras has audio - The audio is not important for what I am attempting to do...)
About the UI... I've been avoiding this but it maybe time to start work on this =P -- I just realized that the box I'm testing the cameras on has space... I may have to reload linux for 64bit but then I can install the Android SDK and get to UI Development.
All three webcams seem to depend on only 3 kernel modules: uvcvideo, videodev and v4l1_compat.
If all 3 drivers are loaded on the gTablet too, then we should be able to get the video frames from /dev/video0 (or whatever the device).
I'll send you a test program this evening. In the mean time...:
That .apk file contains the application too--the classes.dex file contains the Dalvik executable bytecode. Just install the .apk, then run the app and provide a file name as input. Try "tv://" as the file name once all 3 drivers have been loaded. Do the "chmod 666 /dev/video0" before running the app.
Try the webcam test program in the attachment. The program reads from a user-specified V4L device and outputs JPEG images until you stop it with CTRL-C. Run as:
Code:
$ [B]su[/B] [I]Become superuser[/I]
# [B]mkdir /mnt/sdcard/tmp[/B] [I]Make a tmp dir. for storing imgs[/I]
# [B]./webcam -o /mnt/sdcard/tmp[/B] [I]Capture webcam images until stopped with CTRL-C[/I]
Get usage instructions with "./webcam --help".
EDIT: I actually didn't test the program out because I couldn't locate my webcam. Report if you encounter any bugs.
Quick Update:
I will be trying this tonight... I've been busy trying to get things done. (Little one is going to be born tomorrow!)
Sorry I haven't been able to respond sooner...
rajeevvp said:
Try the webcam test program in the attachment. The program reads from a user-specified V4L device and outputs JPEG images until you stop it with CTRL-C. Run as:
Code:
$ [B]su[/B] [I]Become superuser[/I]
# [B]mkdir /mnt/sdcard/tmp[/B] [I]Make a tmp dir. for storing imgs[/I]
# [B]./webcam -o /mnt/sdcard/tmp[/B] [I]Capture webcam images until stopped with CTRL-C[/I]
Get usage instructions with "./webcam --help".
EDIT: I actually didn't test the program out because I couldn't locate my webcam. Report if you encounter any bugs.
Click to expand...
Click to collapse
I copied it to /mnt/asec (because I can execute things there without remount)
When I run it, i get:
Code:
/mnt/asec # ./webcam -o /mnt/asec/tmp -d /dev/video0
./webcam: error getting video channel info. Invalid argument
I tried without the -d /dev/video0 and got the same result.
(Sorry for the LOOONG delay... Turns out a newborn takes more time and energy than I expected. I'm just now figuring that out... =P It's worth it though.)
Try this simple USB Webcam test app in the attachment which works on VEGAn-Tab 7.1 and GtabComb* (which have the pershoot kernel).
1. Plug the USB webcam in.
Assuming the kernel you're running has the correct USB webcam drivers compiled in--and, most of them do seem to have the V4L subsystem and the UVC camera drivers (which supports a lot of the common USB webcams) built into the kernel--you should see a new /dev/video0 device file pop up.
2. Run these commands to set correct permissions and owners on the device file (some ROMs--eg. GtabCombOver--don't need it):
Code:
$ [B]su[/B]
# [B]chown system.camera /dev/video0[/B]
# [B]chmod 660 /dev/video0[/B]
(Note that if you unplug and replug the webcam, you'll have to re-run the commands on ROMs which don't set the correct permissions and owners.)
3. Now install and run the SimpleWebCam app.
If, for some reason, no /dev/video0 device is created, then your webcam may need different device drivers, which have not been compiled in (or not been written!), in which case you'll have to compile a new kernel with the correct drivers either built-in or as loadable modules. Nothing else described in this post will need change.
adamsoutherland said:
When I run it, i get:
Code:
/mnt/asec # ./webcam -o /mnt/asec/tmp -d /dev/video0
./webcam: error getting video channel info. Invalid argument
I tried without the -d /dev/video0 and got the same result.
Click to expand...
Click to collapse
Looks like I'll have to update the code to make the program use the V4L2 API instead.
Nexus 7
Just tested this on my Google Nexus 7 tablet and it worked fine, I didn't have to modify the permissions either,
PS, it is rooted, of sure if that makes much difference, will test it on my friends stock nexus 7 tomorrow
USB Camera App
I was able to get the app working on my rooted Nexus 7 4.2 and an unrooted Galaxy SIII . How hard would it be to add a video record function to the app?
droidoso said:
How hard would it be to add a video record function to the app?
Click to expand...
Click to collapse
If you want to do that, then it's better to compile a custom native camera-interface library which makes the USB webcam appear as a standard camera (--the rear one, usually). Then, you can use the standard apps to record videos.
See this thread for a precompiled binary and for the source.
Hello, I was given a Gtablet by a friend. Everything is in proper working order except for the wifi. The wifi will endlessly scan, never pulling up any SSIDs. Here's what I've done to troubleshoot:
Ascertained flight mode was off (it was)
Enabled wifi through the developer options (Did nothing)
Manually enter SSID/Security information (Claims that SSID is not in range)
Reloaded the OS (He had VEGAn Tab on there. I reloaded the 5.1 Beta. I don't know what version he had on there, oops.)
After a clean install I have the exact same issue, which leads me to believe it is a hardware issue rather than a software issue. Is this common? Am I forgetting something? Would loading an entirely different ROM be of any use or do they also use the same driver?
My apologies if this has been answered previously, but in all my searching I can only find people who have this problem temporarily; a reboot fixes it for them. I haven't been able to find someone who has had this as a persistent issue.
JungleWallace said:
Hello, I was given a Gtablet by a friend. Everything is in proper working order except for the wifi. The wifi will endlessly scan, never pulling up any SSIDs.
Click to expand...
Click to collapse
I'll have to look at some logs to ascertain what your WiFi problem is.
Run the commands in this post (after rebooting the tablet) and then post the text files that're created.
rajeevvp said:
I'll have to look at some logs to ascertain what your WiFi problem is.
Click to expand...
Click to collapse
Thanks, see attached are the logs as per request. As a side note, now that I have the terminal emulator on there I tried a few commands I dug up on the internet after I looked over the logs.
Code:
$ su
# ifconfig tiwlan0 up
# ifconfig eth0 up
Both gave an error message
Code:
error: SIOCGIFFLAGS (No such device)
Also
Code:
# svc wifi enable
did not solve my issues. Oh well.
FYI:
JungleWallace said:
...I tried a few commands I dug up on the internet after I looked over the logs.
Code:
$ su
# ifconfig tiwlan0 up
# ifconfig eth0 up
Both gave an error message
Code:
error: SIOCGIFFLAGS (No such device)
Click to expand...
Click to collapse
The wireless LAN interface name on the gTab is wlan0. Hence your error messages: "No such device" for the ifnames tiwlan0 and eth0. (The latter would work for the ethernet I/F on the dock--if you had one connected.)
Also
Code:
# svc wifi enable
did not solve my issues. Oh well.
Click to expand...
Click to collapse
1. You have to look at the Android system logs (using logcat) to see the result of that svc command.
2. Your Android logs indicate that your WiFi interface is a) disabled at startup and b) then not enabled thereafter:
Code:
01-07 23:21:10.429 V/ConnectivityService( 990): Starting Wifi Service.
01-07 23:21:10.429 I/WifiService( 990): WifiService starting up with Wi-Fi [B]disabled[/B]
Suggestions:
Since this now looks like a ROM problem (ie. not HW):
1. See this thread. Run the script to disable Airplane Mode which might be causing your problem. If that doesn't work, try step 2:
2. Boot into CWM and then a) Format /cache and b) Repartition the Internal SD card (take the external one out first).
You'll lose all your current apps and data with this step, essentially reverting to a "fresh" install of your ROM.
Re-setup WiFi, time & date and other things again.
If step 2. doesn't work, report back next year, and I'll give you more commands to run then.
rajeevvp said:
If step 2. doesn't work, report back next year, and I'll give you more commands to run then.
Click to expand...
Click to collapse
Negative. Ran the airplane fix script, nothing. Reset cache/re-partitioned, still nothing. It's still endlessly scanning/shutting off/scanning.
JungleWallace said:
Negative. Ran the airplane fix script, nothing. Reset cache/re-partitioned, still nothing.
Click to expand...
Click to collapse
OK. Not one of the common simple problems, then.
It's still endlessly scanning/shutting off/scanning.
Click to expand...
Click to collapse
This is puzzling because from your last logs, it doesn't look like the wlan kernel driver was even loaded, so no AP scanning should be possible. A little background will clarify what I mean.
On all the 2.6.32.x kernels for the gTablet, the wlan driver is not compiled into the kernel. Instead, it is built as a separate kernel module which is loaded and unloaded as needed by Android (from the files in /system/lib/hw/wlan/). When the wlan driver is loaded both the kernel (dmesg) and Android (logcat) will show some characteristic messages and until the driver is inserted into the kernel no AP scanning, or other wireless functions, should be possible. And, no wlan driver-related messages in your logs tells me that the driver was likely not loaded. (Also, only after the wlan driver is loaded does it check and initialize the wireless HW. So, only after its been loaded, strictly speaking, can we rule out a HW problem.)
Sometimes the Android logs are not complete, so I want to you setup ADB on your PC, enable USB debugging on the gTablet (Setting > Applications > Development) and collect the Android logs like this from now on:
1. Power off gTab; attach the USB cable to it.
2. Open a CMD.exe window on the PC, then run this command (and keep the window minimized):
Code:
C:\> [B]adb logcat -v time > logcat.txt[/B]
After all the tests/commands have been done, restore this window and press Ctrl-C to kill ADB and terminate Android log collection.
3. Power on the gTablet. The ADB command will wait for the gTablet and keep collecting logs on the PC.
Post also the output of these commands:
Code:
C:\> [B]adb shell dmesg > dmesg.txt[/B]
C:\> [B]adb shell lsmod > lsmod.txt[/B]
C:\> [B]adb shell "cd /; find system -type f -print0 | xargs -0 sha1sum" > sha1sum.txt[/B]
Is this the ROM you currently have?
Have you applied the VEGAn 1.00 beta 5.1.1 supplement also?
rajeevvp said:
OK. Not one of the common simple problems, then.
.........
Is this the ROM you currently have?
Have you applied the VEGAn 1.00 beta 5.1.1 supplement also?
Click to expand...
Click to collapse
That was the current ROM I was using. I had not applied the supplement yet, but now I have. Still the same issue. Here are the logs.
JungleWallace said:
That was the current ROM I was using. I had not applied the supplement yet, but now I have. Still the same issue. Here are the logs.
Click to expand...
Click to collapse
In this one I can see the kernel WiFi driver being loaded, and the driver is not reporting any HW chip, SDIO bus, or other errors:
Code:
<4>[ 23.485281] sdio_reset_comm():
<4>[ 23.503617] DHD: dongle ram size is set to 294912(orig 294912)
<4>[ 23.676913] Firmware version = wl0: May 17 2010 22:38:50 version 4.218.223.1
<4>[ 23.887647] wlan0: Broadcom Dongle Host Driver mac=e0:2a:82:08:3e:81
<4>[ 23.894047] Enter wl_control_wl_start
<4>[ 23.897864] Exited wl_control_wl_start
<4>[ 23.907103]
<4>[ 23.907109] Dongle Host Driver, version 4.218.223.1
As far as the kernel driver is concrned, everything looks OK, but the Android logs still don't show any SSID associations.
What're the exact outputs of these commands? (You can post a screenshot. Mask the psk= value from the 1st output, if present)
Code:
C:\> [B]adb shell "fgrep -v '#' /data/misc/wifi/wpa_supplicant.conf | tr -s '\n'"[/B]
ctrl_interface=wlan0
update_config=1
...
C:\> [B]adb shell wpa_cli -i wlan0 driver rssi[/B]
...
C:\> [B]adb shell wpa_cli -i wlan0 driver linkspeed[/B]
LinkSpeed [I]nn[/I]
C:\> [B]adb shell wpa_cli -i wlan0 scan[/B]
OK
C:\> [B]adb shell wpa_cli -i wlan0 scan_results[/B]
bssid / frequency / signal level / flags / ssid
aa:bb:cc:dd:ee:ff 2452 185 [WPA2-PSK-CCMP] [I]YourSSID[/I]
Collect also the dmesg and logcat outputs as before.
[/FONT]
rajeevvp said:
What're the exact outputs of these commands? (You can post a screenshot. Mask the psk= value from the 1st output, if present) [...] Collect also the dmesg and logcat outputs as before.
Click to expand...
Click to collapse
See attached. Ignore my syntax errors that I underlined. I was typing wlan instead of wlan0.
JungleWallace said:
Ignore my syntax errors that I underlined. I was typing wlan instead of wlan0.
Click to expand...
Click to collapse
Those are OK since you've corrected them. But, these commands you'll have to redo:
1. In the first command (fgrep ... | tr), you've typed a '/' (forward slash) instead of what I've given in the example, which is a '\' (back-slash) character.
The correct character will remove all those blank lines. But, this is a minor typo compared to:
2. The last 2 commands (wpa_cli scan* ...), which you'll have to redo. This time without the extraneous driver argument (again, see the example)--which turns it into a completely different (and non-existent) command. This is why the output doesn't look like what I've shown.
Instead of typing the commands in manually, select and copy the command lines from the browser and paste them into the shell window.
You might also want to increase the no. of columns that CMD.exe displays: Right-click on the title-bar; choose Properties; select Layout; increase the no. of Columns to, let's say, 150.
3. That dmesg.txt file is not very useful because you've not rebooted the tablet before issuing that command.
The kernel has a fixed-size message buffer, so all the HW initialization messages printed only at system boot will be overwritten by later, and irrelevent, messages as time passes. From the timestamps, it looks like your tablet's been on for a couple of weeks, at least--I can't see any of the earlier boot-up messages.
Following the instructions below, I managed to get my USB DAC to work. I will attach the drivers that worked for me.
aluver said:
So, I am glad to say, we have USB Audio (DACs) support now.
If you want to build a serious car sound system, you have to make a digital out to your amp (or DSP) instead of using our head units line outs.
I will try to write in more detail and more simply as to repeat it.
For the redirection of all sounds of the Android to your USB device (a sound card, DAC) it is necessary:
1. To be convinced that a system's kernel version is 3.0.36+ . The version of a firmware can be any. At me I was KLD-1.98 and 4.2.2. But despite it I pulled out driver modules from a tablet firmware on the Android 4.4.2.
2. Get root, root explorer and Android terminal emulator.
3. Copy by root explorer USB Audio support modules *.ko from the applied archive in /system/lib/modules/, and set them permissions to 0644.
4. It is obligatory to try loading modules manually from the terminal exactly in that order:
Code:
[email protected]:/ $ su
[email protected]:/ # insmod /system/lib/modules/snd-hwdep.ko
[email protected]:/ # insmod /system/lib/modules/snd-rawmidi.ko
[email protected]:/ # insmod /system/lib/modules/snd-usbmidi-lib.ko
[email protected]:/ # insmod /system/lib/modules/snd-usb-audio.ko
If the device reboots at execution of this commands, these drivers don't suit to you (though probability of it is small as our HU are identical)
If system silently swallowed your commands - everything normally, we go further.
5. Connect your USB device to one of the back USB ports intended for 3G/Wifi (as we surely need port with support of USB-host).
6. In the terminal enter the following commands and check your device, what number it was defined.
Code:
[email protected]:/ # ls dev/snd
controlC0
controlC1
controlC2
pcmC0D0c
pcmC0D0p
pcmC1D0p
[COLOR="Red"]pcmC2D0c
pcmC2D0p[/COLOR]
timer
[email protected]:/ # cat /proc/asound/cards
0 [RK29WM8731 ]: RK29_WM8731 - RK29_WM8731
RK29_WM8731
1 [RKHDMII2S ]: RK-HDMI-I2S - RK-HDMI-I2S
RK-HDMI-I2S
[COLOR="red"]2 [Headset ]: USB-Audio - Plantronics Headset
Plantronics Plantronics Headset at usb-usb20_host-1.3, full speed[/COLOR]
[email protected]:/ #
Apparently from replies of system, my test Plantronics headset received the address pcmC2D0p - that is Card 2 Device 0. Remembered these figures. Due to the identical architecture of our HU, I think, it will be similar for all of us.
7. To make modules *.ko were loaded at each start of a system, it is necessary to copy by root explorer install-recovery.sh script from archive to /system/etc/install-recovery.sh, set permissions 0755.
8. For providing the redirection of a sound to our USB device it is necessary to deceive system. For this purpose it is necessary to replace number of the device (card) in file /system/lib/hw/audio.primary.rk30board.so. You need find 'pcmC0D0p' string and change it to your remembered value (pcmC2D0p, I think so). It is best of all to make it on the computer by any binary files editor. But I put already my edition of the audio.primary.rk30board.so file with pcmC2D0p value. Don't forget to set it permission 0644. And it is obligatory to make a backup of the original file for ability to return to an initial state.
Click to expand...
Click to collapse
At step 7. my unit looses root capability, therefore I created a script that runs after boot with Script manager.
The script contains the following:
insmod /system/lib/modules/snd-hwdep.ko
insmod /system/lib/modules/snd-rawmidi.ko
insmod /system/lib/modules/snd-usbmidi-lib.ko
insmod /system/lib/modules/snd-usb-audio.ko
At step 8, I didn't find that PCM in my unit so I used another audio.primary.rk30board.so file. I will attach it below.
Problems:
After the sound was rerouted to the DAC, I discovered that I can't control the volume.
Therefore, I bought USB AUdio Player PRO. Now I can control volume, but only from the app, the buttons still doesn't work.
!!!!!! I want to change the tracks from the buttons + SWC and the volume too.
I tried Headunit app, but it doesn't do anything with this player.
PS: Viper4Android doesn't work with this app too.
Instead, Viper4Android works with stock musicplayer but I can't control the volume over HiFimeDIY Sabre USB DAC ES9023 96kHz/24bit
PS2: After I start the USB Audio Player PRO App, I get no sound in other applications. If I don't start that app, I get sound in stock Music Player, Youtube, PowerAmp, etc.
Excellent!
I have found that I can control the volume with the following command:
alsa_amixer -c N cset numid=X Y
Click to expand...
Click to collapse
Where:
N is the number of the card
X is the option corresponding to the volume
y is the value of the volume
In my case, maximum volume is 110 and minimum is 0
Example of command in my case:
alsa_amixer -c 2 cset numid = 2 100
Click to expand...
Click to collapse
Can someone please make a widget/app or integrate it somehow in Headunit so that I can control the volume?
I would be very grateful.
R4D3N said:
I have found that I can control the volume with the following command:
Where:
N is the number of the card
X is the option corresponding to the volume
y is the value of the volume
In my case, maximum volume is 110 and minimum is 0
Example of command in my case:
Can someone please make a widget/app or integrate it somehow in Headunit so that I can control the volume?
I would be very grateful.
Click to expand...
Click to collapse
Here is my edition of last version (2.15) of RK3066-Headunit-service
My edition is able to change the volume levels of DAC and HU together - in same percentage.
DAC volume is changing by command:
Code:
alsa_amixer -c2 sset 'PCM' X%
where 2 - is a card number of DAC (for our HU is always 2)
PCM is the name of alsa volume simple control of Sabre U2 (and many others DACs too)
X% - the value of volume, % - always equal to internal volume of HU, that calculating from 0...30 to 0...100 "exponentialy" by microntek service.
And by the way it also can switch folders/albums in Poweramp through API-commands NEXT_IN_CAT / PREVIOUS_IN_CAT (my wheel buttons codes for it - 61, 62; yours may be different).
I wrote to petrows (developer of this RK3066-Headunit-service) about this modification and asked him to include this functionality to next versions.
Thank you very much. It works but now I have another problem.
After 10-15 minutes, the volume control stops working. It remains or at maximum volume or at the last volume that was set up.
Any ideas how to fix this?
I gues sthe problem is that your volume knob does not control android's volume but send commands to MCU.
Could you try using "Volume+" App to control volume if that works?
Volume+ doesn't work over my DAC.
Headunit does, but after 15 minutes stops working, but if I clear data or restart the Headunit application it works again for 15 minutes.
Any ideas?
PS: SHould I give special permissions to Headunit app? Before it was 0777 and now I am trying with 0644 and I will get back with review.
R4D3N said:
Thank you very much. It works but now I have another problem.
After 10-15 minutes, the volume control stops working. It remains or at maximum volume or at the last volume that was set up.
Any ideas how to fix this?
Click to expand...
Click to collapse
I have had this problem, but only once. Not depends from time in my case. Fixed by reboot too. I think you need to check the direct capability of alsa_amixer to change the dac volume from terminal when it happened again.
Code:
su
alsa_amixer -c2 sset 'PCM' 50%
If it will work, i think the problem is your SU is only for 15 minutes for application. Check your root preferences.
---------- Post added at 07:51 PM ---------- Previous post was at 07:44 PM ----------
dark alex said:
I gues sthe problem is that your volume knob does not control android's volume but send commands to MCU.
Could you try using "Volume+" App to control volume if that works?
Click to expand...
Click to collapse
Our RK3066 HU doesn't have this functional - android volume change is blocked by ROM. Tried this some time earlier.
Alsa mixer was used on this reason. Service just catches microntek MCU volume changes and sends alsa_amixer commands with the same value of volume in %.
How do I check my root preferences?
aluver said:
Code:
su
alsa_amixer -c2 sset 'PCM' 50%
If it will work, i think the problem is your SU is only for 15 minutes for application. Check your root preferences.
.
Click to expand...
Click to collapse
This works so the problem is my root preferences.
then you have to change it in superuser (or SuperSU - depending) app.
I tried but It won't appear in Superuser because when I run it, it doesn't prompt for Root Privilleges, it just runs. How can I manually add it to Superuser?
PS: I am using Malaysk's latest firmware for RK3188.
I installed SuperSU, i granted permanent SuperUser for Headunit but I have the same problem. After a while, the volume control stops working. It works again only if I reboot or if I clear data of the Headunit program.
Ideas?
R4D3N said:
I installed SuperSU, i granted permanent SuperUser for Headunit but I have the same problem. After a while, the volume control stops working. It works again only if I reboot or if I clear data of the Headunit program.
Ideas?
Click to expand...
Click to collapse
When you clear data of the Headunit program, it restarts. So, you just give it 15 min of work with root-access again. Try to delete in SuperSU access rule for this service and reboot. When it will ask for root, give it permanent root. Or you can choose in SuperSU permanent root for all applications.
Thank you very much. I got that working too, I now I have only one problem.
Everytime I power one the unit or when it powers from sleep the volume is at 100% and after I press the volume button it changes at the value on the screen.
Is there a way the set set the default volume as MUTE or 10% ?
Any idea?
If this happens after cold start too, I have the one idea only. Your sevice is starting too early, before the DAC determined by system. Check your startup sequences scripts.
Insmod-commands must be at first positions of install-recovery.sh
mtcservice must be launched by install-recovery-2.sh
There is no problem for me with Malaysk fw #23.
default install-recovery-2.sh from there:
Code:
#dsa
lsd () {
to=$1
shift
for i in $*; do
if [ -d $i ]; then
i=${i%/}
j=${i##*/}
if [ "${j#com.tomtom.*}" != "$j" ]; then
k=$((k+1))
j=$to/$j
if [ -n "`ls $j`" ]; then continue; fi
mkdir -p $j
if mount | grep "$j "; then umount $j; fi
mount -o bind $i $j
else
lsd $to $i/*/
fi
fi
done
}
{
IFS=${IFS#??}
while ! mount | grep "/mnt/internal_sd "; do sleep 1; done
ck=0
while true; do
k=0
#########################################################################
### lsd syntax: ###
### First argument is the target (internal) folder. ###
### Further arguments make a list of source (external) storage paths. ###
### If any com.tomtom.* folder is found in any source path tree, ###
### it will be (bind) mounted under the target folder. ###
#########################################################################
lsd /mnt/internal_sd/tomtom /mnt/external_sd*/*/ /mnt/usb_storage*/*/
if [ $k -gt 0 ]; then
ck=0
sleep 20
continue
fi
if [ $ck -ge 90 ]; then
sleep 30
else
ck=$((ck+1))
sleep 1
fi
done
} >/dev/null 2>&1 &
getpid () {
ps | busybox sed -n "/busybox sed -n/! s/[^ ]* *\([0-9]*\).*$1.*/\1/p"
}
while true; do
pid=`getpid maxmpz`
if [ -z "$pid" -o "$pid" != "$pap" ]; then
om=0
st=0
while true; do
st=$((st+1))
nm=`mount | grep usb_storage | busybox wc -l`
if [ $nm -ne $om ]; then
om=$nm
st=0
else
if [ $st -gt 3 ]; then
if [ $nm -gt 0 ]; then
usb=1
break
fi
if [ -z "$usb" ]; then
break
fi
st=0
fi
fi
if [ $nm -gt 0 ]; then
sleep 1
else
sleep 3
fi
done
while ! am startservice -a com.maxmpz.audioplayer.API_COMMAND --ei cmd 3; do sleep 1; done
sleep 2
pap=`getpid maxmpz`
fi
pid=`getpid petrows`
if [ -z "$pid" ]; then
while ! am startservice com.petrows.mtcservice/.ServiceMain; do sleep 1; done
sleep 1
fi
sleep 10
done &
As you can see startservice com.petrows.mtcservice exists here by default.
I have just replaced old mtcservice apk by new own edition.
PS: Answer with quotes please, because it's the only way to get an E-mail notification for me. I visit this place very rarely.
Does anyone use any RCA mixer or other stuff with DAC to use the built in BT handsfree and FM radio? If I understand good need to connect the DAC and the head unit's RCA outputs to the amplifier in same time.
I found this: Rolls MX22A it is an active mixer, or a passive diy mixer good enough for us?
Or anybody tired the Behringer UCA202/UCA222? It has RCA input and monitor output.
I haven't got any DAC, so I can't try it, but thinking of buying one.
peti007 said:
Does anyone use any RCA mixer or other stuff with DAC to use the built in BT handsfree and FM radio? If I understand good need to connect the DAC and the head unit's RCA outputs to the amplifier in same time
Click to expand...
Click to collapse
If you want to built SQ system, don't do this. This way is wrong - you'll loose the sound quality your DAC gives. Just leave one pair of speakers (coax at rear?) plugged to front speaker outs of your HU and all dirt will live there with BT and radio. You'll CAN hear sound from them, when you need that, but the noise from line outs of HU shouldn't be mixed to your clear music stream
The real music must be at front only: 2-way, 3-way, with sub, etc.
aluver said:
If you want to built SQ system, don't do this. This way is wrong - you'll loose the sound quality your DAC gives. Just leave one pair of speakers (coax at rear?) plugged to front speaker outs of your HU and all dirt will live there with BT and radio. You'll CAN hear sound from them, when you need that, but the noise from line outs of HU shouldn't be mixed to your clear music stream
The real music must be at front only: 2-way, 3-way, with sub, etc.
Click to expand...
Click to collapse
If I listen to FM radio, the HU's RCA out sounds and the DAC is muted, if I listen to music over DAC the HU's RCA is muted.
Maybe I'm wrong, but if I connect the HU's front RCA out and the DAC's RCA out to the RCA mixer in the same time, it doesn't mean they both sound in the same time. There is noise on the HU's RCA too when no sound came out from it?
Hi guys, i successfully build from scratch a device and vendor tree for my rom, and compile CM13 with no problems.
The roms boots but i get a bootloop when it come into "starting apps". My idea is get adb working on boot proccess.
I was googling but i couldn't get working....
This is my init.qcom.rc: https://drive.google.com/open?id=0ByjBTzGuQ9FIQldHTGxBWjdtczQ
And init.usb.rc generated by CM13: https://drive.google.com/open?id=0ByjBTzGuQ9FIc1ZVNnVpTVExOE0
Thanks
Well guy i was digging around and testing ALOT with no luck. Still can't enable adb at boot.
I try adding this properties on default.prop:
Code:
ro.adb.secure=0
ro.secure=0
ro.debuggable=1
persist.sys.usb.config=mtp,adb
An this in build.prop:
Code:
ro.default_usb_mode=0
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=mtp,adb
My device is a Forge TV, and it have a single usb port and no sdcard slot, so the only way to get a log is via usb...
In the stock rom, by default, starts in host mode (storage) and you have to go into config to change it into "device mode" to get usb adb working....
Probably i need to manage how the usb port starts at boot, i thought that "ro.default_usb_mode=0" was the solution...but no
Any help will be appreciated!
PS. lsusb doesn't recognize any device....only in fastboot mode
So i found out something interesting...in stock rom if i execute the command echo 0 > /proc/usb_device the device put itself in device mode and i can debug, putting that value to 1 reverts to storage.
I try to put that on init.d, or even on init.qcom.rc in the boot image with no luck....it's so frustating...
Ususally adbd should already be running this late during the boot.
Can you at least get an usb connection during boot? (check lsusb)
If you want to get at least a dmesg output during boot you could try the following:
set this in the build.prop
Code:
debug.sf.nobootanimation=1
set the following in your kernel defconfig
Code:
CONFIG_VGA_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
(not all of them are needed but I forgot which ones are and which ones are not)
add this to the kernel command line
Code:
console=tty1 loglevel=7
This should at least show some output on the phone screen itself.
To run something in the console, you could try to connect an usb keyboard or use something like a scriptable virtual keyboard.
You might need to set loglevel to 1 or 0 if you don't want it to spam your console while working on it.
ruleh said:
Ususally adbd should already be running this late during the boot.
Can you at least get an usb connection during boot? (check lsusb)
If you want to get at least a dmesg output during boot you could try the following:
set this in the build.prop
Code:
debug.sf.nobootanimation=1
set the following in your kernel defconfig
Code:
CONFIG_VGA_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
(not all of them are needed but I forgot which ones are and which ones are not)
add this to the kernel command line
Code:
console=tty1 loglevel=7
This should at least show some output on the phone screen itself.
To run something in the console, you could try to connect an usb keyboard or use something like a scriptable virtual keyboard.
You might need to set loglevel to 1 or 0 if you don't want it to spam your console while working on it.
Click to expand...
Click to collapse
Hi, thanks alot for your answer! My device is a Razer Forge TV wich is an Android TV device. It's equiped with a single full usb 3.0 port and no sdcard slot. The port works in 2 ways, by default in host mode and device mode (the mode i need to get some debug output). In the stock rom executing "echo 0 > /proc/usb_device" enable this mode and remains on reboot. But doesn't seems to work on CM (i put the command on an init.d script). lsusb reports nothing (equal in stock rom when the port is in host mode).
I test the soluton you provided, but instead of bootanimation i get a black screen then optimizing apps, starting apps and reboot (wich is my main problem)....there's no output on screen...i'm stuck on this like 10 days or more...is so annoying...thanks again
achaw said:
Hi, thanks alot for your answer! My device is a Razer Forge TV wich is an Android TV device. It's equiped with a single full usb 3.0 port and no sdcard slot. The port works in 2 ways, by default in host mode and device mode (the mode i need to get some debug output). In the stock rom executing "echo 0 > /proc/usb_device" enable this mode and remains on reboot. But doesn't seems to work on CM (i put the command on an init.d script). lsusb reports nothing (equal in stock rom when the port is in host mode).
I test the soluton you provided, but instead of bootanimation i get a black screen then optimizing apps, starting apps and reboot (wich is my main problem)....there's no output on screen...i'm stuck on this like 10 days or more...is so annoying...thanks again
Click to expand...
Click to collapse
You could try to insert a usb stick, mount it, and then write dmesg and/or adb output to it using init.rc.
Alternatively you could try to enable adb over tcp and connect that way to it.
Alos try to chose a different tty in the kernel command line.
(btw are the following three lines present in your kernel defconfig?)
Code:
CONFIG_VT_CONSOLE=y
CONFIG_TTY=y
CONFIG_VT=y
ruleh said:
You could try to insert a usb stick, mount it, and then write dmesg and/or adb output to it using init.rc.
Alternatively you could try to enable adb over tcp and connect that way to it.
Alos try to chose a different tty in the kernel command line.
(btw are the following three lines present in your kernel defconfig?)
Code:
CONFIG_VT_CONSOLE=y
CONFIG_TTY=y
CONFIG_VT=y
Click to expand...
Click to collapse
I can't mount usb or enable adb over tcp becasuse the system reboot itself at starting apps...
Right now i'm testing with your new config, switching ttys because i'm still getting black screen instead some output...
Well after some days i remember that the Forge iss equipped with a ethernet port...i feel so stupid lol...
So i was able to debug via adb over tcp.... @ruleh thanks alot for your time!
I think "starting apps" happens when zygote is started.
If it is really the case then it should be possible to mount an usb stick and write the logs to it before everything reboots.
According to the init files I have, init.${ro.hardware}.rc would be the place to do the mount+write.
Ideally /system is mounted and /system/bin is in the path to access tools like logcat and dmesg.
Otherwise you could include them in /sbin which is (in most cases) part of the ramdisk.
It would probably be something like this:
Code:
on early-boot
#mkdir /mnt/usb
mount /dev/(usb_stick) /mnt/usb
exec /system/bin/dmesg > /mnt/usb/dmesg.log
exec /system/bin/logcat > /mnt/usb/logcat.log
(I have never used the init.rc files directly so I am not too sure.)
Also did you try "write /proc/usb_device 0" instead of "echo 0 > /proc/usb_device" in the init.rc files? (preferably before zygote starts...maybe init.usb.rc?)
Or you could try to remove the lines referencing zygote from the init.rc files and see if adbd starts then or not.
---------- Post added at 20:17 ---------- Previous post was at 20:16 ----------
achaw said:
Well after some days i remember that the Forge iss equipped with a ethernet port...i feel so stupid lol...
So i was able to debug via adb over tcp.... @ruleh thanks alot for your time!
Click to expand...
Click to collapse
I wish I read this a bit earlier...... oh well
Hi thanks for reading
I have a rooted Android TV Box [CSA96] running Marshmallow. When first plugged in to AC power, the only indicator of this is a red LED. There is no battery so no charging screen or any output (HDMI). The power button must be pushed in order for Android to boot up. The LED turns blue when the power button is pushed.
My goal is to force the device to automatically turn on when plugged into AC power, removing the requirement of pushing the power button.
From what I've learned so far, the button isn't necessarily a physical barrier -- while plugged in, Android is in a Low Powered State and can listen for an event saying the power button has been pushed. I want to try to invoke the event manually by editing init.rc ... but I am not certain if init.rc is even available at this time, or what other parts of the Android environment are available before the power button is pushed (if any). I'd like to gain an understanding of this so that I am not stumbling in the dark.
Before I continue, I'd like to mention here that I am a developer and am comfortable bricking the device (I've done it several times already, and recovered no problem). I am also using Android Image Kitchen for persistent modification of the system.
Another thing I'd like to say too is, I am well aware of the fastboot oem off-mode-charge 0 command. Unfortunately I have not been able to get fastboot working with this device. The drivers are definitely working as I can flash this device, and even access its bootloader. However for the life of me fastboot devices never shows anything. If someone knows a trick to get it working on the CSA96, that would be great as I'd love to actually try this command for a simple solution
Okay. So I'll get into why I am thinking the key to this is through the init.rc ...
The / dir has several init files, but the ones that seem to be relative to what I am doing are init.rc and init.rockchip.rc and maybe init.debug-charging.rc. I'll paste some of the contents of each ...
[init.rc]
Code:
# Healthd can trigger a full boot from charger mode by signaling this
# property when the power button is held.
on property:sys.boot_from_charger_mode=1
class_stop charger
trigger late-init
Code:
on charger
class_start charger
init.rockchip.rc
Code:
service charger /charger
class charger
seclabel u:r:healthd:s0
Code:
on property:ro.boot.charger.emmc=1
mount ext4 /dev/block/platform/emmc/by-name/system /system wait ro noatime nodiratime
start console
mount ext4 /dev/block/platform/emmc/by-name/metadata /metadata wait noatime nodiratime nosuid nodev noauto_da_alloc,discard
start charger
on property:ro.boot.charger.emmc=0
insmod /rk30xxnand_ko.ko
mount ext4 [email protected] /system wait ro noatime nodiratime noauto_da_alloc
start console
mount ext4 [email protected] /metadata wait noatime nodiratime nosuid nodev noauto_da_alloc
start charger
on charger
setprop ro.boot.charger.emmc 0
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH /vendor/lib:/system/lib
setprop sys.usb.config adb
So in the init.rockchip.rc file, a service named charger invokes a binary called charger, located at /charger ... I found the source code for this program here: https://gitlab.com/pbeeler/system_core/commit/e4b7b294f37d9b64d6b7c1931e2c9bfb1a500d68
Here is a snippet that I find interesting (Line 830)..
Code:
if (code == KEY_POWER) {
if (key->down) {
int64_t reboot_timeout = key->timestamp + POWER_ON_KEY_TIME;
if (now >= reboot_timeout) {
LOGI("[%lld] rebooting\n", now);
android_reboot(ANDROID_RB_RESTART, 0, 0);
/* We do not currently support booting from charger mode on
all devices. Check the property and continue booting or reboot
accordingly. */
if (property_get_bool("ro.enable_boot_charger_mode", false)) {
LOGI("[%lld] booting from charger mode\n", now);
property_set("sys.boot_from_charger_mode", "1");
} else {
LOGI("[%lld] rebooting\n", now);
android_reboot(ANDROID_RB_RESTART, 0, 0);
}.....
So while I don't entirely understand the order of operation, it seems that when the device is plugged in, the charger service is run (executing the /charger binary) .. this binary detects the power button key, and if pressed, sets the sys.boot_from_charger_mode property to 1. Then the on property event inside the init.rc file is triggered, and then i assume late-init is what boots up the device.
So it appears that the contents of init.rc are available at some capacity, before Android has booted up. But I've tried a few adjustments to these files with no results. One thing I've tried is adding setprop sys.boot_from_charger_mode 1 to init.rockchip.rc's on charger event, or at the top of init.rc and other places.
I've also tried changing /charger to /system/bin/reboot
I've also tried putting trigger late-init under init.rockchip.rc's on charger event too.
When I make these changes and try them on the device, I do check the files to verify the changes had stayed.. and they do.
So now I cannot help but wonder that perhaps I am on the wrong track and that maybe these files aren't actually available before the power button is pushed. Some insight would be greatly appreciated.
Thank you.
Jiketsu said:
Hi thanks for reading
I have a rooted Android TV Box [CSA96] running Marshmallow. When first plugged in to AC power, the only indicator of this is a red LED. There is no battery so no charging screen or any output (HDMI). The power button must be pushed in order for Android to boot up. The LED turns blue when the power button is pushed.
My goal is to force the device to automatically turn on when plugged into AC power, removing the requirement of pushing the power button.
From what I've learned so far, the button isn't necessarily a physical barrier -- while plugged in, Android is in a Low Powered State and can listen for an event saying the power button has been pushed. I want to try to invoke the event manually by editing init.rc ... but I am not certain if init.rc is even available at this time, or what other parts of the Android environment are available before the power button is pushed (if any). I'd like to gain an understanding of this so that I am not stumbling in the dark.
Before I continue, I'd like to mention here that I am a developer and am comfortable bricking the device (I've done it several times already, and recovered no problem). I am also using Android Image Kitchen for persistent modification of the system.
Another thing I'd like to say too is, I am well aware of the fastboot oem off-mode-charge 0 command. Unfortunately I have not been able to get fastboot working with this device. The drivers are definitely working as I can flash this device, and even access its bootloader. However for the life of me fastboot devices never shows anything. If someone knows a trick to get it working on the CSA96, that would be great as I'd love to actually try this command for a simple solution
Okay. So I'll get into why I am thinking the key to this is through the init.rc ...
The / dir has several init files, but the ones that seem to be relative to what I am doing are init.rc and init.rockchip.rc and maybe init.debug-charging.rc. I'll paste some of the contents of each ...
[init.rc]
Code:
# Healthd can trigger a full boot from charger mode by signaling this
# property when the power button is held.
on property:sys.boot_from_charger_mode=1
class_stop charger
trigger late-init
Code:
on charger
class_start charger
init.rockchip.rc
Code:
service charger /charger
class charger
seclabel u:r:healthd:s0
Code:
on property:ro.boot.charger.emmc=1
mount ext4 /dev/block/platform/emmc/by-name/system /system wait ro noatime nodiratime
start console
mount ext4 /dev/block/platform/emmc/by-name/metadata /metadata wait noatime nodiratime nosuid nodev noauto_da_alloc,discard
start charger
on property:ro.boot.charger.emmc=0
insmod /rk30xxnand_ko.ko
mount ext4 [email protected] /system wait ro noatime nodiratime noauto_da_alloc
start console
mount ext4 [email protected] /metadata wait noatime nodiratime nosuid nodev noauto_da_alloc
start charger
on charger
setprop ro.boot.charger.emmc 0
export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin
export LD_LIBRARY_PATH /vendor/lib:/system/lib
setprop sys.usb.config adb
So in the init.rockchip.rc file, a service named charger invokes a binary called charger, located at /charger ... I found the source code for this program here: https://gitlab.com/pbeeler/system_core/commit/e4b7b294f37d9b64d6b7c1931e2c9bfb1a500d68
Here is a snippet that I find interesting (Line 830)..
Code:
if (code == KEY_POWER) {
if (key->down) {
int64_t reboot_timeout = key->timestamp + POWER_ON_KEY_TIME;
if (now >= reboot_timeout) {
LOGI("[%lld] rebooting\n", now);
android_reboot(ANDROID_RB_RESTART, 0, 0);
/* We do not currently support booting from charger mode on
all devices. Check the property and continue booting or reboot
accordingly. */
if (property_get_bool("ro.enable_boot_charger_mode", false)) {
LOGI("[%lld] booting from charger mode\n", now);
property_set("sys.boot_from_charger_mode", "1");
} else {
LOGI("[%lld] rebooting\n", now);
android_reboot(ANDROID_RB_RESTART, 0, 0);
}.....
So while I don't entirely understand the order of operation, it seems that when the device is plugged in, the charger service is run (executing the /charger binary) .. this binary detects the power button key, and if pressed, sets the sys.boot_from_charger_mode property to 1. Then the on property event inside the init.rc file is triggered, and then i assume late-init is what boots up the device.
So it appears that the contents of init.rc are available at some capacity, before Android has booted up. But I've tried a few adjustments to these files with no results. One thing I've tried is adding setprop sys.boot_from_charger_mode 1 to init.rockchip.rc's on charger event, or at the top of init.rc and other places.
I've also tried changing /charger to /system/bin/reboot
I've also tried putting trigger late-init under init.rockchip.rc's on charger event too.
When I make these changes and try them on the device, I do check the files to verify the changes had stayed.. and they do.
So now I cannot help but wonder that perhaps I am on the wrong track and that maybe these files aren't actually available before the power button is pushed. Some insight would be greatly appreciated.
Thank you.
Click to expand...
Click to collapse
Reference.
Mi max 3 as car tablet
hello everyone im plan to put a tablet to my car in dashboard, so i searching some informations: - did someone try to use command off-mode-charge to start device when plugged in ? - USB OTG is supported by device ? - is it still worth it in 2020...
forum.xda-developers.com
Have also a look inside here:
Automatically power on Android when the charger is connected
Is it possible to automatically power on the device once the charger is connected given that the device is initially turned off?
android.stackexchange.com
Root your device with Magisk.
Add this lines in init.rc file :
on charger
# class_start charger
exec u:r:magisk:s0 -- /system/bin/reboot