After experimenting for a while, I've managed to successfully use USB 3G dongle, and to connect my Archos 101IT, running uruk-droid 0.4.1, to the Internet over 3G data network. Test was made with two different 3G USB dongles - Huawei E1552 and ZTE MF190.
First of all a big thanks to $aur0n for uruk-droid, because without uruk-droid kernel with adequate configuration, this 3G support would not be possible.
Second, a big thanks to all guys behind usb_modeswitch project (http://www.draisberghof.de/usb_modeswitch/), for providing us with Linux support needed to switch our 3G USB dongles from default cd-rom/mass-storage mode to usb-serial mode needed for 3G operation.
Process of initial setup of 3G USB dongle to a 3G provider under Linux (and Android/Archos) is fairly complex, and requires a little Linux knowledge, but once it is configured right, usage is simple.
Unfortunately I don't see a way to make it simpler, because lot of parameters in various files are greatly dependant on model of 3G USB dongle you are using, and on settings of your 3G data provider.
DISCLAMER:
This is a proof-of-concept modification. Don't expect that everything will work from a first try.
Please note that I don't take responsibility for anything that might happen with your Archos device and/or your data on it.
I didn't had any problems with my A101IT using this mod with Huawei E1552 3G dongle and ZTE MF190 3G dongle, but that doesn't mean that someone else won't have them.
Also, if you make your 3G USB dongle work as modem using steps described here, I don't take any responsibility for possible large bills form you 3G data service provider.
Be sure that you have good and cheap 3G data plan with your 3G data service provider, if you are planning to use 3G data network for Internet connection on a daily basis.
Also, try to avoid using 3G data service while in roaming, because it is very expensive.
Technical explanation:
Basically USB tethering system on Archos is designed to work over PPP connection, provided by /system/bin/pppd via "Serial-over-USB link", provided by cdc-acm.ko kernel module, when supported cdc-acm class device is connected to USB host port of Archos.
Here is a brief description of USB tethering on Archos 101, modified to work with 3G USB dongles, since you probably going to need to edit some of this files in order to adjust them for your 3G USB dongle and your 3G provider:
1. Kernel support for 3G USB dongles.
This is provided by uruk-droid kernel.
One part you'll use from this support is usbserial.ko kernel module that will be loaded by /system/xbin/3Gmodem_init.sh with adequate parameters, when you start tethering.
2. usb_modeswitch program and support files
usb_modeswitch is responsible for switching of 3G USB dongles from default cd-rom/mass-storage mode to usb-serial mode ready for 3G operation.
You'll use it via /system/xbin/3Gmodem_init.sh, when you start tethering.
3. Archos USB tethering support which is partially in Android framework, and partially in Linux scripts called by framework.
This part of tethering support is most complex one, and in order for Android framework to be aware of data connection, we must disguise 3G data connection as a USB tethering:
Android framework calls modified /system/bin/tether_start_usb.sh, which calls /usr/bin/pppd binary, responsible for data connection to your 3G data provider.
Android framework calls modified /system/bin/tether_stop.sh, for stopping data connection to your 3G data provider.
pppd uses couple of configuration files (and additional binary /usr/xbin/chat):
from '/system/etc/ppp/peers' directory, pppd uses configuration file 'tether' (with definition of pppd options for peer it connects to - this may need editing for your 3G provider)
from '/data/' directory, pppd (via /system/xbin/chat) uses 'tether_start' file as definition of <SEND> <EXPECT> pairs of commands sent to configure modem and responses received from modem, when it connects to a peer (this may need editing for your 3G provider).
from '/system/etc/chatscripts/' directory, pppd (via /system/xbin/chat) uses 'tether_stop' file as definition of <SEND> <EXPECT> pairs with commands sent to modem and responses received from modem, when it disconnects from a peer.
This modification relies on modified '/system/bin/tether_start_usb.sh' and '/system/bin/tether_stop.sh', to be able to correctly initialize RNDIS connection or 3G modem, load adequate kernel modules and start connection, while trying to keep compatibility with original "Archos designed" way of USB tethering.
Configured adequatly ('enable' parameter to 'off' in '/etc/uruk.conf/3Gsupport' file), this modified '/system/bin/terher_start_usb.sh' WILL behave as original one. - not needed anymore - scripts auto-detect connection type and behave adequatly.
For a list of changes in recent versions please se post #2 of this thread.
Tutorial how to use RNDIS USB Tethering:
No configuration needed - if your phone is indeed of USB-RNDIS type - everything will be auto-detected.
Just plug your Archos to a RNDIS capable phone in tethering mode via USB cable, wait for at least 5 seconds (or more - depending on phone), and start tethering on Archos.
Expample of RNDIS tethering device is HTC Desire phone with built-in USB Tethering support enabled. Android based phones from "same generation as HTC Desire" are quite probably of same USB-RDNIS type.
NOTE: due to a technical reasons (bad driver), RNDIS tethering support works only if usb host mode driver (musb_hdrc.ko) is loaded in PIO (as opposed to default DMA) mode. When tethering is started, USB host mode driver is reloaded in PIO mode, so this might be indicated on the phone like USB disconnection and re-connection. This is "normal" behaviour, and for now there is nothing I can do about it. When tethering is stopped USB host mode driver is re-loaded again to DMA mode.
Tutorial how to initially configure 3G USB dongle for USB tethering:
NOTE: Everything written here, should be done in Terminal Emulator or ConnectBot (connected as local) under root shell (after 'su' command)!
Install Terminal Emulator, or ConnectBot from Market.
This step is no longer needed if you are running Uruk-Droid 0.7 or later since 3G modem/RNDIS support is integrated in it
Get 3Gsupport-0.4.zip from attachment in this post. Extract 3Gsupport-0.4.tar.gz file from .zip file and copy it to your Archos to /sdcard. Archive contains everything needed (usb_modeswitch binary and support files, replacement tether_start_usb.sh, replacement tether_stop.sh, 3Gmodem_init.sh script, 3Gmodem_detect.sh).
NOTE: Since /system/bin/tether_start_usb.sh and /system/bin/tether_stop.sh from 3Gsupport-0.4.tar.gz will replace original ones, please backup originals.
The 3Gsupport-0.4.tar.gz file contains absolute paths for all files, and should be extracted to a root ('/' path in RootExplorer).
To backup original tether_start_usb.sh and tether_stop.sh:
Code:
# su
# cp /system/bin/tether_start_usb.sh /system/bin/tether_start_usb.sh.ORIGINAL
# cp /system/bin/tether_stop.sh /system/bin/tether_stop.sh.ORIGINAL
Assuming you have 3GSupport-0.4.tar.gz in /sdcard you should do following in Terminal Emulator or ConnectBot to extract 3Gsupport-0.4.tar.gz:
Code:
# su
# cp /sdcard/3Gsupport-0.4.tar.gz /
# cd /
# tar -zvxf 3Gsupport-0.4.tar.gz
Start the Terminal Emulator, or ConnectBot (to localhost).
Issue 'su' command in terminal window to gain root access.
Plug dongle in usb host port (full size USB on A101IT).
NOTE: For A70IT you'll need something called "mini USB Type-A to USB female host cable adapter", and maybe manually loading of host-mode USB driver (musb_hdrc.ko) – I don’t have A70IT so I can’t test.
Wait couple of seconds (at least 5) and then start 3G modem detection script with '/system/xbin/3Gmodem_detect.sh' command.
The output of the detect scripts should be pretty self-explanatory, and if your modem is supported by usb_modeswitch (in both switching and non-switching mode) you should be able to see that usb serial module is loaded and configuration file is written and support for 3G modems is started.
Output should look like this:
Code:
# /system/xbin/3Gmodem_detect.sh
Supported USB device found !!!! VendorID: 12d1 - ProductID: 1446
New VendorID: 12d1
New ProductID not detected in usb-modeswitch config file. Try to detect it later !
Switching device to usbserial mode !
Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
Found devices in default mode, class or configuration (1)
Accessing device 004 on bus 002 ...
Getting the current device configuration ...
OK, got current device configuration (1)
Using endpoints 0x01 (out) and 0x81 (in)
Using endpoints 0x01 (out) and 0x81 (in)
Inquiring device details; driver will be detached ...
Looking for active driver ...
OK, driver found ("usb-storage")
OK, driver "usb-storage" detached
SCSI inquiry data (for identification)
-------------------------
Vendor String: HUAWEI
Model String: Mass Storage
Revision String: 2.31
-------------------------
USB description data (for identification)
-------------------------
Manufacturer: HUAWEI Technology
Product: HUAWEI Mobile
Serial No.: not provided
-------------------------
Setting up communication with interface 0 ...
Using endpoint 0x01 for message sending ...
Trying to send message 1 to endpoint 0x01 ...
OK, message successfully sent
Resetting response endpoint 0x81
Error resetting endpoint: -110
Resetting message endpoint 0x01
Error resetting endpoint: -19
Device is gone, skipping any further commands
Checking for mode switch (max. 20 times, once per second) ...
Searching for target devices ...
Searching for target devices ...
Found target device, now opening
Found correct target device
Mode switch succeeded. Bye.
Detected ProductID of a switched device: 140c
USB device VendorID: 12d1 ProdID: 140c. Probing serial mode
usbserial.ko module registered and /dev/ttyUSB{X} device nodes created sucessfully.
Writing default configuration to '/data/local.prop' file .....Done.
!!! REBOOT your A101IT now in order for your configuration to become active !!!
After reboot:
Disconnect your 3G USB dongle, do not connect anything to USB host port and go to Settings->Wireless & Networks->Cellphone tethering.
If there is tethering profile already defined, delete it - Archos handles only one tethering profile definition at a time.
Create new USB tethering profile.
Your APN, username and password won't be detected automatically, so fill them manually - find adequate info from your 3G service provider (for me on Telekom Srbija: APN is ‘gprsinternet’, username is ‘mts’, and password is ‘064’ (some 3G operators don't need username and password)).
This will create file '/data/tether_start' with adequate commands for ppp daemon to initialize 3G modem and make a connection to your 3G provider.
NOTE for uruk-0.6: It '/data/tether_start' file is not created after wizard finishes try following in terminal emulator:
Code:
su
chown 1000:1000 /data
chmod ug+rwx /data
then delete the tethering profile just created and re-create it again !!! Now everything should be OK.
File should look like this:
Code:
TIMEOUT 5
ECHO ON
ABORT BUSY
ABORT ERROR
ABORT 'NO CARRIER'
ABORT VOICE
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT DELAYED
TIMEOUT 12
'' ATZ
OK AT+CGDCONT=1,"IP","[COLOR="DarkRed"]<your APN configured in tethering wizard>[/COLOR]"
OK ATD*99#
TIMEOUT 120
CONNECT ''
If steps 3 and 4 were OK, then you should be able to test pppd connection to the Internet.
NOTE: This test assumes following:
a) that SIM/USIM card in your 3G modem doesn't require PIN code.
b) that your 3G modem automatically register SIM/USIM to a network in Automatic mode (auto-band, 3G preferred mode (EDGE service if no 3G available))
If this is not a case please take a look in section "Modifying tether_start script" later, for reference how to modify '/data/tether_start' script with adequate AT commands that should be sent to modem.
Re-plug your 3G USB dongle.
Wait at least 5 sec.
Start the Terminal Emulator, or ConnectBot (to localhost).
Issue 'su' command in terminal window to gain root access.
Issue '/system/xbin/3Gmodem_init.sh' command
Issue '/system/bin/pppd /dev/ttyUSB0 460800 debug mtu 1280 mru 1280 name <username> password <password> call tether'
If you get CONNECTED message then your dongle and /dev/ttyUSBx port is set right and everything is configured well.
Output should look like this:
Code:
ATZ
OK
AT+CGDCONT=1,"IP","[COLOR="DarkRed"]<your APN configured in tethering wizard>[/COLOR]"
OK
ATD*99#
CONNECT
You can interrupt pppd with Ctrl+C.
If you don't see CONNECT (or any) response from modem try with one of other ttyUSB[0-5] ports first, or refer to following section on modifying /data/tether_start script.
Assuming the step 5 was success, edit '3Gmod.usbPort' option to match the number you have used in test in step 5, in '/data/local.prop' file, and REBOOT your Archos.
From now you can use 3G USB tethering just by plugging 3G USB dongle, and starting 'Setup->Wireless & Network->Cellphone Tethering->Tether'.
Modifying '/data/tether_start' script for your particular 3G modem and 3G operator:
File '/data/tether_start' is standard chatscript for unix chat program ('man chat' on Google for more info and syntax reference) used by pppd when making connection.
In default tether_start file most important line is one for setting APN: ' OK AT+CGDCONT=1,"IP","<your APN configured in tethering wizard>" ' in example above.
Second important line is one that connects your modem to your 3G data provider: 'OK ATDT*99#' - for some providers it needs to be modified to 'OK ATDT*99***1#'.
If your SIM/USIM card needs PIN in order for you to be able to use your 3G USB dongle, try to disable PIN on your card before using it in 3G USB dongle.
If you can't disable PIN for your SIM/USIM card (for example, as far as I know Tele2 cards must have PIN), you'll probably need to modify 'tether_start' script and to add adequate AT commands and expected responses, before setting APN.
A solid reference of 3G modem AT commands and manufacturer/model specific AT commands can be found these pages:
http://3g-modem.wetpaint.com/page/common+AT-commands
http://3g-modem.wetpaint.com/page/Huawei+AT-commands
http://3g-modem.wetpaint.com/page/ZTE+AT-commands and
http://3g-modem.wetpaint.com/page/Sierra+Wireless+AT-commands
Example /data/tether_start script that sends PIN 1234 and sets "auto 3G/GPRS mode" (for Huawei 3G USB dongles only !!!) looks something like this:
Code:
ABORT 'BUSY'
ABORT 'NO CARRIER'
ABORT 'VOICE'
ABORT 'NO DIALTONE'
ABORT 'NO DIAL TONE'
ABORT 'NO ANSWER'
ABORT 'DELAYED'
REPORT CONNECT
TIMEOUT 6
'' ATQ0
OK-AT-OK ATZ
TIMEOUT 3
OK AT+CPIN=1234
OK-AT-OK ATI
OK ATZ
OK ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
OK AT\^SYSCFG=14,2,3fffffff,0,1
OK-AT-OK AT+CGDCONT=1,"IP","<your APN configured in tethering wizard>"
OK ATDT*99***1#
TIMEOUT 30
CONNECT ''
There is a plenty of information on the Internet on how to configure Linux ppp chatscripts for particular models of 3G USB dongles and 3G operators, so please SEARCH, READ & TRY before asking, since you'll have to try it anyway at the end .
ISSUES:
First start of tethering after plugging, re-plugging 3G USB dongle or stopping tethering can (and probably will) end in "unable to connect by tethering" message.
This happens since dongle needs to be switched to usb-serial mode, kernel modules must be loaded, and most important 3G dongle must register to 3G data network to be able to connect, and Android framework timeout before connection is established.
Solution is to just start tethering again, and since there is no need to do a usb_modeswitch again, and kernel modules are already loaded, and dongle is registered to 3G network provider, it will connect before timeout.
When Archos wakes-up after sleep, some dongles (ZTE-MF190 is one of them), wake-up in default mode (non usb-serial mode), so tethering needs to be stopped and started manually.
One possible workaround is to enable "Prevent device from going to sleep" in 'Setup->Wireless & Network->Cellphone Tethering', but with uruk-droid 0.4.1 based on Archos 2.0.x firmware this option didn't work as expected - device still goes to sleep, even if tethering is connected.
With 2.1.x based uruk-droid (0.6 is first) it seems that this option works.
QUESTIONS & ANSWERS:
Q: Can I use my phone and 3G modem whithout reconfiguring tethering every time I switch them ?
A: Please take a look in this post
FUTURE PLANS:
Integration of real USB-cable tethering with Android based devices that require Archos to tether using usbnet.ko module via "Ethernet-over-USB" type of link. - DONE
Change log:
0.4.1 - Integrated in UrukDroid-0.7 with minor script errors corrected, tutorial updated
0.4 - RNDIS (Ethernet-over-USB) tethering merged with 3G modem, and Archos default USB tethering support this version needs UrukDroid-0.6 at least
changed scripts, in order to acheive auto-detection of tethering type (RNDIS, 3G modem or Archos default Serial-Over-USB)
changed location of saved 3G modem configuration data to /data/local.prop, so the configuration data is avalible upon reboot as Android properties (/data/local.prop file is NOT overwritten by 3Gmodem_detect.sh, so don't worry ;-) )
elimninated need for /etc/uruk.d service, because of previous changes
0.3 - lot of changes in scripts, in order to make 3Gdongle detection and module load configuration simplier.
/system/xbin/3Gmodem_detect.sh introduced for purpose above
tutorial changed to follow 3Gmodem_detect.sh usage
compatible with 3G USB dongles that don't need switching (like Huawei E176)
wokring on uruk-0.6RC2
0.2 - changes to '/system/etc/uruk.d/3Gsupport' script to conform to urukdriod 0.5 standard
'/system/etc/uruk.d/3Gsupport' script now supports (beside start and stop): status, UIstatus and config parameters as well as second parameter force
no other functional changes
working on urukdroid 0.5 and 0.4.1
0.1 - Initial release tested on urukdroid 0.4.1 and 0.5
Here is the list of 3G modems and providers confirmed to work and optional notes if '/data/tether_start' needed to be altered:
1. Huawei E1552 on MTS Serbia (APN: gprsinternet, U: mts, P: 064) and VIP Serbia (APN: vipmobile, U: vipmobile, P: vipmobile)
2. Huawei E1550 on MTS Serbia (APN: gprsinternet, U: mts, P: 064) and VIP Serbia (APN: vipmobile, U: vipmobile, P: vipmobile), and on Starhub (Singapore) (APN as shinternet no U: and no P
3. ZTE MF190 on MTS Serbia (APN: gprsinternet, U: mts, P: 064) and VIP Serbia (APN: vipmobile, U: vipmobile, P: vipmobile)
4. Huawei E173 on MTS Serbia (APN: gprsinternet, U: mts, P: 064) and VIP Serbia (APN: vipmobile, U: vipmobile, P: vipmobile)
5. Huawei E176 on unknown 3G provider/params
6. Huawei E1691 on Wind Mobile in Canada 3G provider and unknown params, but with configuration file change described in this post
7. Huawei E153 on unknow 3G provider/params
Here is the list of phones with RNDIS USB tethering, confirmed to work:
1. HTC Desire (stock 2.29.405.2 with built-in USB Tethering support enabled)
2. US HTC HD2 running a Desire-based NANDroid ROM on T-mobile (APN: epc.tmobile.com, no U: , no P: )
awesome, will have to try this out on my tmobile web and walk III stick later.
Thanks for this very well done explanation ! I'll try on my 70
solune said:
Thanks for this very well done explanation ! I'll try on my 70
Click to expand...
Click to collapse
Note that you'll probably need microUSB-Type A to USB host cable adapter in order to use 3G USB modem dongle.
I really don't know does Archos 70IT automaticaly unload's clinet mode usb driver, and loads host-mode driver when you plug in microUSB host adapter cable (it should do it - that is one of reasons why host cable has one pin more), but if it doesn't you'll have to load musb_hdrc.ko module in manually.
I think that it must be loaded with parameter mode_default set to 1 in order to activate host mode ('insmod /lib/modules/musb_hdrc.ko mode_default=1').
great it is a good news
but no simply
how the merge on UrukDroid
nenadr said:
Note that you'll probably need microUSB-Type A to USB host cable adapter in order to use 3G USB modem dongle.
I really don't know does Archos 70IT automaticaly unload's clinet mode usb driver, and loads host-mode driver when you plug in microUSB host adapter cable (it should do it - that is one of reasons why host cable has one pin more), but if it doesn't you'll have to load musb_hdrc.ko module in manually.
I think that it must be loaded with parameter mode_default set to 1 in order to activate host mode ('insmod /lib/modules/musb_hdrc.ko mode_default=1').
Click to expand...
Click to collapse
Yes I already have microUSB-Type A to USB Host cable adapter, and it works for my USB drive for example. I've already connected my 3G USB modem dongle just for see what's appen, and light blink on it, so I have hope to do something with your very well explained guide
I'll make feed-back here if host-mode driver loads or if I need to mount it manually.
cajl said:
great it is a good news
but no simply
Click to expand...
Click to collapse
I know it is not simple but it is try-error only until your connection is succesfull for a first time (while you fine tune params for your 3G modem, and for your 3G operator). After that is just metter of sticking 3G USB dongle, waiting 5 seconds, and clicking Tethering on Power Widget (twice )
cajl said:
how the merge on UrukDroid
Click to expand...
Click to collapse
I'll hopefully upgrade to uruk 0.5 today, and adapt scripts (mainly uruk-config ones), to 0.5 version of uruk-droid during the weekend, and post those scripts here.
After that my plan is to upgrade to a uruk-0.6RCx and play with USB cable tethering with Android phones that tether via "Ethernet-over-USB" support (usbnet.ko module).
Hopefully, I will know soon enough if that is operational, and after that I'll talk to $aur0n about integration.
solune said:
Yes I already have microUSB-Type A to USB Host cable adapter, and it works for my USB drive for example. ......
Click to expand...
Click to collapse
If it works with USB drive, that should be proof enough that Archos 70IT is switching to USB host mode just by plugging microUSB host adapter. Good news, more devices supported....
solune said:
I'll make feed-back here if host-mode driver loads or if I need to mount it manually.
Click to expand...
Click to collapse
Please do, thank you very much.
i'm up to step 6 . it was pretty clear up to then. a) i dont have a 3Gsupport.conf file in there b) i guess the bit in the [code ] box isnt what you need to do to edit it c) presuming you mean just open the 3Gsupport file and edit that, am i just replacing all instances of vendor and product or also the VendorID /ProductID bits too?
thefunkygibbon said:
i'm up to step 6 . it was pretty clear up to then. a) i dont have a 3Gsupport.conf file in there b) i guess the bit in the [code ] box isnt what you need to do to edit it c) presuming you mean just open the 3Gsupport file and edit that, am i just replacing all instances of vendor and product or also the VendorID /ProductID bits too?
Click to expand...
Click to collapse
Yup I've made a mess in that part of tutorial (wrong path/name of config file, not clear enough explanation):
You have to edit file '/system/etc/uruk.conf/3Gsupport' and it should look something like:
service_enabled=1
enable=on
vendor=12d1
product=1446
port=0
I've corrected that part of initial post. Thanks.
Pictures of this "exploit"
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I've good news for Huawei E176 user, The modem doesn't require to switch mode.
So we just only need to edit ther_usb start and stop .sh
and here is the code for E176
/system/bin/tether_start_usb.sh
Code:
#!/bin/sh
# $1 is the user (not a mandatory argument)
# $2 is the password (not a mandatory argument)
setprop "3Gmod.enable" "on"
setprop "3Gmod.defVendorID" "12d1"
setprop "3Gmod.defProductID" "1003"
setprop "3Gmod.usbPort" "0"
rmmod usbserial
sleep 1
insmod /lib/modules/usbserial.ko vendor=0x12d1 product=0x1003
sleep 1
SUPPORT3G=`getprop "3Gmod.enable"`
VENDOR3G=`getprop "3Gmod.defVendorID"`
PRODUCT3G=`getprop "3Gmod.defProductID"`
PORT3G=`getprop "3Gmod.usbPort"`
if [ ${SUPPORT3G} != on ]; then
insmod /lib/modules/musb_hdrc.ko mode_default=1
insmod /lib/modules/cdc-acm.ko
if [ $# -eq 0 ]
then
/system/bin/pppd /dev/ttyACM0 460800 call tether
else
/system/bin/pppd /dev/ttyACM0 460800 name $1 password $2 debug call tether
fi
else
if [ $# -eq 0 ]; then
/system/bin/pppd /dev/ttyUSB${PORT3G} 921600 call tether
else
/system/bin/pppd /dev/ttyUSB${PORT3G} 921600 name $1 password $2 call tether
fi
fi
/system/bin/tether_stop.sh
Code:
#!/bin/sh
SUPPORT3G=`getprop "3Gmod.enable"`
if [ $1 = "DUN" ]
then
/system/xbin/dund --killall
elif [ $1 = "PAN" ]
then
/system/bin/pand --killall
else
if [ ${SUPPORT3G} != on ]; then
kill -9 $(pidof pppd)
/system/bin/rmmod cdc_acm
/system/bin/rmmod musb_hdrc
else
killall -15 pppd
fi
fi
Meen said:
I've good news for Huawei E176 user, The modem doesn't require to switch mode.
So we just only need to edit ther_usb start and stop .sh
and here is the code for E176
Click to expand...
Click to collapse
Thanks for the info on Huawei E176. I'll make some chaneges in original scripts, for those users that have modems that don't require switching, to be able to use original scripts. It'll be in 0.3 in next day or so.
cajl said:
Pictures of this "exploit"
Click to expand...
Click to collapse
could you please post some bigger pictures? I'm not sure its big enough for people to see.
ok nenadr, I'll try the rest of the process tonight cant wait to try it. have you managed to get an idea of the sort of battery drain using one of these? ie is it much worse than using wifi?
I'm getting the following on step 7 . I am using uruk 0.5 I it makes any difference
/system/xbin/3Gmodem_init.sh 12d1 1003
No 3G USB dongle support detected. Will try to initialize modem.
Found USB 3Gmodem dongle in default mode connected to device. Starting modeswitch.
ERROR: Module option does not exist in /proc/modules
ERROR: Module usbserial does not exist in /proc/modules
ERROR: Module usb_storage does not exist in /proc/modules
Looking for target devices ...
No devices in target mode or class found
Looking for default devices ...
No devices in default mode found. Nothing to do. Bye.
sh: 1003: unknown operand
Found new Product ID: 0002
1003
0001
0a19 for Vendor ID: .
Loading 3G modem kernel driver with adeqate configuration
insmod: error inserting '/lib/modules/usbserial.ko': -1 Invalid parameters
Kernel module load failed. Exiting.
#
thefunkygibbon said:
I'm getting the following on step 7 . I am using uruk 0.5 I it makes any difference
Click to expand...
Click to collapse
Please, take a look couple of posts up, for an alternate solution, because it seems that your vendorID and productID doesn't need mode-switching. I'll fix the scripts, and tutoral for that case tomorrow.
Sent from my A101IT using Tapatalk
lol. oh yeah. sorry. i didnt know mine was a E176 and as such i skimmed over those posts sorry for appearing to be a bit of a idiot. cant wait for the new script.
btw has $auron shown any interest in incorporating this into his rom. would be useful to have all the legwork done automatically and maybe urukconfig could do some of the stuff that isnt able to be done automatically
thefunkygibbon said:
btw has $auron shown any interest in incorporating this into his rom. would be useful to have all the legwork done automatically and maybe urukconfig could do some of the stuff that isnt able to be done automatically
Click to expand...
Click to collapse
yes, his shown interest but this code is stll not mature (and tested on) enough devices to be merged with uruk.... meybe for some later urukdroid, who knows
Sent from my A101IT using Tapatalk
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
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.