Related
So... I'm rather new here and I'm not 100% sure that this is the correct forum to post this in (since I know it says "xda developed apps/games only"). However, I have seen commercial Android apps discussed here before... so... *shrug*.
Let me first say that I am not the developer... I just think this app should get some attention.
Pixie Network Monitor by 9bitlabs (would post a link but my account is restricted. ;-) )
It is a network monitoring app similar to Wireshark, but for Android. It is $4.99 on the Android market, it requires root, and it does not work on all phones (since not all phones can have their wifi put into promiscuous mode). There is a companion app called "Pixie Probe" available on the market for free. Pixie Probe will determine whether or not your phone is compatible with Pixie.
I have tested it out on my Evo (running CM6.1 RC1) and it seems to work amazingly well.
Pixie does not contain all of the features of Wireshark/Kismet. This is from the Pixie FAQ:
Q: What's the difference between Pixie and a desktop tool like Kismet?
A: The biggest difference between the tools lies in how they interface with the network. Kismet interacts directly with the wireless adapter and places it in monitor mode, allowing it to hear any packet over the wifi, even if it is not associated with a network. This can be problematic with some hardware, but many of the newer wifi chipsets work great with Kismet.
Pixie, on the other hand, is constrained by Android. Rather than expose the wifi adapter as an 802.11b device, Android actually hides all of that functionality: the wifi connection actually appears to system processes as a plain old Ethernet device. This means that we don't get monitor mode and we also don't get to see wifi-specific data, such as beacons and associate/disassociate packets.
On the plus side, Pixie runs in your pocket and that's harder to do with Kismet, unless you have very large pockets. Pixie is also significantly easier to set up for folks without Linux experience.
Click to expand...
Click to collapse
The Pixie website gives very detailed information about the app, so I suggest you go there if you want more info.
In any case, I hope other people find it useful.
Hello Community,
My question is: What is possibe with the NFC-Interface today?
Only read and write? or
P2P connections?
Card Emulation?
I was looking for a long time...
Thank you
...Geselthyn
Geselthyn said:
Hello Community,
My question is: What is possibe with the NFC-Interface today?
Only read and write? or
P2P connections?
Card Emulation?
I was looking for a long time...
Thank you
...Geselthyn
Click to expand...
Click to collapse
The capability exists in the API as of 2.3.3 for Read and Write capability as well as P2P (there are SDK demos for these three up as well).
The hardware is present (including a secure element) for card emulation, but I can't say with certainty if that's present in the API yet (I don't believe it is).
krohnjw said:
The capability exists in the API as of 2.3.3 for Read and Write capability as well as P2P (there are SDK demos for these three up as well).
The hardware is present (including a secure element) for card emulation, but I can't say with certainty if that's present in the API yet (I don't believe it is).
Click to expand...
Click to collapse
Thank you for your answer. But what exactly means P2P? What is the different to the "read and write"?
Geselthyn said:
Thank you for your answer. But what exactly means P2P? What is the different to the "read and write"?
Click to expand...
Click to collapse
Read and Write allow for the reading of NFC tags and the Writing of NFC tags (format the tags for NDEF messages and write the message contents to the tag).
P2P refers to the fact that NFC can be used to open a communication socket between 2 NFC enabled phones. This socket can then be used to transfer data between the 2 devices.
krohnjw said:
P2P refers to the fact that NFC can be used to open a communication socket between 2 NFC enabled phones. This socket can then be used to transfer data between the 2 devices.
Click to expand...
Click to collapse
Thanks for the new Post
But is it just possible to use the communication between 2 phones?
It's very much possible to initiate P2P communication with any NFC enabled device that supports the NDEF format. P2P communication is not limited to (android) phones.
NDEF is a standard created by the NFC-Forum (= Phillips, Nokia, etc.) and you can expect future NFC phones (including those running Windows Phone or iOS) to also support that standard. I'm of yet unsure how this works with any desktop/terminal readers though... It appears the desktop/terminal must support the 'NPP - NDEF Push Protocol' in order to talk to an Android phone, which android devs say to publish a spec on soon. But I'm unsure why android devs need to publish a spec on communication on the desktop/terminal-end, if it's a standard created by a whole nother group.
Additionally: Card emulation is not supported (yet) in the Android SDK as it's "actually very hard to do this in a consistent way across the Android platform, due to the current hardware architecture of NFC", and I'm not sure how possible it is to share cards with P2P, or achieve any comparable result...
Thanks for the Answer!!!
Is it possible, that you can do more Things with the NDK than with the SDK?
Best Regards,
Geselthyn
I have a European 3G Xoom running EOS ICS 2. We also have an old HP450 Mobile printer that has a slot for a Compact Flash I Bluetooth card. My question is would we be able to set this printer up to print directly from the Xoom?
The details of the Bluetooth card read:
Serial Port Profile (SPP): Emulates a serial port to enable wireless printing from compatible Bluetooth serial sending device(s).
Hardcopy Cable Replacement Profile (HCRP): Provides the same printing experience (print quality and print speed) as when printing with a cable.
Object Push Profile (OPP): Enables printing from devices that use the OBEX (Object Exchange) protocol.
Basic Printing Profile (BPP): Extends the capabilities of the OBEX protocol and lets you print a variety of content from Bluetooth-enabled devices.
Does Android support any of those Bluetooth printing protocols?
Thanks.
Check bigrushdog's tegra 2 thread in Development. There are a ton of drivers available...maybe you'll find the ones you need.
okantomi said:
Check bigrushdog's tegra 2 thread in Development. There are a ton of drivers available...maybe you'll find the ones you need.
Click to expand...
Click to collapse
Thanks for the info but it looks to me as though I would need some programming knowledge to be able to try these out?
lesmorton said:
Thanks for the info but it looks to me as though I would need some programming knowledge to be able to try these out?
Click to expand...
Click to collapse
The easiest you download starprint app from google play and try it. If it works pay few bucks to remove the watermark. it is cool app.
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.
So you want to run your own server, eh? Whether you want to free yourself from data mining, commercialising, monetising, greedy be-tied-and-suited media moguls or from the spiritual successors of J. Edgar Hoover and Yuri Andropov does not matter. You want your data to be just that, *your* data. While this might seem extreme to some the idea is actually not far fetched, nor is it impossible to realise. After all, the 'net and the web were conceived as a decentralised network of services. This model, while good in allowing diversity and freedom, is less than ideal from a profitability standpoint so you should not expect those who stand to profit from hoarding your data to lend a helping hand here You're on your own here.
Well, not really on your own of course as there is a metric ton of information on this subject to be found on the 'net. Everything from how to turn that old laptop into a server through using single-board computers as servers through re-purposing whatever you happened to find dumpster-diving. Suffice to say that you need hardware, software and a network connection. A separate router, preferably one under your own control, running known software (OpenWRT, DD-WRT, Tomato, etc) on stable and not to anemic hardware so it can be used to run a VPN to your phone. You'll want your own domain name as well, either one from the free services which are (still) around or something more 'personal'.
Network connection and domain
Here you often don't have that much choice. If possible, choose a wired connection over a wireless one, both for the higher reliability as well as the usually more acceptable use policies and the fact that wireless connections often change IP address. Choose a connection without a traffic cap over one which has one. Choose the connection with the highest upload rate, even if this means settling on a lower download rate - servers send traffic up the net after all.
There are many ways to get a domain name. You can buy one, of course. For a personal server this might be overkill, but the choice is yours. One advantage of having your own domain is that it enables you to keep your mail/jabber/web/whatever addresses no matter what happens (as long as you pay the registrar, of course). You're totally free here as you can simply point your domain elsewhere if you happen to move to another ISP (and/or country...). Cheaper - as in 'free' - is to use one of the many free dynamic DNS services. As long as you have an address to feed your phone and other devices which will make use of your server you're fine.
Router
Best here is to use a router which is fully under your own control. While some ISP routers might be marginally usable, these devices are often at the whim of the ISP as they can be remotely controlled and configured. This is not what you want for your network, so just use the thing in bridge mode if possible, otherwise forward all traffic to your own router. With one of the free and open router firmwares on a reliable device you can do interesting things, ranging from port knocking on the router to VPN tunnels to your mobile devices.
Hardware, storage
Power consumption. heat- and noise production are of more importance than raw power here. There should be enough memory to keep the thing from paging (or 'swapping') on the intended work load on the chosen OS. The same goes for storage: If it fits in the box, fine. If it does not (external drives on laptops, Raspberries, etc) make sure the whole contraption is stable so you don't get any sudden 'disconnects'. For a personal server, power consumption, noise and heat production (which directly relates to reliability) are - again - more important than raw performance.
OS
Any 'unix' of choice is fine here. Linux, *BSD, doesn't matter. Even MacOS would do. Windows, not so much. It is not impossible to use Windows but it is more of a hassle given that a lot of the software is tailored to a unix environment. If you really insist on running Windows, at least make sure it is patched up to the hilt and that all - and that means all - unnecessary services have been switched off.
Software
This is the interesting bit, and the reason why this message is here in the first place. On one of the forum threads here someone was surprised by the fact that I don't run any of the Google apps on my devices, wondering how I got by without Google Play, GMail, contacts and calendar sync etc. Part of the answer to that question involves running your own server, part is covered by using alternatives for the Google-provided apps and services. I would have put this all in a table but it seems this silly forum does not support those...
Commercial service: Alternative (Remarks)
Google Play: F-Droid (The F-Droid store only contains free software. It does not provide a full alternative to the Play Store. If you really want to run the Play Store but still have a notion of privacy on your device, consider enabling Google Services only when required, disabling them afterwards. You can also designate one device as the one which gets to run the Play Store and side-load apps from this device to all others. Theoretically this should be possible using an emulator on your server as well, automating the whole process and creating a 'playstore by proxy'. I have not tried this.)
GMail: IMAP to your own server, eg the Debian standard dovecot daemon. K9 or the standard Android email client on your device.
Contacts: CardDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Calendar: CalDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Cloud storage (Dropbox, Google Drive, etc): WebDav to your own server (service is provided by ownCloud, amongst others), one of the many webdav clients on your phone. There is a specific ownCloud app as well.
Photo sharing (Flickr, Smugmug, etc): Trovebox to your own server, Trovebox app on phone
Streaming service (Spotify, Google Music, etc): subsonic on your own server, dSub or Subsonic app on phone (there is a rudimentary streaming service in ownCloud as well, based on Ampache)
More will follow...
If you get in the game on time you might be able to join the Reset the Net initiative!
Reserved #2
This position is reserved for a more thorough list of services
Reserved #3
This position is reserved for a more thorough list of services
YetAnotherForumUser said:
Commercial service: Alternative (Remarks)
Google Play: F-Droid (The F-Droid store only contains free software. It does not provide a full alternative to the Play Store. If you really want to run the Play Store but still have a notion of privacy on your device, consider enabling Google Services only when required, disabling them afterwards. You can also designate one device as the one which gets to run the Play Store and side-load apps from this device to all others. Theoretically this should be possible using an emulator on your server as well, automating the whole process and creating a 'playstore by proxy'. I have not tried this.)
GMail: IMAP to your own server, eg the Debian standard dovecot daemon. K9 or the standard Android email client on your device.
Contacts: CardDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Calendar: CalDav to your own server (service is provided by ownCloud, amongst others), DAVdroid on your phone or tablet.
Cloud storage (Dropbox, Google Drive, etc): WebDav to your own server (service is provided by ownCloud, amongst others), one of the many webdav clients on your phone. There is a specific ownCloud app as well.
Photo sharing (Flickr, Smugmug, etc): Trovebox to your own server, Trovebox app on phone
Streaming service (Spotify, Google Music, etc): subsonic on your own server, dSub or Subsonic app on phone (there is a rudimentary streaming service in ownCloud as well, based on Ampache)
More will follow...
More later, no time now,
Click to expand...
Click to collapse
This is an interesting topic mainly because android has the potential to become non dependant of google services and I would be nice to keep personal data really personal.
Also there is a No Gapps project here in xda that is quite interesting.
YetAnotherForumUser said:
Router
Best here is to use a router which is fully under your own control. While some ISP routers might be marginally usable, these devices are often at the whim of the ISP as they can be remotely controlled and configured. This is not what you want for your network, so just use the thing in bridge mode if possible, otherwise forward all traffic to your own router. With one of the free and open router firmwares on a reliable device you can do interesting things, ranging from port knocking on the router to VPN tunnels to your mobile devices.
Click to expand...
Click to collapse
This reminded me of something that happened in my dad's office recently:
http://arstechnica.com/civis/viewtopic.php?f=10&t=1209257
The ISP guys configured it that way because dad wanted to run a webserver on one system, the one directly connected to the modem on bridged mode. They apparently didn't think it was necessary to also add a router betweenthe modem and the network of computers :/
Lessons:
1. Don't trust anything the ISP guys do
2. Always us a standalone router or firewall
3. Don't use XP. Seriously.
TJKV said:
This reminded me of something that happened in my dad's office recently:
http://arstechnica.com/civis/viewtopic.php?f=10&t=1209257
The ISP guys configured it that way because dad wanted to run a webserver on one system, the one directly connected to the modem on bridged mode. They apparently didn't think it was necessary to also add a router betweenthe modem and the network of computers :/
Lessons:
1. Don't trust anything the ISP guys do
2. Always us a standalone router or firewall
3. Don't use XP. Seriously.
Click to expand...
Click to collapse
I can recommend something like this. They come with web-face, but you need have atleast base knowledge of how network things work.
slph said:
I can recommend something like this. They come with web-face, but you need have atleast base knowledge of how network things work.
Click to expand...
Click to collapse
Nah when I realised what the ISP guys had done I bought a D-Link 2750U and set it up properly in NAT mode
Wifi also works now since it isn't bridged to a computer anymore