Access network from android

Android — Network Connection

Android lets your application connect to the internet or any other local network and allows you to perform network operations.

A device can have various types of network connections. This chapter focuses on using either a Wi-Fi or a mobile network connection.

Checking Network Connection

Before you perform any network operations, you must first check that are you connected to that network or internet e.t.c. For this android provides ConnectivityManager class. You need to instantiate an object of this class by calling getSystemService() method. Its syntax is given below −

Once you instantiate the object of ConnectivityManager class, you can use getAllNetworkInfo method to get the information of all the networks. This method returns an array of NetworkInfo. So you have to receive it like this.

The last thing you need to do is to check Connected State of the network. Its syntax is given below −

Apart from this connected states, there are other states a network can achieve. They are listed below −

Sr.No	State
1	Connecting
2	Disconnected
3	Disconnecting
4	Suspended
5	Unknown

Performing Network Operations

After checking that you are connected to the internet, you can perform any network operation. Here we are fetching the html of a website from a url.

Android provides HttpURLConnection and URL class to handle these operations. You need to instantiate an object of URL class by providing the link of website. Its syntax is as follows −

After that you need to call openConnection method of url class and receive it in a HttpURLConnection object. After that you need to call the connect method of HttpURLConnection class.

And the last thing you need to do is to fetch the HTML from the website. For this you will use InputStream and BufferedReader class. Its syntax is given below −

Apart from this connect method, there are other methods available in HttpURLConnection class. They are listed below −

This method releases this connection so that its resources may be either reused or closed

This method returns the request method which will be used to make the request to the remote HTTP server

This method returns response code returned by the remote HTTP server

This method Sets the request command which will be sent to the remote HTTP server

This method returns whether this connection uses a proxy server or not

Example

The below example demonstrates the use of HttpURLConnection class. It creates a basic application that allows you to download HTML from a given web page.

To experiment with this example, you need to run this on an actual device on which wifi internet is connected .

Sr.No	Method & description
1

Steps	Description
1	You will use Android studio IDE to create an Android application under a package com.tutorialspoint.myapplication.
2	Modify src/MainActivity.java file to add Activity code.
4	Modify layout XML file res/layout/activity_main.xml add any GUI component if required.
6	Modify AndroidManifest.xml to add necessary permissions.
7	Run the application and choose a running android device and install the application on it and verify the results.

Here is the content of src/MainActivity.java.

Here is the content of activity_main.xml.

Here is the content of Strings.xml.

Here is the content of AndroidManifest.xml

Let’s try to run your application. I assume you have connected your actual Android Mobile device with your computer. To run the app from android studio, open one of your project’s activity files and click Run icon from the tool bar. Before starting your application, Android studio will display following window to select an option where you want to run your Android application.

Select your mobile device as an option and then check your mobile device which will display following screen −

Now just click on button, It will check internet connection as well as it will download image.

Out would be as follows and it has fetch the logo from internet.

Источник

Android Networking — Tutorial

Performing HTTP operations with Android. This article describes how to access web resources via HTTP in Android.

1. Overview of network access on Android

1.1. Accessing the network in Android

Within an Android application you should avoid performing long running operations on the user interface thread. This includes file and network access.

The Android system crashes your application with a NetworkOnMainThreadException exception, if you access network is accessed from the main thread.

Android contains the standard Java network java.net package which can be used to access network resources. The base class for HTTP network access in the java.net package is the HttpURLConnection class.

Performing network operations with standard Java API can be cumbersome. You have to open and close a connections, enable caches and ensure to perform the network operation in a background thread.

To simplify these operations several popular Open Source libraries are available. The most popular ones are the following:

OkHttp for efficient HTTP access

Retrofit for REST based clients

Glide for image processing

Prefer using OkHttp over the usage of HttpURLConnection . It is faster than the standard Java library and has a better API.

1.2. Permission to access the network

To access the Internet your application requires the android.permission.INTERNET permission. On modern Android API versions, this permission is automatically granted to your application.

1.3. Check the network availability

The network on an Android device is not always available. To check the network state your application requires the android.permission.ACCESS_NETWORK_STATE permission. You can check the network is currently available via the following code.

This requires the ACCESS_NETWORK_STATE permission.

2. Web Sockets

Web Sockets are a standard based on HTTP for asynchronous message-based communication between a client and a server. To start a web socket communication, you create a HTTP GET request with a special HTTP headers. If the server accepts this request, the client and the server can send each other messages.

Messages can be text or binary data and should be relatively small, as the web socket protocol is intended to be used with small payloads in the data.

It is good practice to use JSON as data format for the messages.

Источник

