FYI, I don't have a Nexus 5, but I've been following the Android L news for the past few weeks and have yet to see any reports on the battery historian developer tool. I'm really curious to see detailed battery usage reports for apps that are known to cause frequent wakeups from deep sleep (e.g. facebook). From what I can tell, you need 3 things to use this tool:
1.) adb
2.) The actual Python script: https://raw.githubusercontent.com/google/battery-historian/master/historian.py (just right-click and "Save as" to the directory from which you run 'adb')
3.) Also need to install Python 2.7 on your system (for Window users): https://www.python.org/download/
4.) Obviously, a browser to view the generated html.
There are some comments at the beginning of historian.py script that describe how to generate the required data with adb. Note for Windows users: open up the file in Wordpad, not Notepad.
Also for Windows users: assuming you have installed Python 2.7 in c:\Python27, use the following command line to run the script:
c:\Python27\python.exe historian.py [OPTIONS] [FILE]
Also note that this tool is NOT part of the built-in Android battery settings/stats and there is no native Android UI for it. It is meant to be a developer tool. However, this doesn't mean that users with access to 'adb' can't play with it...
I manage to get this work...even i have no idea about development...
First it need python 2.7 not 3.4
After that you have to mix some commands from the OT and the info inside the .py file...so what i do
After installing python 2.7 i use the command to get a bugreport from the phone...
Code:
adb bugreport > bugreport.txt
then i use the OT command to make the bugreport to an html file with a bit of change
Code:
c:\Python27\python.exe historian.py -a bugreport.txt > battery.html
Thats it...now..i don't know if it has the correct data...im just achived the html look of what we saw on I/O
I think first you need to use this command
Code:
adb shell dumpsys batterystats --enable full-wake-history
To let the phone start dumping stats...and then after some use time to gather the bugreport from your phone....anyone with better knowlage im sure it will figure it out!!!
On the attachment i use the command
Code:
adb shell dumpsys batterystats --reset
to reset my values cause im not using my L rom...
Oh btw this will work only on L....
I can't use "--enable" option.
I can't use this command.
Code:
adb shell dumpsys batterystats --enable full-wake-history
Please tell me how to use "--enable" option.
My phone is Android4.4.2.
("--enable" option is Android "L" only ??)
k-matoo777 said:
I can't use this command.
Code:
adb shell dumpsys batterystats --enable full-wake-history
Please tell me how to use "--enable" option.
My phone is Android4.4.2.
("--enable" option is Android "L" only ??)
Click to expand...
Click to collapse
This is only for Android L.
thomase00 said:
This is only for Android L.
Click to expand...
Click to collapse
How is it that we are a month after Google I/O, and no one with Android L has played with this yet?
IMHO, this is one of the most important new features.
Yep, i think this is the most recent problems the two guys from project Volta have. They have to be rely on the help of the programmers which develop the software.
Daimonion1980 said:
Yep, i think this is the most recent problems the two guys from project Volta have. They have to be rely on the help of the programmers which develop the software.
Click to expand...
Click to collapse
They have to rely on Developer to use JobScheduler API but not for finding you bad apps that are killing the battery. And to that effect, those guys are doing a terrible job with a botched tool.
It's amazing how there is NOTHING on the Internet about the Battery Historian tool. It's like no one has used it. In my case, I can't get the command to builds the html file from the bugreport. It keeps giving me a invalid html error.
Yep, I did ask chamonix from BBS if he can use the generated stats and he will take a look into it. I hope he will do it in the near future.
Using battery historian
After playing with this for a while I've figured out how to use the basic function (this is part of project volta, so it will only work on Android 5.0+)
enable full wake history and then output your batterystats to a text file
./adb shell dumpsys batterystats --enable full-wake-history
./adb shell dumpsys batterystats > batterystats.txt
navigate to wherever you placed historian.py and output the data to a html file (you need python 2.7)
./historian.py [location of batterystats.txt] > batterystats.html
open the batterystats.html file and you're done! For basic use at least. I'm still figuring out the rest myself.
So after having problems on lollipop with mobile radio active bug (https://code.google.com/p/android/i...id&colspec=ID+Type+Status+Owner+Summary+Stars)
i managed to get an dump from battery historian. But at the moment a see not the culprit in my log. The only thing i see is that my device although it was not heavily used this morning has a tons of wakelocks.... and an running par between 10:45 and 10:55 where i don't know it's coming from......
Have a look at it:
http://picture-diamonds.de/private/Thomas/Dumpsys.html
Is anyone able to interpret this chart?
I finally got 5.1 on my Verizon Moto X (1st gen). One of the first things I did was collect battery stats and run Battery Historian 2.0. The following guide was very helpful in getting this set up on Windows 7:
http://ph0b.com/battery-historian-2-0-windows/
Anyway, it turns out that while sitting untouched on my desk at work, the phone pretty consistently wakes up about once per minute (only for a second or 2), with the partial wakelock held by GOOGLE_SERVICES. Most of the time, it seems to be related to location reporting. This doesn't sound like a lot, but I think there is a relatively big cost associated with powering the up and down.
Other than location, the ONLY reason I can think of for waking up the phone periodically is for TCP keep-alive (to keep GCM push notifications working), but once per minute seems kind of excessive even for that. My theory is that there is an app using the Google Play Services Geofencing API, and I just happen to be parked near a geofence boundary. According to my understanding, the Google geofencing service adjusts location polling frequency according to your distance from a geofence. If I am correct, the problem is that it is not smart enough to understand that you are stationary and therefore avoid excessive polling.
I'll try to collect more stats from different locations.
I'm sure this ground has been tread before...
thomase00 said:
I finally got 5.1 on my Verizon Moto X (1st gen). One of the first things I did was collect battery stats and run Battery Historian 2.0. The following guide was very helpful in getting this set up on Windows 7:
http://ph0b.com/battery-historian-2-0-windows/
Anyway, it turns out that while sitting untouched on my desk at work, the phone pretty consistently wakes up about once per minute (only for a second or 2), with the partial wakelock held by GOOGLE_SERVICES. Most of the time, it seems to be related to location reporting. This doesn't sound like a lot, but I think there is a relatively big cost associated with powering the up and down.
Other than location, the ONLY reason I can think of for waking up the phone periodically is for TCP keep-alive (to keep GCM push notifications working), but once per minute seems kind of excessive even for that. My theory is that there is an app using the Google Play Services Geofencing API, and I just happen to be parked near a geofence boundary. According to my understanding, the Google geofencing service adjusts location polling frequency according to your distance from a geofence. If I am correct, the problem is that it is not smart enough to understand that you are stationary and therefore avoid excessive polling.
I'll try to collect more stats from different locations.
I'm sure this ground has been tread before...
Click to expand...
Click to collapse
Thanks for sharing ph0b's work here with Battery Historian.
Related
Not using Tasker? Shame on you… Download your free trial here
The debate about whether or not to use an automatic task killer in Android is for another thread. The general consensus seems to be ‘don’t’, but regardless, we all have them in case of troublesome processes (even if you can long-press the back button) and therefore I’ve produced this tutorial to show you how to use Tasker to create one that you can configure how you wish, should you wish!
If nothing else, there’s a few good Tasker tips in here, that I’m sure will come in handy for your other profiles.
Let’s get on with it!
Preparation
For best practice, testing and understanding, you’ll need:
1) A Terminal Emulator
2) A Task Killer (!)
3) The Locale Execute Plug-in for Tasker (make sure this is installed prior to importing the profile)
4) A speech engine – Pico TTS for example.
The Short Winded Tutorial
It kills sh*t loads of processes.
Proceed to the download!
The Long Winded Tutorial
Import the profile and ‘un-tick’ it to make sure it is not active until you have edited it to suit your needs.
The trigger for this profile is time based and set up as standard to run every 30 minutes between the times you are likely to be using your phone. Be sure that the activation time does not match that of your AutoSync Profile that you may/should/could be using from here, or otherwise how often your standard email and widgets sync with their individual settings – you don’t want those processes being killed mid-sync.
In this profile, Tasker will use Linux commands via the Locale Execute Plug-in to kill processes you have specified. Let’s get familiar with them.
Open up the Terminal Emulator and type:
Code:
su
then:
Code:
ps
The current running processes will be listed. You’ll note that all applications you would want to kill are assigned a process ID (PID) and an application number app_** (listed under 'User'). The application process (process name) is listed at the end, such as com.android.google.browser.
A process can be killed using its corresponding PID. Try it with an application you see in the list (NOT A SYSTEM PROCESS!):
Code:
pkill 3456
Unfortunately, the PID changes and therefore is not a constant we can use to terminate applications. We therefore have to focus on the process name – bbc.iplayer.android for example.
Try killing an application by name (open it first, list the processes again to make sure it’s there and then see if it has gone afterwards by listing processes again):
Code:
pkill com.google.android.youtube
Sometimes a process is persistent and needs further encouragement (execution) to die:
Code:
pkill -9 com.facebook.katana
Sometimes a process refuses to die – this can be because there are other processes associated with it that are not killed by the above.
Code:
Killall -9 com.levelup.beautifulwidgets
That’s the process killing commands lesson complete and only leaves us with one small issue = What if you are using the process at the time? Obviously we don’t want the browser killed if you are in the middle of surfing, so we have to use a variable to make certain of this. The chosen built in variable is %LAPP, which is the last foreground application used. By making sure this isn’t killed, it’ll stop your current program being terminated in the middle of a message to someone! Therefore, each separate action to kill a process has an IF statement included to prevent the termination if that application is currently being used.
There are plenty of examples in the profile for you to use, but of course you’ll want to add your own entries in the KillProcesses task by:
+
Plugin
Execute
Edit
And then type (or even better paste):
@! pkill -9 and then the process name* (@! Stops the commands appearing on the screen)
Press the back button to save
Click IF
%LAPP
Click ‘~’ select ‘doesn’t match’
Enter the application name**.
Done
* The process name can be found and noted in the Terminal Emulator. Alternatively, often the process names are listed in the Task Manager you are already using.
** In the profile, there is a speech task, popup notification and a STOP task, these are there to discover the correct application name. Open the application you want to add to the list, long hold the home button and select Tasker and then press ‘test’. Tasker will say the name of the application and show how it is spelt on the screen. If the speech says ‘Launcher’, you may need to navigate back to Tasker (after opening the desired app) via the notification bar.
Copying all of the process names and completing the IF statements can be a little tedious, but when it’s done, it’s done… Test each new action to ensure the application is actually killed – just drag it above the STOP action. The Super User application may request permission first time (for each application command). Go to your current Task Manager, refresh it and check the application was terminated! If it wasn’t, try the ‘killall -9’ command detailed above. I have to use this for Beautiful Widgets and Titanium Backup as they are stubborn (and return again soon).
When you've completed your list, delete the pop-up, speech and stop actions and you're good to go.
Finally, it couldn’t be easier to create a widget for the home-screen to activate KillProcesses whenever you like. Hold down somewhere on the home-screen, select widgets. Select Tasker. Select Task. Select KillProcesses. Select your icon and hit ‘make widget’! Done!
There you have it! Your very own self created task murderer at the touch of a button!
Enjoy!
Shortfalls
You are unable to kill a troublesome process if it’s not in your task list!
Future Inclusions?
When setting this up, I had Locale write the process list to a text file. In theory it is possible to get Tasker to read this file, dissect it and therefore discover by the constant app_** which tasks are running and place the process name in a variable which then could be exported to Locale to kill (I think). This is waaay too much effort, but have a go if you want!
In addition, Tasker could compare the before and after (kill) process list and work out approximately how many applications it killed, displaying the number in a popup notification. Again, effort – go for your life!
At present a notification is displayed showing the last time it murdered something.
Please let me know if you have any sensible requests and your feedback is always welcome!
Installation Instructions
In menu options/profile data 'Import One Profile':
Task_Manager
The thanks meter lets me know I'm appreciated!
Feedback?!
There have been a few downloads of this now... but no comments!
Do I assume that it works absolutely fine? No errors or anything? If so, I'll stick it on the Tasker Wiki for educational purposes.
Wow! But how about use Locale AutoKill Plug-in ? It works for me with 2.2 Froyo. So much easier )
memberfive said:
Wow! But how about use Locale AutoKill Plug-in ? It works for me with 2.2 Froyo. So much easier )
Click to expand...
Click to collapse
For education purposes
Sent from my HTC Desire using XDA Premium App
brandall said:
For education purposes
Click to expand...
Click to collapse
Well. In this case, suggest another simple solution, without the use of additional fee applications.
1) Connect your phone via USB.
2) Do adb shell and then ps to remember the last lines.
3) On your phone start the unnecessary application, again execute ps
and see the process name (like android.process.media) after the last lines.
4) Add it to the killing list (say kill_list.txt): echo android.process.media>>/sdcard/kill_list.txt.
5) Repeat for all the unnecessary applications.
6) In the Locale Execute Plug-in is only one line: @! /system/xbin/cat /sdcard/kill_list.txt | /system/xbin/xargs -n1 /system/xbin/killall
memberfive said:
Well. In this case, suggest another simple solution, without the use of additional fee applications.
1) Connect your phone via USB.
2) Do adb shell and then ps to remember the last lines.
3) On your phone start the unnecessary application, again execute ps
and see the process name (like android.process.media) after the last lines.
4) Add it to the killing list (say kill_list.txt): echo android.process.media>>/sdcard/kill_list.txt.
5) Repeat for all the unnecessary applications.
6) In the Locale Execute Plug-in is only one line: @! /system/xbin/cat /sdcard/kill_list.txt | /system/xbin/xargs -n1 /system/xbin/killall
Click to expand...
Click to collapse
Do you mean 'fee' applications? It only uses locale which is free??
I originally messed with the idea of using a list like this, but the problem is, you can't pass the %LAPP variable in this way. I had Tasker/locale writing the original .txt file from ps output and getting Tasker to try and 'read line/find' the associated %LAPP process in order to exclude it from the list prior to the xargs command being executed... but it became more complicated than just listing IF actions individually as I was going to have to list them anyway!
Hope that made sense? If you can think of a betterway to exclude the foreground process and then use a single command in this way, please do let me know!
Sent from my HTC Desire using XDA Premium App
brandall said:
Do you mean 'fee' applications? It only uses locale which is free??
I originally messed with the idea of using a list like this, but the problem is, you can't pass the %LAPP variable in this way. I had Tasker/locale writing the original .txt file from ps output and getting Tasker to try and 'read line/find' the associated %LAPP process in order to exclude it from the list prior to the xargs command being executed... but it became more complicated than just listing IF actions individually as I was going to have to list them anyway!
Hope that made sense? If you can think of a betterway to exclude the foreground process and then use a single command in this way, please do let me know!
Sent from my HTC Desire using XDA Premium App
Click to expand...
Click to collapse
I mean, this solution is just for the Tasker with free Locale Execute Plug-in !
I think that any attempt to pass variables in Tasker and process them would increase the CPU load and reduce performance. It seems to me that there is no difference as to kill the process. And everything works (killed) fine with a single command.
memberfive said:
I mean, this solution is just for the Tasker with free Locale Execute Plug-in !
Click to expand...
Click to collapse
Thought so!
I think that any attempt to pass variables in Tasker and process them would increase the CPU load and reduce performance.
Click to expand...
Click to collapse
Agreed - It was becoming more complicated than an actual Task Killer!
It seems to me that there is no difference as to kill the process. And everything works (killed) fine with a single command.
Click to expand...
Click to collapse
Only problem is with it killing the current application you are using....... Need a solution to prevent that....
Ok, been browsing the web and found these nice profiles, which can trigger an app (Fast Reboot - which acts like a virtual reboot, closing all apps). What do you think about it Brandall? Could it be tweaked even more to get a nice profile using this app? Thanks.
Published by James.
Display- Battery Saver
The initial idea came from some members on the LG2X MoDaCo Forum. The problem at the time was various applications were misbehaving and not stopping when the phone should have been going into its sleep mode. One member suggested using Fast Reboot to ‘reset’ the phone into a state where it can enter sleep mode.
The context:
Event: Display Off
The task:
Wait [ Seconds:11 ]
Stop If [ %SCREEN ~ ON ]
Load App [ App:Fast Reboot Data: Exclude From Recent Apps:On]
The wait is to allow my phone to lock (10 seconds after screen off) then if the phone has been used again the second part should cancel the task #this has limited success if you know a better way to about a task please get in touch!#. Fast reboot unlike many task managers closes and restarts your tasks so your alarms and other app keep working.
Further Improvements
I have added two more complimentary profiles to control when the above profile can run.
Profile: Display- Phone Idle
Event: Phone Idle
Task: Profile Status [ Nameisplay- Battery Saver Set:On]
and
Profile: Display- Phone Offhook
Event: Phone Offhook
Task: Profile Status [ Nameisplay- Battery Saver Set:Off]
These stop the Display- Battery Saver profile from running when the phone is in use. Again, they may not been the most effective solution but they work.
Click to expand...
Click to collapse
mi3x said:
Ok, been browsing the web and found these nice profiles, which can trigger an app (Fast Reboot - which acts like a virtual reboot, closing all apps). What do you think about it Brandall? Could it be tweaked even more to get a nice profile using this app? Thanks.
Published by James.
Click to expand...
Click to collapse
I'd say this is a little excessive... Using a hot/fast reboot as it is known is not addressing the actually issue of misbehaving applications...
For Tasker users, this can be done using Deep Sleep Detective - for other users, this can be done with Better Battery Stats.
Hot/Fast reboot resets the system without rebooting the kernel and is only really necessary when system changes such as remapping hardware keys need to be applied without the need for a full and time-consuming reboot...
Best to track down a problem and resolve it rather and kill everything which this solution does... If a rouge application or process starts at screen-off, then this will happen eventually/immediately after a reboot, so again, a little drastic for short term 'relief'.
The hot reboot is used in my Tasker media mapping profiles though!
I want to kill the backup service that saves data from apps in the cloud and start the service later (when charging) again.
I think it is android alarms: act=android.app.backup.intent.RUN isn't it?
How can I do that?
Thanks in advance!
MaluNoPeleke said:
I want to kill the backup service that saves data from apps in the cloud and start the service later (when charging) again.
I think it is android alarms: act=android.app.backup.intent.RUN isn't it?
How can I do that?
Thanks in advance!
Click to expand...
Click to collapse
This is entirely possible in theory, however killing the service once does not guarantee that it will not start again and again when it feels like it... There is no monitor within Tasker to alert you when it starts...
If there was....
Sent from my Sensation using xda premium
So could you help me with that for the backup service? Or enable/disable toggle?
Thanks.
brandall, I need some help here, please help me out.
I want the following thing:
Everytime I turn internet (easy) some apps services would be launched, like viber/whatsapp/facebook/gmail runing in background as they already do, and when I turn off the internet, I want to kill those process and services...
how can I do that?
pkill -9 and kill-9 arent killing com.whatsapp for example.
MaluNoPeleke said:
So could you help me with that for the backup service? Or enable/disable toggle?
Thanks.
Click to expand...
Click to collapse
Sorry, I didn't see your reply. It's not possible unless the process is obvious when you type 'ps' in the terminal - you can try manually killing it then and see if it comes back. Let me know if you find it and I'll talk you through how to kick off the intent with Tasker.
Sent from my HTC Sensation XE with Beats Audio using xda premium
brunoshady said:
brandall, I need some help here, please help me out.
I want the following thing:
Everytime I turn internet (easy) some apps services would be launched, like viber/whatsapp/facebook/gmail runing in background as they already do, and when I turn off the internet, I want to kill those process and services...
how can I do that?
pkill -9 and kill-9 arent killing com.whatsapp for example.
Click to expand...
Click to collapse
Hi, don't forget that Android is supposed to handle these processes so they don't use any cpu and remain dormant, however, I understand that sometimes it just feels better if they are not there... (although others would tell you that killing apps may make your device under-perform!)
Anyway, killall -9 com.whatsapp will kill the process, but testing it on my device, it restarted almost instantly.
I have the application system tuner pro by 3c an amazing app and under the apps tab there is a 'startup' option for applications which I assumed referred to at boot - I just unticked whatsapp in there, killed the process and then it didn't restart... Maybe a coincidence, but worth a try...
I've no idea what different events in Android cause these apps to decide to come to life...
Hope that helped!?
Sent from my HTC Sensation XE with Beats Audio using xda premium
brandall said:
Hi, don't forget that Android is supposed to handle these processes so they don't use any cpu and remain dormant, however, I understand that sometimes it just feels better if they are not there... (although others would tell you that killing apps may make your device under-perform!)
Anyway, killall -9 com.whatsapp will kill the process, but testing it on my device, it restarted almost instantly.
I have the application system tuner pro by 3c an amazing app and under the apps tab there is a 'startup' option for applications which I assumed referred to at boot - I just unticked whatsapp in there, killed the process and then it didn't restart... Maybe a coincidence, but worth a try...
I've no idea what different events in Android cause these apps to decide to come to life...
Hope that helped!?
Sent from my HTC Sensation XE with Beats Audio using xda premium
Click to expand...
Click to collapse
they may not use cpu but for sure they use battery =/
brunoshady said:
they may not use cpu but for sure they use battery =/
Click to expand...
Click to collapse
It's not my understanding, but I have been wrong before
Did what I suggested stop it restarting??
kill service
I would like to kill a service using this method
I can find the service I want in android service list, it's called "RTService"
How can I find the text to put before "pkill" ?
In terminal emulator and "ps", I didn't find anything related to this and of course "pkill RTService" does nothing ^^
Thanks!
So, looks like we have Carrier IQ on our phones, thanks to AT&T. Any luck on getting a 3rd party ROM on here yet? Any estimates as to when?
Can you give us more information? like how you found it on the phone, what steps did you take?
With more info, those of us in the know can figure out how to disable it, or remove it, without having to resort to waiting for a rom.
I have been looking for it for quite some time without much luck.
It's the device health app.it calls the ciq agent . Easily frozen.
Sent from my MB865
mtnlion said:
It's the device health app.it calls the ciq agent . Easily frozen.
Sent from my MB865
Click to expand...
Click to collapse
Thanks, I will see what else I can come up with for the ciq agent, maybe a way I can fake it out on the *NIX side of the house.
Yep first thing I went looking for after I got root.
Bloat freezer. It's free, finds it fast. When you freeze device health it doesn't want to close and keeps force closing, just reboot, it will be frozen and not running.
Douchewithaphone said:
Bloat freezer. It's free, finds it fast. When you freeze device health it doesn't want to close and keeps force closing, just reboot, it will be frozen and not running.
Click to expand...
Click to collapse
Must be rooted.
Sent from my mAtrix2!!
Well, I have found a way from the UNIX end to stop this thing in it's tracks, but it is not pretty for those unfamiliar with command line....
What we have to do is uncompress the kernel image in the boot.img remove the sys.DeviceHealth from the init.rc file there, then compress the kernel back up, all using cpio.... now to see if I can possibly make it work, and not brick any phones in the process, maybe I can throw a quick apk together next week.
I have tried the bloat freezer and the android assistant and I can still find the sys.DeviceHealth running on the UNIX side with the ps command, so this is a nasty one.
I will keep you guys posted, If I can find a better way.
Here is the link I saw, and how I figured out where sys.DeviceHealth is starting from.
For those interested ONLY. PLEASE do not try this yet, give me some more time to play with this in an emulator and see what I can come up with.
I am just sharing information at this time. BTW Zygote is the process that is calling the sys.DeviceHealth on the Atrix 2.
To see this Do the following from the terminal emulator app on your phone or though adb shell.
ps | grep -i Heal
ps | grep -i zygote
If you notice on the sys.DeviceHealth process that the second number is the same number as the first number of the zygote process.... What that means is that the zygote process starts the sys.DeviceHealth process. The first number is process ID (the processes "adress" so to speak), and the second number is the Parent process ID (The process that started the next one).
http://vinnysoft.blogspot.com/2009/12/zygote-system-process.html
jimbridgman said:
Here is the link I saw, and how I figured out where sys.DeviceHealth is starting from.
For those interested ONLY. PLEASE do not try this yet, give me some more time to play with this in an emulator and see what I can come up with.
I am just sharing information at this time. BTW Zygote is the process that is calling the sys.DeviceHealth on the Atrix 2.
To see this Do the following from the terminal emulator app on your phone or though adb shell.
ps | grep -i Heal
ps | grep -i zygote
If you notice on the sys.DeviceHealth process that the second number is the same number as the first number of the zygote process.... What that means is that the zygote process starts the sys.DeviceHealth process. The first number is process ID (the processes "adress" so to speak), and the second number is the Parent process ID (The process that started the next one).
http://vinnysoft.blogspot.com/2009/12/zygote-system-process.html
Click to expand...
Click to collapse
zygote appears to be a process respawner (watchdog) of some type. The trick is to find out where its config lies and tweak that to prevent the launching of sys.DeviceHealth.
I've just got the busybox installed that came with TiBackup and the shell tools are sorely limited (no grep for eg.). The shell itself is also pretty limited (no pipe??? WTF?). I had a version of bash on my atrix4g, and I'm wondering if you know of a reliable source for bash and shell tools for the atrix2?
A lil info on what AT&T says and how it uses Carrier IQ and some of the devices it is on can be read here http://m.androidcentral.com/atts-us...its-own-analytics-app-not-just-embedded-phone
razholio said:
zygote appears to be a process respawner (watchdog) of some type. The trick is to find out where its config lies and tweak that to prevent the launching of sys.DeviceHealth.
I've just got the busybox installed that came with TiBackup and the shell tools are sorely limited (no grep for eg.). The shell itself is also pretty limited (no pipe??? WTF?). I had a version of bash on my atrix4g, and I'm wondering if you know of a reliable source for bash and shell tools for the atrix2?
Click to expand...
Click to collapse
Yes that is exactly what zygote is. You would disable the sys.DeviceHealth in the EXACT way it says in the in link I posted, but you have to uncompress the kernel image, and extract the init.rc in there, then edit it to not include the sys.DeviceHealth, then re-compress it with cpio. This is just for information right now, so that later on when the ROM developers get started, they can use this info for their ROMs. I am testing this using a couple Android emulators to see what I can do with this.
As for a reliable busybox, I like the version from JRummy16 in the market, go grab that an install the latest version of busybox from his installer you downloaded (I think it is 1.19.3 or something similar).
also go get the hackers keyboard in the market, it helps a lot if you EVER use the terminal app ON the phone, heck I like for text and typing as well.
Jim: I'm assuming you mean the initrd image and not the kernel, or is that all wrapped up into one in android? the initrd is an odd place for the system's watchdog config. I suppose putting it in the kernel image prevents disabling it because presumably we don't have the key to sign the new image...
that's a new version of busybox, but I'm more interested in one with all of the options compiled in. What I have is pretty bare-bones... Does his busybox have grep at least? what do you do for a decent shell?
razholio said:
Jim: I'm assuming you mean the initrd image and not the kernel, or is that all wrapped up into one in android? the initrd is an odd place for the system's watchdog config. I suppose putting it in the kernel image prevents disabling it because presumably we don't have the key to sign the new image...
that's a new version of busybox, but I'm more interested in one with all of the options compiled in. What I have is pretty bare-bones... Does his busybox have grep at least? what do you do for a decent shell?
Click to expand...
Click to collapse
Yes in the initrd image the kernel is packed in there, as well as the init.rc file on Android, as well the filesystem subset, etc.
The init.rc file in / on the phone is NOT the one the kernel itself executes, take a look at that link I posted, Here is the excerpt we are interested in, I am pretty sure that the sys.DeviceHealth is in the exact same place:
I want to get a bit more control of what things are starting up when. To do this I need to modify the init.rc file. To do this I first extracted the the ramdisk to the fileystem so that I can modify it (gnucpio -iz -F ramdisk.img).
After this I simply commented out the line from init.rc. Then we can recreate it: (gnucpio -i -t -F ../ramdisk.img | gnucpio -o -H newc -O ../rootfs.img).
Click to expand...
Click to collapse
Yes both the stericson and JRummy16 busybox have most every command in the busybox you really need, oh and they create links in /system/bin for you, so that you can run commands without needing to always type busybox in front of the command.
As far as shells, I am a bourne or korn guy, so I just use the default /system/bin/sh, since I am closely intimate with bourne, being the UNIX Engineer that I am, and handling anything at the lowest level of the OS still requires bourne. But I love to program in korn (ksh), but I have not found any android shells that are useable beyond the basics, since we really are not going to spend much time there, it does not matter much. I would get aquainted the bourne, that android uses, since android seems be using the old school UNIX style bourne, more and more, yes there is some bourne again in there too.
P.S. pipe is in the /system/bin/sh, just make sure you source the /osh/apath.sh file, to get the /system/bin and /system/xbin in the shell...
The hackers keyboard has things like the arrow keys so that you can command recall, and other helpful things.
If you really need to run something, from the shell, just make sure put sh in front of it, or it won't run in a shell, one of the oddities about Android.
I have tested the method I mentioned before, and uncompressing the ramdisk that holds the kernel, and removing the sys.DeviceHealth from the init,rc, and it does work, after packaging it back up with CPIO. I tested this on an older phone that does not have a locked bootloader.
I am afraid to test it on the Atrix 2 since we still do not have a true way to get back after a soft brick at that low level.
Given the fact that this was another style of phone, and an unlocked bootloader, and the fact that the process name is a little different, I am still confident we can do something similar for our phone.
If you follow the directions on my post, you'll find it much easier to disable the Carrier IQ.
http://forum.xda-developers.com/show...6#post20281786
mrpoet said:
If you follow the directions on my post, you'll find it much easier to disable the Carrier IQ.
http://forum.xda-developers.com/show...6#post20281786
Click to expand...
Click to collapse
^^^^^^^^^^^Page not found^^^^^^^^^^^
kirkgbr said:
^^^^^^^^^^^Page not found^^^^^^^^^^^
Click to expand...
Click to collapse
Try this Link. I am not sure if it will do the job for us or not, because we don't have the same Apps installed as the Epic 4g that this original post was copied from.
Here is the thread, mrpoet created and pointed to:
http://forum.xda-developers.com/showthread.php?t=1390874
Here is the original one, that he does link to in his references:
http://forum.xda-developers.com/showthread.php?t=1373394
I am going to see if it works.
----Edit---
I just gave this a try and all the commands ran successfully, but sys.DeviceHealth is still running after following the above post.
JRW 28 said:
A lil info on what AT&T says and how it uses Carrier IQ and some of the devices it is on can be read here http://m.androidcentral.com/atts-us...its-own-analytics-app-not-just-embedded-phone
Click to expand...
Click to collapse
Just to let everyone know, the information contained in the link that JRW 28 posted, is an accurate statement from AT&T.
I have inside information that, that is BS. There are 100's of Terrabytes of Disk Storage just for this purpose.
They're a pack of bastards.
DISCLAIMER:
It is extremely illegal to use this app against networks you don't own or don't have a permission to attack. I am not responsible for how you use it and any damage you may cause. Consider yourself warned.
Hijacker is a Graphical User Interface for the wireless auditing tools airodump-ng, aireplay-ng and mdk3. It offers a simple and easy UI to use these tools without typing commands in a console and copy&pasting MAC addresses.
This application requires an android device with a wireless adapter that supports Monitor Mode. A few android devices do, but none of them natively. This means that you will need a custom firmware. Nexus 5 and any other device that uses the BCM4339 (and BCM4358 (although injection is not yet supported so no aireplay or mdk)) chipset will work with Nexmon. Also, devices that use BCM4330 can use bcmon.
The required tools are included in the app. To install them go to Settings and click "Install Tools". This will install everything in the directory you select. If you have already installed them, you don't have to do anything. You can also have them at any directory you want and set the directories in Settings, though this might cause the wireless tools not being found. The Nexmon driver and management utility is also included.
Root is also necessary, as these tools need root to work. If you don't grant root permissions to it, it hangs... for some reason... don't know why...
Features:
View a list of access points and stations (clients) around you (even hidden ones)
View the activity of a network (by measuring beacons and data packets) and its clients
Deauthenticate all the clients of a network
Deauthenticate a specific client from the network it's connected
MDK3 Beacon Flooding
MDK3 Authentication DoS for a specific network or to everyone
Try to get a WPA handshake or gather IVs to crack a WEP network
Statistics about access points (only encryption for now)
See the manufacturer of a device (AP or station) from a OUI database (pulled from IEEE)
See the signal power of devices and filter the ones that are closer to you
Leave the app running in the background, optionally with a notification
Copy commands or MAC addresses to clipboard, so you can run them in a terminal if something goes wrong
Include the tools
Reaver WPS cracking (pixie-dust attack using NetHunter chroot)
.cap files cracking with custom wordlist
Let the user create custom commands to be ran on an access point or a client with one click.
Installation:
Make sure:
you are on Android 5+
you are rooted. SuperSU is required. If you are on CM, install SuperSU
have installed busybox (opened and installed the tools)
have a firmware to support Monitor Mode on your wireless interface
Download the latest version here.
When you run Hijacker for the first time, you will be asked whether you want to set up the tools or go to home screen. If you have installed your firmware and all the tools, you can just go to the home screen. Otherwise, click set up to install the tools. You can change the directories in which they will be installed, but I recommend that you leave them unchanged. The app will check what directories are available and select the best for you. Keep in mind that on some devices, installing files in /system might trigger an Android security feature and your system partition will be restored when you reboot. After installing the tools and the firmware (only Nexmon) you will land on the home screen and airodump will start. If you don't see any networks, make sure you have enabled your WiFi and it's in monitor mode. If you have a problem, go to settings and click "Test Tools". If they all pass, you probably don't have monitor mode enabled. If something fails, click "Copy test command" and select the tool that fails. A sample command will be copied to your clipboard so you can open a terminal, run it, and see what's wrong.
Keep in mind that Hijacker is just a GUI for these tools. The way it runs the tools is fairly simple, and if all the tests pass and you are in monitor mode, then you should be getting the results you want. But also keep in mind that these are AUDITING tools. This means that they are used to TEST the integrity of your network, so there is a chance (and you should hope for it) that the attacks don't work on a network. It's not the app's fault, it's actually something to be happy about (given that this means that your network is safe). However, if an attack works when you type a command in a terminal, but not with the app, feel free to post here to resolve the issue. This app is still under development so bugs are to be expected.
Troubleshooting:
First of all, if the app happens to crash at a random time, run it again and close it properly. This is to make sure that there are not any tools still running in the background, as this can cause battery drain. If it crashes during startup or exiting, open a terminal, run `ps | busybox grep -e air -e mdk` and kill the processes you see.
Most of the problems arise from the binaries not being installed (correctly or at all). If that's the case, go to settings, click "install tools", choose directories for binaries and the lib (libfakeioctl.so) and click install. If the directory for your binaries is included in PATH, then you don't have to do anything else. If it's not, the you need to adjust the absolute paths of the binaries, right below the "install tools" option. This might also cause problems (especially with mdk) since these programs require the wireless tools to be installed, and they won't find them if you install them anywhere other than the paths included in your PATH variable. If you don't know what the PATH variable is, then you probably shouldn't be using any of these programs.
If you are certain that there is problem with the app itself and not the tools installation, open an issue here so I can fix it. Make sure to include precise steps to reproduce the problem and a logcat (having the logcat messages options enabled in settings). If the app happens to crash, a new activity should start which will generate a report in /sdcard and give you the option to email it to me directly. I suggest you do that, and if you are worried about what will be sent you can check it out yourself, it's just a txt file and it will be sent as an email attachment to me.
XDA:DevDB Information
Hijacker, App for all devices (see above for details)
Contributors
chrisk44
Source Code: https://github.com/chrisk44/Hijacker
Version Information
Status: Testing
Current Stable Version: v1-RC.4
Stable Release Date: 2016-12-23
Created 2016-11-14
Last Updated 2016-12-26
Reserved
thank you
works great on my nexus 5 and note 3
not working on s6 edge problem i dont know i already installed in my device correctly and also hijacker airdump shows networks for attacking but not do real attack
I need an app to monitor battery charging and auto send sms texts to another mobile when level reaches a low or a high battery %.
It's actually several Apps out there which sends sms alerts on battery low, but it turns out that no developers are interested in adding the upper limit alert to their function, because Google has "banned" such auto sms sendings and wont allow them on the Play store.
But for my privat use i dont care about Google policies. So, a stupid question.. what are the chances of doing this myself, either adding the missing feature to an existing app or make a new one? I'm a former Delphi Object Pascal programmer, but I dont want to use weeks to set it up for this little task. I've seen there are some graphical "simple" tools to make Android apps without coding, but is it possible for this task?
Any suggestions are welcomed.
Android apps are coded in either JAVA or Kotlin.
I would decompile an existing app, add the missing feature, then re-compile it.
BTW:
The default SMS limit values of 30 messages within a span of 30 minutes is something that OEMs or carriers themselves can change before they sell the device to you. By default though, Google has set it to 30 messages in a 30 minute period but it’s very easy for anyone to change if device's Android is rooted:
Code:
adb devices
adb shell "settings put global sms_outgoing_check_max_count <WHATEVER_NUMBER_YOU_WANT>"
adb shell "settings put global sms_outgoing_check_interval_ms <WHATEVER_TIME_FRAME_IN_MS_YOU WANT>"
jwoegerbauer said:
Android apps are coded in either JAVA or Kotlin.
I would decompile an existing app, add the missing feature, then re-compile it.
BTW:
The default SMS limit values of 30 messages within a span of 30 minutes is something that OEMs or carriers themselves can change before they sell the device to you. By default though, Google has set it to 30 messages in a 30 minute period but it’s very easy for anyone to change if device's Android is rooted:
Code:
adb devices
adb shell "settings put global sms_outgoing_check_max_count <WHATEVER_NUMBER_YOU_WANT>"
adb shell "settings put global sms_outgoing_check_interval_ms <WHATEVER_TIME_FRAME_IN_MS_YOU WANT>"
Click to expand...
Click to collapse
Sounds like a feasable task to do. What's the most "minimalistic" decompile/edit/compile tools I could try?
Is there an updated XDA tutorial yet on setting up adb COMPLETELY wirelessly as of Android 11?
Why do I ask?
Using adb is a critical developer/hacking/user tool
As of Android 11, adb has been fundamentally changed for Wi-Fi
As of Android 12, adb was further improved for Wi-Fi
The existing XDA Developers' tutorial doesn't contain that info
I figured it out on my own (see below)...
(Which meant a LOT of new questions popped up that had to be solved that could have been answered in a tutorial)
Unfortunately, almost everything out there that I can find about adb is (wrong / inaccurate / incomplete [choose one]) in terms of how to set up a wi-fi connection as of Android 11 & 12.
The problem is there are important questions to be solved that are MISSING from that old tutorial
(These problems revolve around connection completely from the PC side only)
Where I would think EVERYONE would have the SAME questions as I do about the new setup
(And for which an updated XDA Developers' adb tutorial would be very useful!)
Mostly these new Android 11+ Developer options Wireless debugging features eliminate the USB cable.
But that then instantly brings up the non-intuitively fundamental question of ESTABLISHING the connection solely from the PC...
(which - let's never forget - is how the older, well documented USB-cable-first-then-Wi-FI adb connection had always been done)
Hence my question of:
Is there an updated XDA tutorial yet on setting up adb COMPLETELY wirelessly as of Android 11+ & 12+?
DETAILS:
Spoiler: Short summary of steps which should be in a tutorial
Given how important adb is to Android software development and hacking, I searched for an XDA Developers writeup on how the newly added Android 11+ Developer options Wireless debugging works and which incorporates a few of the even more newly added Android 12+ Developer options Wireless debugging tiles (which are CRITICAL but it's not obvious to those who haven't done it why those new Android 12 tiles have to be used every day all day!) & Android 12's separate ability to randomize the phone's MAC address for every Wi-Fi connection for added privacy (not just for every Wi-Fi SSID as Android 11 did it) which itself has further implications for reserving IP addresses (usually erroneously referred to as "static IP addresses" in the router and on the phone) for those daily random-port connections using adb over Wi-Fi only. You can no longer connect "from" the PC until after you physically "look" (using live human eyeballs!) to locate either the random port assignment (for "adb connect") or a different random port assignment plus a random pin assignment (for the new Android 11+ encrypted "adb pair" command). Now you can connect via adb over Wi-FI from the PC. But bear in mind the catch! Frequently (upon reboot for example), the Android 12+ tile turns off, as does the Developer options:Wireless debugging toggle, as does the Wi-Fi connection (in my case for privacy, as I have Wi-Fi toggle off when I leave the range of the LAN - which then turns off Wireless-debugging in an unintended cascade) but more importantly, frequently the random port assignment changes as does the random pin assignment. So you have to perform the all-important human-eyeball LOOK frequently - which you would rather not need to do if you could help it
Whew! I said what "should" be in a tutorial so others don't have to figure all of that out on their own just to set up adb completely wirelessly (without first establishing a USB connection on the PC).
I figured it all out, of course, but that XDA Developers writeup didn't help (in fact it hurts)... because it contained completely outdated information (which is why I wrote that long paragraph above, to summarize what's completely missing).
Here's what needs to be done on the phone:
Enable Wi-Fi (mine is set up to NOT auto-reconnect, for privacy)
Establish a connection over Wi-Fi to an SSID on your LAN
Enable Developer options:Wireless debugging (Android 11+)
Enable Developer options:Wireless debugging Tile (Android 12+)
Enable random MAC address per SSID (Android 11) or per connection (Android 12+)
Enable the (so-called) static IP address of the phone
Physically eyeball the random Wireless debugging port assignment (&/or random port + random PIN)
Note all the questions are related to the fact everyone wants to eliminate that last step above!
On the PC:
Simply assure yourself that the phone is on the LAN (e.g., ping 192.168.0.2) (duh)
Remember - it's using a RANDOM MAC address so the router has to be configured for that
Then connect from the PC adb to the phone completely over Wi-Fi (encrypted or not)
Remember - there's no initial establishment via USB - which means you need to know random ports!
adb connect 192.168.0.2:12345 (or) adb pair 192.168.0.2:12345 123456
Remember - everyone's goal is to obtain those random ports 100% from the PC side of things
You may have to accept an encryption dialog on your phone if this is the first time using that PC
At this point, adb over Wi-Fi works the same as adb has always worked (over USB first, then over Wi-Fi).
Until, of course, Android randomly resets the port assignment - which it does frequently!
Then you're back to having to look at the phone for the random port assignment
Notice that most of the issues people are having (see reference list below) are related to the fact that the random port assignement, as far as we know, can ONLY be obtained from a visual inspection of the Android phone - but also notice that nobody used to need to do that in the olden days (when we connected via USB cable first!).
My observation is nobody wants to do that visual inspection of the phone every time, all day, every day, whenever Android re-randomizes the MAC address (which, for me, happens frequently but my phone is set up specifically for Wi-FI privacy).
In summary, this thread asks if there is an XDA Developers' writeup for connecting adb on the PC completely wirelessly to Android 11 and Android 12 and up.
The REASON I believe that XDA Developers' updated adb tutorial is needed by hackers/developers/users is:
a. The way adb works over Wi-Fi is COMPLETELY DIFFERENT as of Android 11 (this is why finding an updated tutorial is needed!)
b. I had to figure all this out on my own, so that means everyone else does too (unless I missed the XDA Developers' tutorial), and,
c. There are still a ton of open unanswered questions that everyone also has.
REFERENCES: (in no specific order, these are attempts to make it work the way everyone wants it to work!)
(PSA) Using the new Android 12 TILE for 'Developer options' 'Wireless debugging' to establish adb connection over Wi-Fi without USB
What's the difference between Windows/Android adb "connect" versus adb "pair" when mirroring Android 12 over Wi-Fi onto a Windows PC?
Android 12 Developer options adb "Wireless debugging" option keeps turning off
[adb,scrcpy,vysor] What ports does Android 12 randomly set when Wi-Fi connecting via Wireless debugging adb "pair" or "connect" commands?
[adb] What is the adb syntax to connect wirelessly to Android by unique serial number (instead of by Wi-Fi LAN IP address & random port assignment)?
Note that none of those threads would be needed if we could have found a comprehensive tutorial that was updated to Android 11 and 12 new connect-adb-over-Wi-Fi-without-USB functionality that answers those basic obvious questions to ask. (See illustrative screenshots below).
Is an updated XDA Developers' writeup extant for connecting adb on the PC completely wirelessly to Android?
I simply use ladb - it's an app that makes the whole process a breeze
See a big xda write up about it here ..
How to debloat your phone (and more) without connecting to a PC
LADB is an app that lets you run ADB shell commands from your phone, no root and no PC needed! Use it to debloat your phone and more!
www.xda-developers.com
CFKod said:
I simply use ladb
Click to expand...
Click to collapse
Thanks for that advice to use Local ADB which "leverages Android’s built-in support for ADB over WiFi to provide a GUI for sending shell commands straight from the Android device."
The great news is that was the first XDA Developers' tutorial that I've seen that showed cognizance of the new Android 11 features of setting up adb completely wirelessly (without need for USB first).
* GitHub: LADB (A local ADB shell for Android!)
The bad news is that, at least upon initial inspection, ladb doesn't do anything you can't do inside of Termux as far as I can tell (is that correct though - maybe the ladb apk can do more privileged actions?).
Spoiler: Example of doing in Termux what would often be done in adb
1. Install F-droid <https://f-droid.org/>
<https://f-droid.org/F-Droid.apk>
2. Install F-Droid Termux <https://f-droid.org/en/packages/com.termux/>
<https://f-droid.org/repo/com.termux_117.apk>
3. Add F-Droid Termux Widget <https://f-droid.org/en/packages/com.termux.widget/>
<https://f-droid.org/repo/com.termux.widget_12.apk>
4. Run the F-Droid Termux & create an alias we'll name "rad" for reset ad id.
$ rad
(This should report: No command rad found)
$ alias rad 'am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity'
$ rad
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programmatically close it later)
$ cat ~/.bashrc
cat /data/data/com.termux/files/home/.bashrc
No such file or directory
$ alias > ~/.bashrc
$ cat !$
alias rad='am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity'
$ unalias rad
$ rad
(This should report: No command rad found)
$ source ~/.bashrc
$ rad
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programatically close it later)
5. Run the F-Droid Termux and create two directories for the shortcut widget
$ mkdir -p $HOME/.shortcuts (we will put our shell script here)
$ mkdir -p $HOME/.shortcuts/tasks (we didn't use this directory yet)
6. Create a shell script to open up the reset ad id Activity.
$ cd $HOME/.shortcuts
$ nano ./rad.sh
Edit the result to look like this:
#!/data/data/com.termux/files/usr/bin/bash
am start -n com.google.android.gms/.ads.settings.AdsSettingsActivity
$ chmod +x ./rad.sh
$ ./rad.sh
(nothing will happen)
7. Modify termux to be able to execute user shell scripts on Android.
$ pkg install termux-exec
8. Test your shell script.
$ ./rad.sh
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programmatically close it later)
9. Add the Termux Widget to your homescreen.
Long press your Android homescreen.
Select "Widgets" & then "Termux:Widget" & place it on your Android homescreen.
It will ask: Create widget and allow access? to which you press "Yes"
Then press the "rad.sh" entry showing up in that Termux Widget.
"Termux requires "Display over other apps" permission
to start terminal sessions from background on Android >=10."
"Grants it from Settings -> Apps -> Termux -> Advanced"
10. Grant Termux permission to display over other apps:
Android11:Settings > Apps > Your apps > Termux > Appear on top = (change off to on)
11. Now press the Termux Widget entry named "rad.sh"
(this should pop up the "Reset Advertising ID" Activity on your phone
(manually close that Activity for now - we can programmatically close it later)
12. Reboot the phone & ensure everything is persistent.
Tap the new homescreen icon after rebooting
& the "reset ad id" Activity should pop up.
But worse, the LocalADB instructions clearly say to do the same manual (aurgh!) steps we've been doing all along.
That is, even with LADB, they're still NOT obtaining the random port address programatically; they're getting it manually - just like I've been doing all along without LADB.
So ladb doesn't change anything... as far as I can tell (but maybe I'm wrong?).
"Copy the 6 digit “Wi-Fi pairing code” and paste it into the “pairing code” box in LADB. Copy the 5 digit port number from the IP address (the 5 numbers after the colon) and paste it into the “Port” box in LADB."
Click to expand...
Click to collapse
If I were to "guess" wildly - then that means what everyone wants is perhaps impossible to accomplish; but I'm still hoping that's not the case - but - the point is to find an updated XDA Developers' tutorial that shows an awareness of the stated problem set.
EDIT: I have an idea. I installed LADB on Android, and now I'm trying to see if I can query that LADB from the PC using adb commands where the goal is maybe the PC adb can query the Android ladb to figure out what the current random port assignment is???
GalaxyA325G said:
So ladb doesn't change anything... as far as I can tell (but maybe I'm wrong?).
If I were to "guess" wildly - then that means what everyone wants is perhaps impossible to accomplish; but I'm still hoping that's not the case - but - the point is to find an updated XDA Developers' tutorial that shows an awareness of the stated problem set.
EDIT: I have an idea. I installed LADB on Android, and now I'm trying to see if I can query that LADB from the PC using adb commands where the goal is maybe the PC adb can query the Android ladb to figure out what the current random port assignment is???
Click to expand...
Click to collapse
Yes .. everything you have said is correct
I wouldn't say it has any special privileges. It just guides you through the connection process.
You end up with a blank canvas in terminal - just as you would using termux
Not sure what the app costs, I purchased pre release so cost barely a thing
either way , it cuts out some of the faff and i'd certainly recommend for a less tech savvy person...
Then again.. why wouldn't anyone with no clue, use adb?
If I can assist in any way. Feel free to give me a shout on telegram
CFKod said:
Yes .. everything you have said is correct
Click to expand...
Click to collapse
I must again thank you for letting me know about local adb.
I installed ladb the instant you informed me about it.
Yesterday and today I started to test it out.
CFKod said:
It just guides you through the connection process.
Click to expand...
Click to collapse
I'm hoping maybe this ladb running on the Android device "might" give it something special that the PC doesn't have in terms of access to the information of the random port assignment on Android.
There are multiple levels of this problem set, the top level being the almost complete lack of XDA Developers' tutorials that have any cognizance of what's new in Android 11 and up with respect to adb wireless connections - where - again - I thank you for finding the one and only XDA Developers' tutorial that shows that awareness.
However, the more important level of this problem set is to find a way to connect adb wirelessly to Android WITHOUT manually grepping the random port with our eyeballs.
CFKod said:
You end up with a blank canvas in terminal - just as you would using termux
Click to expand...
Click to collapse
It may very well be that the Android developers made that impossible (e.g., for security reasons); but in the absence of any information or tutorial stating that as a fact, I'm not going to assume it's impossible (yet).
AFAICT, the way to solve the problem is to find a way to either:
a. Keep the port assignment static, or,
b. Set the port to a specific assignment (as we did with USB), or,
c. Determine the random port assignment programatically
It "may" be that local adb can help in that latter method... dunno yet... but I didn't even know ladb existed until you mentioned it so I'm starting from scratch without a tutorial (for this part of the problem set).
CFKod said:
I wouldn't say it has any special privileges.
Click to expand...
Click to collapse
Actually, after looking it up since yesterday, I think local adb DOES have more privileges than does Termux; so I was wrong in that assumption.
The ladb developer, @tytydraco said so himself on Dec 18, 2020 when he announced the existence of the ladb APK on XDA Developers.
tytydraco said:
for those of you who have used or encountered ADB in the past, you know that you usually need a PC to shell into your phone. While yes, apps such as Termux exist, they don't have elevated privileges as ADB does.
Click to expand...
Click to collapse
So we can safely assume ladb has "elevated privileges" which Termux doesn't have (which is a good thing as we may need them!).
CFKod said:
Then again.. why wouldn't anyone with no clue, use adb?
Click to expand...
Click to collapse
Well.... just as "mock location" GPS spoofing is a "Developer option" that has gone mainstream, I suspect we're at an inflection point where with screen mirroring of scrcpy and vysor, that adb usb/wireless debugging has gone mainstream too!
In summary, here's the status so far (which may change over time)...
a. Unfortunately, nobody knows of an updated XDA adb tutorial
b. But there is an updated XDA ladb tutorial
c. But even that ladb tutorial REQUIRES an eyeball grep of the random port assignment (aurgh!)
Note with the brand new Android 12 tile that it's not in the least difficult to do that eyeball grep of the current random port assignment (although you have to get up from your computer to find the phone in order to do so) - but the whole point of computers is they are supposed to do that stuff for you (are they not?).
While it may be designed that way by Google, I'm hoping I can figure out a programatic way to obtain that random port assignment from the PC, where the suggestion of perhaps implementing ladb as a middleman "might" solve that problem (if I can figure out the method).
Thanks for your help and advice, as everyone has the same adb random port assignment problem who wants to mirror their phone onto the PC completely wirelessly - and for which there is no known XDA tutorial to help them (yet).
BTW, I've noticed only recently since I started testing out ladb that the serial numbers are different where I wonder if anyone can explain why there is both a long and a short serial number when using adb completely wirelessly.
Note the question matters because "maybe" we can omit the random port if we can connect via the static serial numbers...
Adb source changes a lot, with the adb wifi stuff being added in, you could probably compile a modified adb binary to use via an apk like ladb that could use a static serial number connection method.
In source, there's a lot of testing binaries you can compile, iirc in maybe 11-dev branch there was some code commented out to allow for more insecure connections.
Hey I have noticed that shizuku also uses wireless adb...
I may have time to test it later.
Surge1223 said:
you could probably compile a modified adb binary to use via an apk like ladb that could use a static serial number connection method.
Click to expand...
Click to collapse
Thank you for that suggestion, because if it was easy to connect purely over Wi-Fi (sans USB) between adb on the PC and the Android 11+ phone (WITHOUT eyeballing the randomly assigned port address), it would have been documented already (since it's what EVERYONE wants to do).
So we're breaking new ground...
And, while I definitely harbor the optimism that there (almost always) is a way, I do agree that nobody on the Internet (that I can find) has found THAT way.
Still... as you suggested, ladb does have some extra "hooks" on the phone itself which may allow ladb to REPORT back to the PC over Wi-Fi what our EYEBALLS have to see for themselves today (of the random port address).
This report back to the PC (of the random port address) over Wi-FI has to be done in some OTHER protocol than adb itself, I suspect... as it's a chicken-and-the-egg scenario otherwise.
BTW, we "might" be able to use the Android serial number to good effect, but probably not as my tests using the Android serial number only work AFTER the adb connection has been prior established.
Code:
C:\> adb devices
*daemon not running; starting now at tcp:5555
*daemon started successfully
List of devices attached
C:\> adb devices
List of devices attached
C:\> adb devices
adb-YFVR80V7YFY-yF7kj8._adb-tls-connect._tcp. device
C:\> scrcpy -s adb-YFVR80V7YFY-yF7kj8._adb-tls-connect._tcp.
C:\> adb connect -s adb-YFVR80V7YFY-yF7kj8._adb-tls-connect._tcp.
C:\> adb connect -s 192.168.0.2
CFKod said:
Hey I have noticed that shizuku also uses wireless adb...
I may have time to test it later.
Click to expand...
Click to collapse
Thank you for that pointer to Shizuku which, like ladb, I had never heard of until you mentioned it as a possible solution.
What's nice is Shizuku has its own updated tutorial on XDA Developers which, at least, is aware of the new Android 11+ Developer options:Wireless debugging toggle, as it says...
"On Android 11 or above, you can enable Wireless debugging and start Shizuku directly from your device, without connecting to a computer."
Click to expand...
Click to collapse
By which they really mean:
"On Android 11 or above, you can enable Wireless debugging and start Shizuku directly from your device, without first needing to connect by USB to a computer."
Click to expand...
Click to collapse
I'm not rooted; but, since Shizuku can be started on the Android device, maybe it can be used to tell the computer over Wi-Fi what the current random port address assignment is (or the unencrypted adb connect command) or the random port and pin assignment (for the encrypted adb connect command).
MOD EDIT: ENGLISH TRANSLATION ADDED
I want to apply this program, Yasser, as much as possible
---------------------------------
ااريدتطبيق هذا البرنامح ياسر مايمكن
MOD EDIT: ENGLISH TRANSLATION ADDED
and not google
-----------
وغير قوقل
زين said:
MOD EDIT: ENGLISH TRANSLATION ADDED
I want to apply this program, Yasser, as much as possible
---------------------------------
ااريدتطبيق هذا البرنامح ياسر مايمكن
Click to expand...
Click to collapse
زين said:
MOD EDIT: ENGLISH TRANSLATION ADDED
and not google
-----------
وغير قوقل
Click to expand...
Click to collapse
1. This thread is a question (mostly) about a missing XDA tutorial.
2. The NEED for the tutorial is embedded in the details
Essentially...
a. We need an updated adb TUTORIAL for Android 11+ new features
b. Specifically, how to connect COMPLETELY via Wi-Fi (no USB)
Keeping in mind...
i. The OLD USE model used adb over USB first
ii. And then, after USB connection, adb could move to Wi-Fi
What we want is...
A. The Android 11+ use model is to eliminate the need for USB
B. But STILL connect using adb over Wi-Fi from the PC
Where...
A. The OLD use model was done COMPLETELY from the PC
B. And we're simply trying to REPLICATE that old use model
However... the problem is...
1. So far, we MUST first ascertain VISUALLY the random port (& PIN)
2. Which means we can no longer connect FROM the PC
That's the problem exposed by this thread, in a nutshell...
But... I do NOT understand what the two posts above are asking us to answer...
a. "I want to apply this program, Yasser, as much as possible"
b. "And not google"
Huh?
A. Which program? (adb? ladb? shizuku?)
B. Who (or what?) is Yasser?
C. And what does "not Google" have to do with it?
D. What does that poster want as an "answer"?
I want to help the guy (just as I'd want to help anyone).
But I don't understand what the heck the guy is even asking.
Can someone translate that English translation to something that makes sense in English that can be answered in English?