Listen to live FM broadcasts on devices that don't have a built-in FM radio!
Description
SDR Touch turns your mobile phone or tablet into a cheap and portable software defined radio scanner. Allows you to listen to live on air FM radio stations, weather reports, police, fire department and emergency stations, taxi traffic, airplane communications, audio of analogue TV broadcasts, audio amateurs, digital broadcasts and many more! Depending on the hardware used, its radio frequency coverage could span between 50 MHz and 2.2 GHz. It currently demodulates WFM, AM, NFM, USB, LSB, DSB, CWU and CLW signals.
You can get a compatible USB receiver for under $20 online from eBay. Just plug in your rtl-sdr compatible USB DVB-T tuner into your Android device using a USB OTG Cable and turn on SDR Touch. For list of supported Realtek RTL2832U based dongles, please see the end of the description.
Compatible USB DVB-T tuners
- Generic RTL2832U (e.g. hama nano)
- ezcap USB 2.0 DVB-T/DAB/FM dongle
- Terratec Cinergy T Stick Black (rev 1)
- Terratec NOXON DAB/DAB+ USB dongle (rev 1)
- Terratec Cinergy T Stick RC (Rev.3)
- Terratec T Stick PLUS
- Terratec NOXON DAB/DAB+ USB dongle (rev 2)
- PixelView PV-DT235U(RN)
- Compro Videomate U620F
- Compro Videomate U650F
- Compro Videomate U680F
- Sweex DVB-T USB
- GTek T803
- Lifeview LV5TDeluxe
- MyGica TD312
- PROlectrix DV107669
- Zaapa ZT-MINDVBZP
- Twintech UT-40
- Dexatek DK DVB-T Dongle (Logilink VG0002A)
- Dexatek DK DVB-T Dongle (MSI DigiVox mini II V3.0)
- Dexatek Technology Ltd. DK 5217 DVB-T Dongle
- MSI DigiVox Micro HD
- Genius TVGo DVB-T03 USB dongle (Ver. B)
- GIGABYTE GT-U7300
- DIKOM USB-DVBT HD
- Peak 102569AGPK
- SVEON STV20 DVB-T USB & FM
Interaction with battery savers
It turns out some manufacturers such as Huawei and Samsung have very aggressive power saving policies and force close background apps without notice. If the system decides to kill the RTL-SDR (or SdrPlay) driver while SDR Touch is running, the app will stop playing and become unresponsive eventually showing a "Disconnected unexpectedly" error message.
If you are experiencing this issue, the only solution that currently exists is to manually whitelist *both* the SDR driver app and SDR Touch in your phone's power saving settings to prevent the operating system from unexpectedly stopping the apps. More information and instructions on how to do this based on your particular phone make and model can be found on this website: dontkillmyapp.com
Feedback
An article about SDR Touch - Android Meets the RTL2832U from HamRadioScience
A user submitted video showing off advanced features of SDR Touch running on a mobile phone:
Any additional feature suggestions, comments or feedback will be much appreciated!
looking good sir looking good
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
daniel_reetz said:
Fantastic work. I am excited to see squelch on the list of improvements. Is there any chance that you will ever support a plugin architecture or P25 decoding? There is a decoder called DSD which can decode P25. Squelch+P25 would make it replace my scanner entirely. I would pay additional $$ for each of these features and it would still be more affordable and interesting than carrying around a scanner.
Click to expand...
Click to collapse
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Although this seems to be a great app, I couldn't make it to work with Xperia Ray... ("no tuner found" error)
Anyone here had success with making it work on a Xperia phone?
martintzvetomirov said:
Thanks for the support! Squelch is coming soon! I will look into P25 but we might need to work together on this - you may need to provide me some I/Q recorded samples - but I would say this would be a bit later since I just started my second semester and have some studying to do as well
P.S. Squelch is now on top of my TODO list
Click to expand...
Click to collapse
Fanastic, thank you. I can't wait for squelch!
I'll supply whatever data/info you need to implement P25. I/Q samples are no problem. I understand completely that your time is limited and there is a larger audience to serve, but if you need resources, please let me know what you need and I'll see how I can help.
My account here is new, so I can't post links, but "DSD" and "radioreference wiki" will get you to the DSD source.
Amazing work! Well worth the $9.99USD pricetag. Gave you a nice review on the Google Market/Play Store as well.
FYI: Works wonderfully on an Acer A500 w/ Android 4.2.1.
SDR Touch has been removed by Google from Google Play! I will investigate the issue and will report back as soon as I have more information!!!
If somebody needs the latest version of SDR Touch, please download it from the attachment. Keep in mind that as soon as SDR Touch goes back to Android market you might need to reinstall it in order to get the latest updates!
Ok, just to make it clear for everybody that is concerned.
SDR Touch DOES NOT violate the GPL license!
SDR Touch is merely a client for - https://github.com/martinmarinov/rtl_tcp_andro-. rtl_tcp_andro is released under GPL2+. SDR Touch and rtl_tcp_andro are separate works in the sense of GPL. They are neither statically or dynamically linked and they are two separate executables that communicate over a TCP connection. rtl_tcp_andro is bundled with SDR Touch merely to help the user and with accordance to point 2. of GPL Terms and Conditions. You can think of SDR Tocuh as an "installer" of rtl_tcp_andro. It just launches rtl_tcp_andro with Runtime.exec("");. Furthermore SDR Touch could happily work without the bundled rtl_tcp_andro in network mode by connecting to a remote computer running either rtl_tcp_andro or the original rtl_tcp.
Therefore GPL is not violated. Saying that GPL is violated would be like saying that you can't listen to online radio with your proprietary music player because the radio is being streamed with a GPL based software.
A quote from GPL-3.0:
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Click to expand...
Click to collapse
Did you read that quote ?
... and which are NOT combined with it such as to form a larger program, in or on a volume of a storage or distribution medium ...
Click to expand...
Click to collapse
A single .APK _is_ a single distribution medium ... and they definitely _ARE_ combined to form a larger program. The "SDR Touch" .APK is the larger program, containing both your own code and the rtl_tcp_andro binary. That clause is meant for when you ship a CDRom with different stuff on it for example where they have no special relation ship. Here the relation ship and dependency is clear (even says so in the damn description of the app)
The problem is not with SDR Touch or the way it's a client for a rtl_tcp version, that's the right way to do it.
The problem is that both are distributed bundled.
SDR Touch and rtl_tcp_andro need to be two separate packages to be installed independently by the user.
There is also the requirement to make a written offer and include the full license terms when distributing rtl_tcp_andro, usual way is to include both the license in the .APK and also accessible to the user in the UI (menu often).
Cheers,
Sylvain
smunaut said:
Did you read that quote ?
Click to expand...
Click to collapse
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
The license is linked in the Help section of SDR Touch. The thing that I haven't done is to put the license physically on the apk as well.
But that's a good point,
Thanks,
Martin
martintzvetomirov said:
But rtl_tcp_andro is a separate binary and the apk is just a container like a CD Rom. That's precisely the point. The binary classes of SDR Touch are separate entities in the apk file and are not linked to rtl_tcp_andro!. The GPL allows using an "installer" to install proprietary software as well as GPLed software in one go. The Android apk installer grabs the contents of the archive (which is like a rar archive) and unrars it ("installs") it onto the device. When the user is using the program, the two entities are still different and separate!
Click to expand...
Click to collapse
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
smunaut said:
Mmm, first, I'm not sure the APK is uncompressed on the flash.
But you're missing the point that in this case it's a single "application", no matter what binaries it's composed of. It's not pulled independently (as a dependency or not) and via that "installer" you can't get it independently, it's just a single package, even presented as a single application to the user (aren't they both under the same 'title' in the "Application" tab of android ?)
So really, I don't see how you could consider this as not being a "whole" without, like I said, distribute it as two different packages (which would also allow other "users" to use the rtl_tcp_andro for eg) and give a undeniable separation between the two.
Click to expand...
Click to collapse
Ok, I see your point and this looks like an option. I still can argue that they are separate but in order to prove that, as you say, I might split them into two packages.
Will see how things go, will keep you posted!
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
MS3FGX said:
Like smunaut said, this definitely counts as a derivative work as they are being presented to the user as one cohesive application via the Play Store.
This is the same problem that SDR# had some time back, where they tried to distribute the GPL RTL-SDR with their proprietary UI. They thought that, since the UI only communicated with RTL-SDR and wasn't technically part of SDR#, they could include it; but that's not the case. (http://dangerousprototypes.com/2012/08/05/confusion-over-sdr-vs-opensdrsharp/)
The solution in this case will be the same as it was for SDR#: Either make the entire application GPL, or break rtl_tcp_andro into a completely separate package. Make sure that the description for the rtl_tcp_andro package clearly states its license, and make sure you link to the GitHub page for it so the source is clearly available. That should cover all the bases.
Click to expand...
Click to collapse
Ok, this makes sense.
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
stejc said:
Please add NetSDR support for RFSpare radios like NetSDR or SDR-IP.
I would pay 10x the Pro price for this! http://sourceforge.net/projects/cutesdr/ and http://cutesdr.svn.sourceforge.net/...face/sdrinterface.cpp?revision=36&view=markup will probably reveal how NetSDR format works.
Click to expand...
Click to collapse
I already have sever requests about this. I will keep this idea in the record. I will first need to make sure SDR Touch is working properly and implement the list of features in the first post.
Also, I was able to rapidly prototype so far but now I'm back in University and I am forced to slow down the development speed. So it may take some time.
Any chance to make the whole app Open Source? This would be a nice recognition of the hard work done by the rtl-sdr folks, and solve your packaging problem.
I have licensed APRSdroid (which btw. can modulate and demodulate Packet Radio using audio in/out) under the GPL, and I can not complain about people not getting the paid version from Google Play.
To the contrary, 80% of my users actually bought the app, and all without evil nag screens!
martintzvetomirov said:
Actually this won't be a bad idea after all, I mean if there is a separate app "rtl_tcp_andro" that can do I/Q samples, this might help other developers write their own SDR based applications so therefore help the community.
Click to expand...
Click to collapse
Absolutely. That is the idea behind the GPL in the first place, that other developers can benefit from improvements made to the code. Having a separate download for rtl_tcp_andro would definitely be a positive for the community, I could personally think of a couple interesting projects with it.
martintzvetomirov said:
I don't want to release the processing bit under GPL since it took me quite some time to optimize the algorithms to run on Android so I want to keep my work with this private and this is what Pro users are paying for but rtl_tcp_andro is in the public domain anyways, I will just wrap it around with an apk and release it under GPL.
Click to expand...
Click to collapse
Of course, it's your right to keep your own software closed source. I don't personally believe in keeping this kind of software closed, but it's your decision.
Though I would like to point out that this type of software is going to get paid downloads either way. The type of users you will attract with this kind of software are the same kinds of users who have no problem donating to open source projects. We aren't talking about some casual game here that just anyone will be downloading, this is an application developed for more technical users who have a pretty good idea of the amount of effort that goes into a project like this.
In any event, I'm glad to see you taking the proper steps to make sure your software is GPL compliant.
FUNcube Pro & FUNcube Pro Plus Support
Any chance FUNcube Pro & FUNcube Pro Plus Dongles Support can be added in the future.
AnJaRoot stands for Android Java Root, and it's just that - a replacement for the previous generation of supersuer access on Android. The days of calling su to execute scripts in a limited environment are over, developers are now able to perform previously restricted actions directly from Java!
This is the official Developer Support Thread for the AnJaRoot Library - Please focus your post on the Library, everything about the app should go here.
For more informations about AnJaRoot, please visit main thread or go to http://www.anjaroot.net/.
Getting Started
To start using the AnJaRoot Library, download it from the main thread or from the homepage. You will need the AnJaRoot-Library.jar, optionally also the provided JavaDoc jar. Integrate it as a dependency in your app and you are ready to go!
Resources
I'ts always easier to start with a sample and some documentation at hand. I've started the AnJaRootTester project to serve as a reference for the library usage as well as testing if AnJaRoot is correctly running and installed on a device. While it's not the cleanest app the world has ever seen, it shows pretty good how to integrate AnJaRoot into your app.
You may also like the online library documentation.
Feel free to post anything which is related to the library itself and happy hacking!
Luminger said:
AnJaRoot stands for Android Java Root, and it's just that - a replacement for the previous generation of supersuer access on Android. The days of calling su to execute scripts in a limited environment are over, developers are now able to perform previously restricted actions directly from Java!
Click to expand...
Click to collapse
Nice! And very different from how I implemented Java code support in RootTools.
A question regarding your NOTES file: you write that setresuid() is inlined. Where is it inlined? If you use LD_PRELOAD, your own library will be hit first, and you can ask the compiler not to inline your code.
Yea, it turned out pretty simple I think
After reading the NOTES file again, I have to say that I was wrong on the comment placed there regarding inlines getresuid()/getresgid() calls.
You are right, your library will be hit first when it comes to external symbol resolve. But this only works for dynamically linked symbols, not for anything which is inlined or comming directly from the executable. I'm currently evaluating switching to ptrace() to place my capset() hook as it would interop with Xposed without it even knowing - so it may become obsolete soon anyway.
I can remember that I poked around in the compiled libraries pulled from my device, searching for external symbols I could replace. I looked at the wrong files and assumed that the compiler inlined those calls. Looking back this conclusion is so wrong, it would be awful if the compile would inline calls to shared library symbols
AnJaRoot 1.1.0 is now compatible with Xposed. It can be downloaded from http://anjaroot.net or the main AnJaRoot thread here at XDA.
You have to reinstall it via the provided update.zip to get Xposed compatibility. The library change is upward compatible, updating is recommended but not needed.
Hey guys,
We are working on InstaReloader - the development tool that reloads class and resource changes on the fly while developing the Android application.
Its purpose is to minimize the time consumed by the application rebuilds and reinstalls during development.
Right now supported features are:
Adding and reloading regular and inner classes.
Refreshing changes in method bodies, adding and removing methods.
Adding and removing variables, constants.
Reloading changes in layouts, menus and other stuff in res directory.
Here is a short demo of InstaReloader:
Prototype android layouts on the fly demo:
What features are also needed? How many times per day do you rebuild & restart the app? We would like to add some reloading functionality to the popular frameworks and it would be great to hear your feedback
You can download InstaReloader form here: Android hotswap tool
Pre configured Eclipse sample project
Pre configured Android Studio - Gradle sample project
Looks quite awesome, it would save me a lot of time every day.
When do you plan to publish? Will it be opensource?
Archimano said:
Looks quite awesome, it would save me a lot of time every day.
When do you plan to publish? Will it be opensource?
Click to expand...
Click to collapse
It is too early to think about the final, though alpha will be released soon. Right now class reloading is pretty stable but layouts reloading is a pain in the [email protected] Would you like to participate?
The good news:
We improved layout reloading. Now you can add onClickListeners in the Java code for newly added elements and be able to interact with changes almost instanlty!
Planning to add support for Intellij IDEA soon.
and Intellij IDEA is supported now
This app can be used for all android roms? Or it has some requirements and support only some android devices?
Sent from my HTC Desire using xda app-developers app
siavash2death said:
This app can be used for all android roms? Or it has some requirements and support only some android devices?
Sent from my HTC Desire using xda app-developers app
Click to expand...
Click to collapse
I think should work almost an all ROMs, depends how significant it changes from the original android's one. So far I've successfully tested class reloading on LG, Samsung, HTC, ASUS devices with original ROMs.
With Layout reloading it's a bit harder because usually this part is "fragmented" so need to create a separate plugin for each brand.
new features demo video is added
Just uploaded another awesome demo video to YouTube! Android layouts can be prototyped on the fly:
http://www.youtube.com/watch?v=ogatWLZA4yQ
We've sent closed beta release to first participants today! It will be available on the XDA soon!
Made the configuration doc. It's quite big so posting link only: http://www.instareloader.com/instalation-configuration/. We will drop some steps in the next version.
ART
I wonder is dynamic class loading possible in ART aka dalvik 2.0 We will check and try to find a solution after receiving the new nexus with the 4.4
InstaReloader 1.5.1 is ready. It contains better logging and bug fixes.
InstaReloader 1.5.1 is now public. Here is a direct download link to this Android code hotswap utility
Implemented cool new feature. InstaReloader can be started from the test-project. Only one entry should be added to the manifest file. Will release 1.6.0 after documentation is ready.
InstaReloader works on KitKat with ART!
InstaReloader 1.6.0 is released!
Download it here: http://www.instareloader.com/download
InstaRelaoder 1.6.1 is released! Now it has support for Android Studio and Gradle.
Check the new demo app: AS-Gradle sample app
Someone have the source of this Tool?
All links are gone.
onolox said:
Someone have the source of this Tool?
All links are gone.
Click to expand...
Click to collapse
I was wondering the same thing. Very quietly this project just disappeared. I wonder if there is anything on github from it?
I think the developer has been contracted by jrebel.
But i'm working in a open source project that does the same thing:
http://forum.xda-developers.com/and...ap-res-src-t3243653/post63713718#post63713718
H,
Currently in the process of trying to edit the NFC source files of Java to change some of the functionality of the HCE feature of Android versions 4.4 and above.
I've downloaded the source and installed a custom version of AOSP to my Nexus 7, and am now looking to start adding my own code. However, when looking at how these source files are used/called i'm running into some trouble.
Are there any Kernel Trace programs available, to see what files/functions are being called and in which order, so I can start looking to add my own modifications to the source?
Any help is appreciated,
Thanks - Jay
XPosed
If the Java part of HCE is all you are interested in you may want to give a try to the Xposed framework [1].
The framework will allow your app to hook into any JAVA system call on a rooted device. You can e.g. hook into HostEmulationManager.notifyHostEmulationData and log or even manipulate any APDU received. You will find a short tutorial at [2]. At [3] you will find a small Xposed module targeting HCE. It is a new framework but no big deal after all.
I'm interested in HCE too and gained some experience over the last weeks so what exactly are you trying?
[1]
http://repo.xposed.info/
[2]
http://forum.xda-developers.com/showthread.php?t=2709324
[3]
http://forum.xda-developers.com/showthread.php?t=2573430
Hi Thomas
Essentially at my university, we have student cards that are MiFare Classic 1/4k RFID cards, that when placed up against a scanner outside of buildings/labs, scans the UID of the card and checks if the student is allowed access.
When Emulating a tag on an Android device, the UID (Not the AID) is randomly set. This is (I believe) set in the libnfc-nci code at the lower levels of Android, and so will require modifications at that level, and the levels above to allow me to pass a specific UID down the Android stack that will then be set.
I asked a similar question on Stackoverflow and got the following response:
http://stackoverflow.com/questions/28409934/editing-functionality-of-host-card-emulation-in-android
Essentially i'm looking for a way to find out what code is called when HCE is turned on, to find where the UID is set - after that I can look at passing down my own ID down from an app to set it myself.
Hello all,
(Note to mods: I'm too junior to post in Android Dev fora, so please someone move my post, I believe it's worthwhile as this is really useful)
I've updated my little known but highly useful 'bin dump' tool to work on Android 9 and later. This tool is like "service", able to list services, but not just In the normal namespace - also in the vndbinder (though that requires root).
The primary use of this tool is to list who's actually holding or using the service. There's a full explanation on how I accomplish this at the webpage - newandroidbook.com/tools/bindump.html (mods: please make this a link? I can't). This way you can see who's using "power", for example (i.e. holds wake locks) , or "SurfaceFlinger" (i.e. has activity views) or "activity" (i.e is an activity/service/broadcast receiver).
Unfortunately, the advanced use requires root, due to binder's debugfs entries being chowned and chmodded nowadays.
The tool DOES NOT use libbinder, and I effectively rewrote the whole thing in pure C with the low level ioctl()s. I support Android 9 and onwards (if you need insights to the parcel format, which changed three times in between these versions.. let me know). Should work everywhere - That said, I've seen idiosyncrasies in Samsung devices which I've accounted for. Feedback more than welcome.
I need a 32bit version , is source available?
Tool is not open source (too much secret sauce and re-implementation of libBinder from scratch) but I built a bdsm.armv7 binary and linked it from the download page
(direct: http://NewAndroidBook.com/tools/bdsm.armv7)
Thanks , will try that out