1

I've developed an wear os 2.0+ app which communicates with an HTTP API. I'm using Volley to connect to this API, but it only seems to work whenever I've switched bluetooth off. Any requests I make with bluetooth simply timeout. The other end usually respond within miliseconds and returns not more than a few kilobytes.

The documentation states the following regarding networks access:

Wear OS apps can make network requests. When a watch has a Bluetooth connection to a phone, the watch's network traffic generally is proxied through the phone. But when a phone is unavailable, Wi-Fi and cellular networks are used, depending on the hardware. The Wear platform handles transitions between networks.

So from my understanding Android should take care of making sure my requests make it to the other end, either with bluetooth (proxied through phone) or wifi.

The actual code which makes the HTTP request with volley:

public <T> CompletableFuture<T> send(String url, Class<T> type) {
    CompletableFuture<T> requestCompletableFuture = new CompletableFuture<>();

    JsonObjectRequest request = new JsonObjectRequest(Request.Method.GET, url, null,
            response -> {
                T data = serializer.fromJson(response.toString(), type);

                requestCompletableFuture.complete(data);
            }, (ex) -> {
                requestCompletableFuture.completeExceptionally(ex);
    });

    request.setRetryPolicy(new DefaultRetryPolicy(15000,
            0,
            DefaultRetryPolicy.DEFAULT_BACKOFF_MULT));

    requestQueue.add(request);

    return requestCompletableFuture;
}

Android does provide a ConnectivityManager which gives me the ability to request a WIFI network. But creating a high bandwith network which I don't need sounds a bit unnecessary and battery draining what I am trying to prevent.

Zoe
  • 27,060
  • 21
  • 118
  • 148
Jamie
  • 3,031
  • 5
  • 36
  • 59
  • #MeToo Ive been chasing the answer to this forever. if you have seen this post: https://stackoverflow.com/questions/31259692/does-android-wear-support-direct-access-to-the-internet A google engineer confirms all radios are available at all times... but as you found it appares difficult to acheive in practice. – axa Mar 17 '19 at 00:19
  • BTW, Have you been able to do this with ConnectivityManager? Even if so Id like to confirm that is indeed the correct way, it seems rather excessive becuase i belive BT is already a high bandwidth network, just a low power one, not sure. Makes sense the OS wants to shut down power hungry wifi while BT available, but there should be an obvious way to route it. FWIW ive found a very acceptable way around this problem i'd be happy to share once its clear to me this is a real issue and not our misunderstanding. – axa Mar 17 '19 at 00:40
  • I haven't tried the connectivitymanager yet. I will add it to the app today and see if it works. The last option is probably using one of the data layer apps to send requests to the phone to proxy requests. – Jamie Mar 17 '19 at 07:34
  • Please follow up. honestly i couldnt get the Connectitity Manager working and would love to konw if its the right way to do it. – axa Mar 17 '19 at 08:13
  • A quick update. I wrote some code to request a wifi network but it didn't do anything. So I turned on bluetooth debugging (mobile & wear) and noticed one of my API calls never completed. All the other calls worked just fine. I disabled wifi to make sure the api calls were actually proxied to my phone which seems to work. – Jamie Mar 17 '19 at 14:04
  • Sorry I'm sure I don't follow, so you are able to make virtually all calls now? How did you do this? – axa Mar 17 '19 at 19:50
  • Yes I am. The only thing I did is removed a specific API call which seems to never give a response whenever I use bluetooth. For testing purposes I used http://hipsterjesus.com/api/ (it was the first free API I could find..) – Jamie Mar 17 '19 at 19:55
  • So to be clear, 1 you did not implement connectivity manager at all. 2 you are not using any phone companion app to handle any networking... Rather the same wear os app that works on it's own now works when paired and connected to phone with BT. 3 debugging over Bluetooth doesn't influence your results.... Maybe your on to something with a bad call, was there anything particular about this 'bad call' ? – axa Mar 17 '19 at 21:19
  • Yes on all your questions. Im not sure about your last question because the API isnt mine. So I am not sure why it doesnt work with the specific call. The only thing that is different is the content-encoding; chunked in the http response header. Have you tried the api i used as an example? – Jamie Mar 17 '19 at 21:46
  • 1
    Well damn... As you, i hit another vanilla test server and the calls over Bluetooth worked as expected. The problem has been with my production server the whole time... I didn't consider that once as no one has ever had a problem. I truly thank you for the insight. – axa Mar 18 '19 at 04:27
  • Good to hear you fixed your problem! – Jamie Mar 18 '19 at 09:53
  • So ive found my problem is actually http calls over the paried phone bluetooth connection to a LOCAL server seemingly get routed to the internet...?! Its host name wont get resolved, or simply using the local IP address will time out, obviously both are invalid over the internet. At this point im curious if its even possible to hit a LOCAL server when calling over a bluetooth connection – axa Mar 24 '19 at 05:36

1 Answers1

1

Turns out the problem was on the other side. The API just never send a response which caused a time-out everytime I send a request.

I do recommend to test on bluetooth if you face a similar problem.

Jamie
  • 3,031
  • 5
  • 36
  • 59