I've made app that allows me to connect to bluetooth le device and lists all services and characteristics. However the only recognized service is 'Device Information Service', there is also 'Unknown Service' but it doesn't seem to pass data that im looking for. I'm sure that device is working properly because official app that was attached to the device works fine. What could be the problem? Is it possible that information that im looking for are passed in unknown service and are somehow encrypted?
Your app correctly discovers the services, the problem isn't there. The problem is that you expect the service to be a generic one but it isn't, it's a vendor specific service.
A vendor specific service (characteristic) is easily recognizable : Its UUID is 128 bits long. Also it's not resolved by generic BLE apps such as nRF Connect for the simple reason that they are specific and not generic.
When a company sells a device that implements generic services, they know that it will work with multiple applications but they also know that these applications will also work for the other devices from their competitors. By example, you can buy a heartrate belt from several companies and use them with several fitness apps on your smartphone.
When a company sells a device that implements vendor specific services, they know that it will not work with another application than their own one and that not any competitor will be able to sell a device that also works with their application.
Two different strategies, many different goals.
Basically, the company that designed the device you are playing with did not want you to be able to use another app than their own app to access the data in the device. It's that simple.
Now you still can reverse engineer their service. Use a sniffer, compare the data transferred when using their app with the data actually displayed in the app and maybe you'll find some logic, and learn the hard way how they have hidden the data in their service. However they probably have some clause stating you shall not reverse engineer this or that.
You can see the generic services here, but you won't learn anything more than what I've said : BLE GATT Services
Related
I'm developing a mobile app that uses WiFi without internet connection (in order to communicate to an IOT device) and it uses cellular data as well (see TL;DR section for more).
The problem -> some devices don't automatically switch their default route to cellular (rmnet interface) while others are capable.
The workaround -> create a *"local" VPN in order to manage and re-routing network traffic via cellular interface (there are apps like Speedify that can do this by assigning priority to interfaces)
The question -> there is a simple way to accomplish this or it's pretty tricky? When I say "simple" I mean the calls of several well documented API and when I say "tricky" I mean to starting read and parse routing table with customized rules depending on every vendors?
"*local" = a VPN without web server or VPN gateway because I'm not actually interested to do the VPN's job (I seem to have understood that I need a VPN level to manage network traffic of others app but I'm pretty newbie of VPN topic)
TL;DR
My goal is to remaining connected to my access point (in order to call its APIs) AND use cellular data for all others requests I.e: login via my backend, use Google Maps and so on.
Handle this scenario it's quite easy because combining network objects, socketFactory and bindProcessToNetwork I'm able to do this.
Troubles come for others app like YouTube, WhatsApp that stop working because as default network they are using my access point without internet (Android doesn't switch default interface to a cellular)
I'm going crazy because seems that each vendor (or Android OS version?) handles "WiFi without connectivity" with cellular active in a different way.
There are certain devices that all work fine (similar to iOS) but there are others that it's a nightmare.
See this question for further details
Thanks for reading, I really love Android but those issues make me sadder every day more and I'm thinking to pass to the Dark Side of mobile development (iOS).
You've the chance to change my mind ;)
I'm trying to write a cross-platform abstraction over Bluetooth. When it comes to identifying devices (or peripherals, as iOS calls them), I'm a bit stumped.
iOS includes an identifier property, which is a generated ID assigned to a device the first time it connects. However, Android does not seem to have an equivalent concept. The best I seem to be able to do is to use BluetoothDevice.getAddress, which returns a MAC address. I can then turn that into a UUID by doing some byte twiddling.
Is there anything better I can do here to uniquely identify devices in an agnostic manner?
As you already noticed, you cannot use the identifier property to identify a device on iOS.
The correct way to do this is to advertise a service with a characteristic's value you can control on device A and discover this on the device B.
Depending on what you want to achieve, there are also SDKs you can use for device discovery, for example newaer, p2pkit or google nearby just to name a few.
Disclaimer: I work for Uepaa, developing p2pkit.io for Android and iOS.
My application need to create multi-group wifi-direct communication.But after testing I find that none of the following scenarios are feasible in Android:
1) a device plays the role of P2P client in one group and GO in another.
2) a device behaves as client in two or more groups.
I want to ask does the google have the plan to update the android Wifi-Direct API for suppporting one of above, so that we could implement multi-group communication easily?
Or are there some ways for two wifi-direct group communication with each other in android?
Thanks!!!!!!!!!!!!!!!!
Simple answer for all questions would be: No. though the second question it would be that As far as I know, No.
Anyway, if your logic requires you to be able to be GO & Client same time, then you could work around this by creating normal access point, where clients would connect to, and you could connect to other devices access point.
For access point, you could for example use the CreateGroup function, which would create hidden access point. Then you could use the Wifi Direct service advertising for delivering the password & SSID alongside IP-Address to other devices, so they could discover access points and connect to them.
I have to develop an android application that has to get all mobile devices info in same Telco BTS as mine phone. Can I get all other mobile devices cell IDs?
In the comments you mention your requirement is 'I only have to send a broadcast to all the neighboring mobile devices'.
There is actually a solution built into most deployed GSM networks to do this already - it is called Cell Broadcast (or sometimes SMS-CB).
It is usually intended for emergency situations and allows an operator to send a message to all the devices in a given cell efficiently and even when the network is congested.
There is also a newer standard eMBMS which is similar concept but designed for multimedia broadcast, so maybe suitable to more commercial applications. This is not so well deployed at the moment, AFAIK.
Either way, the API's are in the Telco's domain and not available to a device unless the Telco has provided a special service for this.
As others have pointed out, a regular Android device will not have the ability to discover all its peers or to message everyone in the same cell, although a telco could provide a web service that the device could call if they wished.
The division between the 'phone' part of an Android phone and the 'app or computer' part of the device is strictly defined in Android - the intent is not only to protect privacy etc but also to protect the phone functionality and the network from malicious or malfunctioning apps.
I'm currently doing some research about my project, a smartphone tracking native application, and I have four questions. Links to any material I can read up will be greatly appreciated, and the most useful/comprehensive response will be accepted.
The primary target smartphones are the Android, Blackberry and iPhone models.
For starters I found out here Uniquely Identify an Android Handset that IMEI can be used to uniquely identify Androids but I think I once read that it can be faked. I don't know about the iPhone and Blackberry.
What's the most reliable way to uniquely identify the smartphone device, if any? Can MAC addresses work or is it possible to spoof that? Can IMEIs truly be faked?
Is it possible to "lock" the device with a custom error message remotely via its unique identification, once the device is reported as stolen? This lock state will remain on the phone even when disconnected from the network, until it is reconnected to the network and unlocked remotely once again.
Assuming such a remote phone lock is possible, can such be reversible by the thief? The native app will run in stealth mode so that it cannot be uninstalled.
Can a cross-platform solution work in this case, or will I have to develop various native apps per platform?
EDIT:
Some more context. As Till rightly said, Apple's "Find my Phone" does this exact thing already (I am just finding out about it, but it looks like a perfect fit already). The user who is choosing to install the app is informed that the phone will be uniquely identified if they do install the app. As for locking the device, "Find my Phone" does it (I gather). Now I need to know how that might be possible on the two other platforms.
With regards the iPhone side of things:
You aren't allowed to uniquely identify the iPhone like that. Apple have just forbidden it unless you get the user's permission first. So if they refuse you permission, your app won't function and you'll need to find another way.
No, you can't do that.
See 2. Also you can't run an app in "stealth mode"
See 2.
Only the network operators can talk to the handsets on an IMEI level. The IMEI number IS the MAC address of GSM networks. However, you can't access that unless you have control of the network. Sure you can get the IMEI from the user, but you can't use that to locate the phone. On CDMA networks this address is called the MEID number.
But there are other ways:
You can get location data on either platform with the users' permission. This is the way you should think about developing your application. You'll want to assign a UUID to a user once they download and install your application on their phones. You can then have the phones report to a server every so often (heartbeat). As long as the phone is powered on and connected to a network, the user would be able to locate the phone.
You can also get the phones IP address on the network, among other things -- such as contacts, messages, files, cache data etc..
On Android it's pretty easy to implement this kind of functionality as a service that could would only be visible on the packages page. Further, if you have root access, you can write whatever kind of rootkit you want such that it hides itself from the system. Same with a jailbroken iPhone. I am not as knowledgeabe about iPhone services though.
Either way, the only cross platform compatibility you'd be able to exploit would be perhaps the way data is sent and received from the server. You could use some standard such as JSON to send and receive data (and hence the same server). Although, both platforms have JSON and Apache libraries, the other parts of the apps or services themselves will need to be completely and dependently developed for each platform (UI, Internal Content Handeling, Syscalls, Permissions, etc).
You can remotely lock, wipe, factory reset, etc. Android devices using the security and device administration Android system interface. This still requires the user to grant permission and it asks them an a more.. obnoxious.. way so that they know what exactly they are agreeing to when they give an app device administration permission. If you ever use an exchange server for business or school, it's likely you'll run into this.
I am unsure about remote iPhone device administration on a jailed system.
If you really want something that can't be removed lest you do a factory reset, you'll need to know a thing or two about Unix programming, and a lot about the operating systems that their respective SDK's don't (and probably shouldn't) tell you. You'll need to be comfortable poking around sources and even reverse engineering if called for. If you're still interested, you'll want to hang around the circles that work on custom phone firmware and software for the iPhone, and Android (and Blackberry). I would start with Android. It's probably the easiest since the sources for the AOSP are easily and legally available.