Взаимодействие Android-устройств в локальной сети

Предположим, мы пишем игру для Android, которая подразумевает некое сетевое взаимодействие между устройствами. Причем наши устройства находятся в одной сети и мы хотим, чтобы взаимодействие между ними осуществлялось быстро, а значит вариант с обменом данными через интернет нам не подходит. Ах да, еще одна маленькая ложка дегтя — мы хотим охватить максимально возможную аудиторию, для чего нам необходимо поддерживать Android 2.3.
Что же нам делать? Давайте поговорим об этом, а заодно рассмотрим относительно новые возможности Android SDK для соединения двух и более устройств.

О чем это и для кого это?

Как-то раз, уйдя с предыдущего места работы и погрузившись в заслуженный отдых, я принялся писать сетевую игру, в которую могут играть люди, находящиеся в одной локальной сети. И сразу же столкнулся с тем, что для нормального функционирования подобной игры нам мало соорудить сетевое взаимодействие — нам нужно сделать нормальное и быстрое обнаружение устройств в сети. Собственно, в данной статье я поделюсь своим опытом в реализации решения для данной задачи.
Сразу оговорюсь, что статья предназначена в большей мере для тех, кто имеет опыт Android-разработки, написал несколько приложений и хочет расширить свой кругозор, а также улучшить профессиональные навыки.

Какие возможные способы решения существуют?

1. Android Network Service Discovery. Простой и эффективный способ обнаружения устройств. На Android Developer есть пошаговое руководство по подключению NSD, есть пример NsdChat, который можно скачать там же. Но есть один существенный минус — данный метод поддерживается только начиная с API Level 16, то есть с Android 4.1 Jelly Bean;
2. Второе решение, предлагаемое нам на сайте Android Developer — Wi-Fi Peer-to-Peer. Проблема этого метода та же самая — поддерживается он только начиная с API Level 16;
3. Есть странное решение, которое предлагается некоторыми программистами на Stack Overflow — самостоятельно сканировать локальную сеть на предмет наличия сервера. То есть проходить по всем адресам сети. Это уже сейчас звучит как странный велосипед, а теперь представьте, что порт нашего сервера назначается автоматически. Таким образом, сканирование даже самую небольшой сети становится достаточно долгой и трудоемкой задачей;
4. Наконец, мы можем обратить внимание на Java-библиотеки и написать что-нибудь с их использованием. Например, JmDNS.

Последний способ выглядит вполне адекватным и, кажется, может обеспечить нас требуемой скоростью и удобством обнаружения устройств в сети для конечного пользователя.

Я вооружился JmDNS и решил попробовать соорудить несколько классов, которые по максимуму упростят написание описанных выше приложений. Но для начала пришлось немного повырезать дубликаты .class-файлов из jar-пакета JmDNS (проблема описана здесь):

Далее я взял исходный код NsdChat с Android Developer и изменил его служебный класс, который отвечает за инициализацию сокетов и организацию сетевого взаимодействия. Также я написал wrapper для JmDNS

Здесь размещены 4 основные функции для работы Network Discovery:

1. startServer для создания сервера и регистрации соответствующего сервиса в локальной сети;
2. findServers для поиска серверов;
3. reset для окончания работы с Network Discovery и последующего освобождения ресурсов;
4. wifiLock для запроса блокировки Wi-Fi.

В завершении я написал универсальный класс ConnectionWrapper для полноценной организации обнаружения, а также обмена сообщениями в локальной сети. Таким образом, создание сервера в конечном приложении выглядит следующим образом:

А вот и mServerHandler, использующийся для приема и обработки сообщений:

Отправка сообщений еще проще:

И, наконец, метод для обнаружения и подключения к серверу:

Как видите, все очень просто. А главное, все это работает в любой версии Android для максимум двух устройств. Но сделать так, чтобы это работало для условно неограниченного числа устройств очень легко, и очевидное решение придет к вам почти сразу после детального изучения класса Connection. Пусть это будет в качестве домашнего задания.
Ах, да, весь код доступен для изучения и использования всеми желающими в моем репозитории на GitHub.. И, конечно, не исключаю то, что некоторые вещи можно сделать лучше и проще, поэтому не стесняйтесь форкать и делать pull request’ы.

Источник

Wi-Fi и много других аббревиатур. Как в Android приложении получить данные об узлах Wi-Fi и не опухнуть

Однажды мне понадобилось сканировать из Android приложения сети Wi-Fi и получать подробную выкладку данных о точках доступа.

