[Q] Command line Android testing? - Android Software Development

I'm trying to test several Android features -- features that don't involve the full complement of an Android app. For example, PhoneNumberUtils.convertKeypadLettersToDigits is just a String operation. I'd like to test convertKeypadLettersToDigits by calling it from a Java main method and sending the output to System.out. This avoids the overhead of running the emulator. When I try to do this, I encounter several hurdles, the latest of which is the RuntimeException Stub!
Is there a way to do this kind of testing?

Related

kSOAP2 and custom string types, or alt. engine?

Hi All,
I'm trying to access a SOAP service (I know, why can't people provide REST?!) from my android app.
I found ksoap2 and it looks nice and simple, I've imported the lib into my project (eclipse fwiw) and it all appears to be functioning normally.
However, the SOAP service I'm attempting to use is extremely picky.
It expects string data ("SAE" or "SHY" for example) named "crs" in a "type" of "CRSType". I can not figure out how I can get kSoap2 to do this. If I send the data as type String, I get a soap error back from the server of "no crs specified".
I have tried setting the request property to a java type of CRSType implementing CharSequence and a toString() method that returns the data. Wireshark shows me it's still reported to the service as "d:string".
I tried creating a custom data type with KvmSerializable and it nested it, and called the data "d:anyType" containing a normal "d:string"...
I'm starting to think I should craft the xml myself, but it's frustrating me and I figured I'd see if anyone here had any ideas.
ETA: Feel free to suggest other libs that might be suitable and as easy-to-use as kSoap2.
BTW, it's an opensource app, probably won't reach market but is on googlecode under droidtransport if anyone wants it (no webservice code committed as so far it's not working!)
TIA
--
Martyn

[Q] Using tinyalsa in android application

Hi,
I'm trying to figure out how to use tinyalsa in my android app to record audio.
I know of the following ndk libs: tinyalsa and tinyalsa-ndk, but I couldn't figure out how to wrap them using java calls, and where to obtain valid parameters (e.g. card, device). I also know that it requires root, but I couldn't find out why - am I required to push files somewhere, grant rw permissions to something or something else?
I'm not looking for a ready-to-go wrapper library (although I would certainly not mind one), just some starting point for undertanding how to use it.
Many thanks
What are you trying to achieve with tinyalsa? Standard Android recording API doesn't satisfy your needs?
surlac said:
What are you trying to achieve with tinyalsa? Standard Android recording API doesn't satisfy your needs?
Click to expand...
Click to collapse
I'm trying to write a Call Recorder for myself that does not rely on Standard API recorders (e.g. MediaRecorder or AudioRecord).

No Root? How about a set of linux shell utilities without root.

Anybody else upset that you cannot root the device and install common linux shell utilities on it such as ssh, curl, etc? I created a petition for google to create a set of shell utilities for all android owners, regardless as root. Even without root, there is no reason we can't use ssh. This is common on most linux hosts. Please have a look and consider signing the petition, or give me feedback.
https://www.change.org/p/google-inc...utm_source=share_petition&utm_medium=copylink
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Hi #Sual, while you are correct, SSHDroid provides an SSHd server, However it does not provide a native ssh client, I could run through the connected device. I have tried many things suggested by users, but none of them offer a set of shell utilities I can run from the android host shell itself. Did you have a chance to read through the petition and fully understand what I'm requesting. Similar functionality would come from dan drowns android ports, or lil debi, or busybox, but all require root. Finally the fact things aren't updated for 5.0 compatibility, underscores that There is a reason that people desire this functionality on the device itself. Thanks for your feedback.
Saul Goodman said:
nothing stops you from making this yourself, or using one of the existing ways to run a ssh server
Terminal IDE provides lots of GNU utilities, but hasn't been updated for 5.0 compatibility https://play.google.com/store/apps/details?id=com.spartacusrex.spartacuside&hl=en
SSHDroid provides a SSH server https://play.google.com/store/apps/details?id=berserker.android.apps.sshdroid&hl=en
Click to expand...
Click to collapse
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
ecaslak said:
There are ways to run Busybox without root. Here's an app that makes it dead simple: https://play.google.com/store/apps/details?id=burrows.apps.busybox. I've used it on my XT1528 (Verizon Moto E) with great success.
There are also ways to run Debian without root, like KBOX: http://kevinboone.net/kbox3.html
Click to expand...
Click to collapse
Hi @ecaslak ,
I will try your suggestions. Most recently I've tried GNURoot Debian, which uses proot. However I was unable to use the open ssh server I installed on it. However, I will still stand by my petition.
A significant portion of the Android community spends great effort trying to root their devices, many with only the desire for common functionality that we have from any core linux distribution. While having root itself on a device would be great, it should be expected that google provide all device owners with basic functionality found in most core linux distributions for the last 20+ years. Not including an option for basic user utilities ( ssh / wget or curl / most of what is included in busybox, a fairly powerful common shell such as bash or similar ) , that most non-root accounts have on practically all systems, limits the freedom of expression and ability to create that users have come to expect from a GNU Linux distribution.
While root can be enjoyed on many devices, this is often only available to a small segment of the population who either pays a significant amount more for a unlocked device with a free bootloader, or spends a significant amount of time trying to root their device. Android does seem to provide a small set of simple userland utilities such as ls, cat, but not much beyond that. This is a request to provide a set of utilities similar to what is found on most any common Linux distribution.
While their is some concern for manufacturers or communication companies to lock their users devices down, there should be no concern allowing basic utilities on all android devices. To be specific, what harm does allowing somebody to download a file through a terminal using wget or curl, or to ssh into a host , or the phone itself? Similar functionality to these kind of operations are provided to developers in the form of the Android SDK, and or libraries and programs that can be installed on all android platforms. However having simple system shell utilities is quite different that writing an application. Then there should be no harm in making them more accessible to the Android community, in said form. Finally the communications companies will benefit from increased usage, and therefore data billings from providing these features.
This petition requests that Google compile / create / maintain / distribute a set of common linux shell utilities to be included with the device, or provided through the play store for all Android versions moving forward. The people who are signing this petition believe that any owner should be able to use common *nixy functionality on any personally owned android device, regardless of device manufacturer or communication company.
Furthermore, we believe that by creating a standard distribution for these tools will reduce the effort of many people doing the same thing in their own time. That a standard will improve the tools themselves, and improve the Android experience to the community at large.
Google Android has stood on the back of giants, and taken the Linux kernel and wrapped a nice system and SDK around it, with the exception of removing some of the core functionality included in most any Linux system. Thus Android is significantly limiting the freedom of users. This is a proposal for the middle ground, which will allow a better system for everyone, even people who have no root or unlocked device.
Finally I Had a look at the kbox project, I think this sentence from their site underscores the challenge users face:
"Android is not Linux, as Google repeatedly tells us — and getting ordinary Linux desktop utilities to work in Android can be a chore, to say the least."
Hi @sual, I believe change.org is having some issues with their servers the past few days. Sorry for the dead link. I re-posted above and found it working. I also pasted the petition arguments above. It is my belief that if enough people desire a feature, then it is reasonable to ask Google to provide such a feature. I think it's reasonable to create a petition for something you believe in. Finally I appreciate your feedback, and have considered your point of view.
Saul Goodman said:
I couldn't read your petition because the link is bad.
But I don't know why this is something you feel is owed to you by Google. I agree that it'd be useful, but it's totally not something I'd expect to be part of a mobile platform at all. It's clearly something you could make on your own. If existing solutions require root, it's in part because that makes it easier or because their creators assume that everyone has root.
Click to expand...
Click to collapse
Finally, another link in case the copy link from the change.org platform is broken.
https://www.change.org/p/google-inc...-linux-shell-comands-for-the-android-platform
Incredibly few Android users root. And Android is not a traditional Linux distribution; it's a mobile OS that happens to use the Linux kernel. GNU/Linux distributions contain all these common tools because large essential portions of them are written in scripting languages and because they are needed for operation of the system. These things are simply superfluous in Android.
Google hasn't removed any functionality from a Linux distribution in the building of Android. They build a totally different system using Linux as the kernel. and have no need to include other separate components that comprise a standard Unixlike environment Just like all kinds of other embedded devices do. In this sense, Linux is a commodity OS kernel that competes with other open-source and proprietary ones. Furthermore, Android in particular depends on non-POSIX mechanisms like wakelocks and SELinux and uses an unPOSIXlike approach to isolate different apps (different uid per app).
I suggest you start writing code or organize a project and recruit developers to build this.
@sual Developers have already built plenty of Android binaries. I can build em. Look here: http://dan.drown.org/android/ . There are busybox sets all over the play store. The problem remains that they are usually crippled if installed without root. Crippled beyond the point of what you can do with a user account in most Linux environments. I thought the desire for this would be greater, but maybe I'm just an odd fish. I should save up and look for a platform that meets my wants and needs.
If tools running as a non-root user on Android seem more crippled than a non-root user on a typical Linux distribution, it's because Android uses a different UID per app for isolation purposes. Which is a good thing. Hence the existence of the "system" user on Android, accessible via adb, which has many more permissions than available to any particular app. Making even this set of permissions more widely available to apps would be a security nightmare, there's a reason you have to deliberately turn on developer mode then again enable ADB, and a reason why you (afaik) have to have root if you want to enable ADB over wifi on the device itself.
With that said, you should be able to package your own tools and run them via the adb user on any Android device, no?

Help with running a backscreen sample

I had an idea to do a time tracking program using the back screen, so thought I'd knock it up and see how it is. But no, not so simple.
For background, I've actually released a few games on Android, but they were a few years ago and were all in C++. They only used Java to open a GL context and connect to input and audio. The build system was a custom one and I didn't go near Eclipse.
So I downloaded Android Studio, made a copy of the yp_hello project and got it all building and running. Except that it crashes on startup every time.
This:
setBSContentView(R.layout.bs_activity_main);
is immediately followed by this:
mTransferredText = (TextView) (findViewById(R.id.bs_sub_text));
But it crashes here with java.lang.ClassCastException: java.lang.reflect.ArtMethod cannot be cast to android.widget.TextView
However, it doesn't crash if I put in a breakpoint in and run it.
Without the breakpoint, a Log print shows that findViewById returns an java.lang.reflect.ArtMethod object.
With a breakpoint anywhere in the code (even after the crashing line), the same Log print show that findViewById returns an android.view.TextView object. Once the breakpoint has been hit, I can continue the program and it all works fine on the phone.
Can anybody help with getting this working? It's just a yp_hello sample that comes with the Yotaphone SDK, made to run in the latest Android Studio with the latest SDK.

Shady process in my Dynalink 4K Box. Possible backdoor?

Yesterday, I noticed my Dynalink 4K Box struggling with 4K video. After running "top" in "adb shell", I found a strange process named "askey_tr", running as root (!), occasionally pegging the CPU at 100-200%.
I decided to dig around and in the end was so spooked (and annoyed with the performance drop) that I ended up rooting my device and removing this binary with a DIY Magisk module. Here's what I found by running "strings" on the binary.
It seems to include help strings for common unix tools like ping and traceroute:
Code:
Modern traceroute for Linux, version 2.1
Copyright (c) 2016 Dmitry Butskoy, License: GPL v2 or any later
You do not have enough privileges to use this traceroute method.
ping: can't set multicast time-to-live
This would've almost fooled me (maybe "tr" in askey_tr stands for traceroute, right?), however, it gets more interesting after you look more. There are references to something called TR069:
Code:
external/tr069/source/atomic.c
external/tr069/source/sd.c
external/tr069/source/ft.c
Googling revealed that TR069 is a protocol for remote management of consumer devices, including set-top boxes. That would make some sense. There is even a paper describing use of TR069 for Android devices. However, the unknown extent of this type of "management" scares me. Wouldn't Android's standard update mechanisms be enough?
There are also some strings that look like metrics about the device:
Code:
Device.DeviceInfo.ProcessorNumberOfEntries
Device.DeviceInfo.SupportedDataModel.1.URN
Device.DeviceInfo.ProcessStatus.ProcessNumberOfEntries
Device.ManagementServer.ConnectionRequestUsername
Device.ManagementServer.STUNUsername
Device.ManagementServer.StandbyPolicy.NetworkAwarenessCapable
Device.UserInterface.PasswordRequired
Device.UserInterface.ISPName
Device.UserInterface.RemoteAccess.X_Charter_AllowedIpRanges
Device.Ethernet.RMONStats.template.DropEvents
Device.Ethernet.Interface.2.Enable
Device.Ethernet.Interface.2.Stats.BytesReceived
Device.Ethernet.Interface.1.Enable
Device.Ethernet.Interface.template.LowerLayers
Device.Ethernet.Interface.template.Stats.BytesReceived
Device.Ethernet.Link.2.Stats.DiscardPacketsSent
Device.Ethernet.Link.1.Stats.UnicastPacketsSent
Device.Ethernet.Link.template.Stats.BroadcastPacketsSent
Device.Ethernet.Link.template.Stats.BroadcastPacketsReceived
Device.Ethernet.VLANTermination.template.Stats.BroadcastPacketsReceived
Device.SoftwareModules.ExecutionUnit.template.Status
Device.SoftwareModules.ExecutionUnit.template.References
Things related to XMPP protocol:
Code:
ctrl_send_sig ctrl_sig_xmpp_status_changed
jabber:client
xmpp_load_pem_cert
And some other things that give us clues: HTTP request templates, symbols from OpenSSL, etc.
I also tried to drop this executable into Ghidra, but felt way out of my depth as I'm not experienced in reverse engineering. Perhaps this will pique the interest of someone more skilled.
So in conclusion, this may be something as benign as a software for delivering OTA updates, or a full-on backdoor. The troubling part is it running automatically as "root" and the fact that its nature is not documented anywhere.
I'm attaching the binary and a zip of the contents of /data/tr069 where the executable seems to store its data.
sus
looked through the string table
found RAND_seed, Device.Users.User.2.Password, GetSSIDFromTR069ManagerServer
TR-069 is a remote management protocol standard. It's likely been put in that box for remote command and set up. I've been working with one Android TV OEM to include it in a set top for monitoring and basic config/maintenance stuff. In a way it would be a kind of backdoor to change config info or diagnostics. It was likely built in by the manufacturer for that purpose though and not some nefarious 3rd party (assuming the manufacturer's intentions are noble). I think it boils down to if you trust the box maker or not. TR-369 is the newer variation of it. This doc goes into some more detail on what it can be used for.

Categories

Resources