Тут пришлось столкнуться с несколькими трудностями: в офф.документации Android многие описанные классы стали deprecated (API level > 26), что никак не было в ней отражено; описание некоторых вещей в документации минимально (например поле capabilities класса ScanResult на момент написания не описано почти никак, хотя содержит много важных данных). Третья сложность может заключаться в том, что при первой близости с Wi-Fi, отличной от чтения теории и настройки роутера по localhost, приходится иметь дело с рядом аббревиатур, которые кажутся понятными по отдельности. Но может быть не очевидно, как их соотнести и структурировать (суждение субъективно и зависит от предыдущего опыта).

В данной статье рассмотрено как из Android кода получить исчерпывающие данные о Wi-Fi окружении без NDK, хаков, а лишь с помощью Android API и понять, как их интерпретировать.

Не будем тянуть и начнем писать код.

1. Создаем проект

Заметка рассчитана на тех, кто больше одного раза создавал Android проект, поэтому подробности данного пункта опускаем. Код ниже будет представлен на языке Kotlin, minSdkVersion=23.

2. Разрешения на доступы

Для работы с Wi-Fi из приложения понадобится получить от пользователя несколько разрешений. В соответствии с документацией, для того, чтобы осуществить сканирование сети на устройствах с ОС версий после 8.0, помимо доступа к просмотру состояния сетевого окружения нужен либо доступ на изменение состояния модуля Wi-Fi устройства, либо доступ к координатам (примерным или точным). Начиная с версии 9.0 необходимо запросить у пользователя и то и то, и при этом явно запросить у пользователя включить службу определения местоположения. Не забываем галантно объяснять пользователю, что это прихоть компании Google, а не наше желание устроить за ним слежку 🙂

Итого, в AndroidManifest.xml добавим:

А в коде, в котором есть ссылка на текущую Activity:

3. Создаем BroadcastReceiver и подписываемся на события обновления данных о сканировании сетевого окружения Wi-Fi

Метод WiFiManager.startScan в документации помечен как depricated с версии API 28, но офф. guide предлагает использовать его.

Итого, получили список объектов ScanResult.

4. Смотрим на ScanResult и разбираемся в терминах

Посмотрим на некоторые поля этого класса и опишем, что они означают:

SSID — Service Set Identifier – это название сети

BSSID – Basic Service Set Identifier – MAC адрес сетевого адаптера (Wi-Fi точки)

level — Received Signal Strength Indicator [dBm (русское дБм) — Децибел, опорная мощность 1 мВт.] — Показатель уровня принимаемого сигнала. Принимает значение от 0 до -100, чем дальше от 0, тем больше мощности сигнала потерялось по пути от Wi-Fi точки к вашему устройству. Подробнее можно посмотреть например на Википедии. Здесь же расскажу, что с помощью Android класса WifiManager можно проградуировать уровень сигнала по шкале от отличного до ужасного с выбранным вами шагом:

frequency — частота работы точки Wi-Fi [Гц]. Помимо самой частоты вас может заинтересовать так называемый канал. У каждой точки есть своя рабочая чистота. На момент написания текста наиболее популярным диапозоном Wi-Fi точек является 2.4 GHz. Но, если быть точнее, точка передает информацию на ваш телефон на пронумерованной частоте, близкой к названной. Количество каналов и значения соответствующих частот стандартизованы. Это сделано для того, чтобы точки поблизости работали на разных частотах, тем самым не создавая помехи друг другу и взаимно не понижая скорость и качество передачи. При этом точки работают не на одной частоте, а на диапазоне частот (пареметр channelWidth), называемом шириной канала. То есть точки, работающие на соседних (и не только на соседних, а даже на 3 от себя) каналах создают друг другу помехи. Вам может пригодится этот незамысловатый код, который позволяет вычислить номер канала по значению частоты для точек с частотой 2.4 и 5 Ghz:

capabilities — наиболее интересное поле для анализа, работа с которым потребовало много времени. Тут в строку записываются «возможности» точки. При этом подробности интерпритации строки в документации можно не искать. Вот несколько примеров того, что может лежать в этой строке:

5. Разбираемся в аббревиатурах и парсим capabilities

Стоит упомянуть, что классы пакета android.net.wifi.* использует под капотом linux-утилиту wpa_supplicant и результат вывода в поле capabilities является копией поля flags при сканировании.

Будем действовать последовательно. Рассмотрим сначала вывод такого формата, при котором внутри скобок элементы отделены знаком «-«:

Первое значение описывает т.н. метод аутентификации (authentication). То есть, какую последовательность действий должны произвести устройство и точка доступа, чтобы точка доступа позволила собой пользоваться и каким образом шифровать полезную нагрузку. На момент написания поста самые частые варианты это WPA и WPA2, при котором либо каждое подключаемое устройство напрямую, либо через т.н. RADIUS-сервер (WPA-Enterprice) предоставляет пароль по зашифрованному каналу. Скорее всего у вас дома точка доступа предоставляет подключение по этой схеме. Отличие второй версии от первой в болеее стойком шифре: AES против небезопасного TKIP. Также постепенно внедряется WPA3, более сложный и продвинутый. Теоритически может встретиться вариант с enterprice-решением CCKM (Cisco Centralized Key Managment), но мне так и не встретился.

Точка доступа могла быть настроена на аутентификацию по MAC-адресу. Или, если точка доступа предоставляет данные по устаревшему алгоритму WEP, то аутентификации фактически нет (секретный ключ тут и является ключом шифрования). Такие варианты отнесем к типу OTHER.
Ещё есть полюбившийся в общественных wi-fi метод со скрытым Captive Portal Detection — запрос аутентификации через браузер. Такие точки доступа выглядят для сканера как открытые (какими с точки зраения физического подключения и являются). Поэтому отнесем их к типу OPEN.

Второе значение можно обозначить как алгоритм использования ключей (key management). Является параметром метода аутентификации, о котором написано выше. Говорит о том, как именно происходит обмен ключами шифрования. Рассмотрим возможные варианты. EAP — используется в упомянутом WPA-Enterprice, использует базу данных для сверки введеных аутентификационных данных. SAE — используется в продвинутом WPA3, более устойчива к перебору. PSK — самый частый вариант, подразумевает ввод пароля и его передачу в зашифрованном виде. IEEE8021X — по международному стандарту (отличному от поддержанным семейством WPA). OWE (Opportunistic Wireless Encryption) является расширением стандарта IEEE 802.11, для точек, которые мы отнесли к типу OPEN. OWE обеспечивает безопасность данных, передаваемых по незащищенной сети, за счет их шифрования. Также возможен варинант когда ключей доступа нет, назовем такой вариант NONE.

Третьим параметром является т.н. метод шифрования (encryption schemes) — как именно используется шифр для зашиты передаваемых данных. Перечислим варианты. WEP — использует поточный шифр RC4, секретный ключ является ключом шифрования, что в мире современной криптографии считается неприемлемым. TKIP — используется в WPA, CKIP — в WPA2. TKIP+CKIP — может быть указан в точках умеющих WPA и WPA2 для обратной совместимости.

Вместо трех элементов можно встретить одинокую пометку WEP:

Как мы обсудили выше, этого достаточно чтобы не конкретизировать алгоритм использования ключей, которого нет, и метода шифрования, которое одно по-умолчанию.

Теперь рассмотрим такую скобочку:

Это режим работы Wi-Fi или топология сетей Wi-Fi. Вам может встретиться Режим BSS (Basic Service Set) — когда есть одна точка доступа, через которую общаются подключенные устройства. Можно встретить в локальных сетях. Как правило точки доступа нужны для того, чтобы соединять устройства из разных локальных сетей, поэтому они являются частью Extended Service Sets — ESS. Тип IBSSs (Independent Basic Service Sets) говорит о том, что устройство является частью Peer-to-Peer сети.

Ещё может попасться флаг WPS:

WPS (Wi-Fi Protected Setup) — протокол полуавтоматической инициализации сети Wi-Fi. Для инициализации пользователь либо вводит 8-символьный пароль, либо зажимает кнопку на роутере. Если ваша точка доступа относится к первому типу и этот флажок высветился напротив имени вашей точки доступа, вам настоятельно рекомендуется зайти в админку и отключить доступ по WPS. Дело в том, что часто 8-значный PIN можно узнать по MAC-адресу, либо перебрать за обозримое время, чем кто-то нечистый на руку сможет воспользоваться.

6. Создаем модель и функцию парсинга

На основе того, что выяснили выше опишем data-классами то, что получилось:

Теперь напишем функцию, которая будет парсить поле capabilities:

8. Смотрим результат

Посканирую сеть и покажу, что получилось. Показаны результаты простого вывода через Log.d:

Неосвещенным остался вопрос подключения к сети из кода приложения. Скажу только, что для того, чтобы считать сохраненные пароли ОС мобильного устройства, нужны root-права и готовность порыться в файловой системе чтобы прочитать wpa_supplicant.conf. Если логика приложения предполагает ввод пароля извне, подключение можно осуществить через класс android.net.wifi.WifiManager.

Спасибо Егору Пономареву за ценные дополнения.

Если считаете, что нужно что-то добавить или исправить, пишите в комментарии 🙂

Источник