Файл манифеста AndroidManifest.xml предоставляет основную информацию о программе системе. Каждое приложение должно иметь свой файл AndroidManifest.xml. Редактировать файл манифеста можно вручную, изменяя XML-код или через визуальный редактор Manifest Editor (Редактор файла манифеста), который позволяет осуществлять визуальное и текстовое редактирование файла манифеста приложения.
Назначение файла
- объявляет имя Java-пакета приложения, который служит уникальным идентификатором;
- описывает компоненты приложения — деятельности, службы, приемники широковещательных намерений и контент-провайдеры, что позволяет вызывать классы, которые реализуют каждый из компонентов, и объявляет их намерения;
- содержит список необходимых разрешений для обращения к защищенным частям API и взаимодействия с другими приложениями;
- объявляет разрешения, которые сторонние приложения обязаны иметь для взаимодействия с компонентами данного приложения;
- объявляет минимальный уровень API Android, необходимый для работы приложения;
- перечисляет связанные библиотеки;
Общая структура манифеста
Файл манифеста инкапсулирует всю архитектуру Android-приложения, его функциональные возможности и конфигурацию. В процессе разработки приложения вам придется постоянно редактировать данный файл, изменяя его структуру и дополняя новыми элементами и атрибутами.
Корневым элементом манифеста является . Помимо данного элемента обязательными элементами является теги и . Элемент является основным элементом манифеста и содержит множество дочерних элементов, определяющих структуру и работу приложения. Порядок расположения элементов, находящихся на одном уровне, произвольный. Все значения устанавливаются через атрибуты элементов. Кроме обязательных элементов, упомянутых выше, в манифесте по мере необходимости используются другие элементы.
Описание
Элемент является корневым элементом манифеста. По умолчанию Eclipse создает элемент с четырьмя атрибутами:
Атрибуты
объявляет разрешение, которое используется для ограничения доступа к определенным компонентам или функциональности данного приложения. В этой секции описываются права, которые должны запросить другие приложения для получения доступа к вашему приложению. Приложение может также защитить свои собственные компоненты (деятельности, службы, приемники широковещательных намерений и контент-провайдеры) разрешениями. Оно может использовать любое из системных разрешений, определенных Android или объявленных другими приложениями, а также может определить свои собственные разрешения.
android:name название разрешения android:label имя разрешения, отображаемое пользователю android:description описание разрешения android:icon значок разрешения android:permissionGroup определяет принадлежность к группе разрешений android:protectionLevel уровень защиты
Элемент запрашивает разрешение, которые приложению должны быть предоставлены системой для его нормального функционирования. Разрешения предоставляются во время установки приложения, а не во время его работы.
android:name имеет единственный атрибут с именем разрешения android:name. Это может быть разрешение, определенное в элементе
данного приложения, разрешение, определенное в другом приложении или одно из стандартных системных разрешений, например: andro
Наиболее распространенные разрешения
- INTERNET — доступ к интернету
- READ_CONTACTS — чтение (но не запись) данных из адресной книги пользователя
- WRITE_CONTACTS — запись (но не чтение) данных из адресной книги пользователя
- RECEIVE_SMS — обработка входящих SMS
- ACCESS_COARSE_LOCATION — использование приблизительного определения местонахождения при помощи вышек сотовой связи или точек доступа Wi-Fi
- ACCESS_FINE_LOCATION — точное определение местонахождения при помощи GPS
объявляет базовое имя для дерева разрешений. Этот элемент объявляет не само разрешение, а только пространство имен, в которое могут быть помещены дальнейшие разрешения.
определяет имя для набора логически связанных разрешений. Это могут быть как объявленные в этом же манифесте с элементом
разрешения, так и объявленные в другом месте. Этот элемент не объявляет разрешение непосредственно, только категорию, в которую могут быть помещены разрешения. Разрешение можно поместить в группу, назначив имя группы в атрибуте permissionGroup элемента
I am making some tests with the requestLocationUpdates() function from the FusedLocationApi . I am using the PRIORITY_BALANCED_POWER_ACCURACY. A city block precision is fine for me.
When I request the ACCESS_FINE_LOCATION permission, I get around a 100m precision which is great with GPS off. As I do not need a GPS precision but a city block precision, I would like to request only the ACCESS_COARSE_LOCATION permission. However when I request the ACCESS_COARSE_LOCATION permission, I get a 2 km precision. It seems that the device does not use anymore the Wifi permission and only a cell tower precision.
How can I have a better precision with the ACCESS_COARSE_LOCATION permission?
Note: the GPS is disabled on my test device.
2 Answers 2
This is an interesting problem, and I was under the impression that using ACCESS_COARSE_LOCATION would use WiFi, since that’s what the documentation says.
The documentation for ACCESS_COARSE_LOCATION states:
Allows an app to access approximate location derived from network location sources such as cell towers and Wi-Fi.
So, I put it to the test, and the results are surprising.
Here is the code that I used to test with:
The first test I did was with PRIORITY_BALANCED_POWER_ACCURACY , and no WiFi. Note that I also disabled Always Allow Scanning , since it states:
Let Google Location Service and other applications scan for Wi-Fi networks, even when Wi-Fi is off
So, that would certainly skew the results if it was enabled.
Note that I also had Location Mode set in Battery Saving Mode for all tests, so the GPS radio was off the entire time.
Here are the results of PRIORITY_BALANCED_POWER_ACCURACY , ACCESS_COARSE_LOCATION , and no WiFi:
So, it says 2000 meter accuracy, and here is how far away the actual coordinates are, the green arrow shows where I actually am:
Then, I enabled WiFi, and ran the test again, and surprisingly, the results were exactly the same!
Then, I switched to LocationRequest.PRIORITY_LOW_POWER in the LocationRequest while keeping android.permission.ACCESS_COARSE_LOCATION in the AndroidManifest.xml.
The results were exactly the same again! Using PRIORITY_LOW_POWER had the same results as using PRIORITY_BALANCED_POWER_ACCURACY , in that the WiFi state did not seem to have any effect on accuracy of coordinates.
Then, just to cover all the bases, I changed back to LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY , and switched the AndroidManifest.xml to ACCESS_FINE_LOCATION :
First test, no WiFi:
So, it says accuracy of 826 meters, and here is how close it was on the map:
Then, I powered on WiFi, and here is the result:
It’s literally spot on, as you can see on the map:
It seems that it matters less what you use in your LocationRequest in the Java code, and more what permission you use in the AndroidManifest.xml, since the results here clearly show that when using ACCESS_FINE_LOCATION , having the WiFi radio on or off made a huge difference in the accuracy, and it was also more accurate in general.
It certainly seems as though the documentation is a bit miss-leading, and that while using android.permission.ACCESS_COARSE_LOCATION , having the WiFi radio on or off doesn’t make a difference when your app is the only one making location requests.
Another thing that the documentation states is that using PRIORITY_BALANCED_POWER_ACCURACY will let your app "piggy-back" onto location requests made by other apps. From the documentation:
They will only be assigned power blame for the interval set by setInterval(long), but can still receive locations triggered by other applications at a rate up to setFastestInterval(long).
So if the user opens up Google Maps, according to the documentation your app can obtain a more accurate location at that point. That is one of the major up-sides of using the new Fused Location Provider rather than the older APIs, since it decreases the amount of battery drain of your app without much work on your part.
Edit: I performed a test of this functionality, to see what would happen while using ACCESS_COARSE_LOCATION .
First Test: ACCESS_COARSE_LOCATION , PRIORITY_BALANCED_POWER_ACCURACY , and WiFi on:
That placed me out in the water, quite far from my current location. Then, I exited the test app, launched Google Maps, which located me exactly where I am, then re-launched the test app. The test app was not able to piggy-back onto the location from Google Maps, and the result was exactly the same as before!
I re-tested this a few times, just to be sure, but it really looks like using ACCESS_COARSE_LOCATION also disables the ability of apps to "piggy-back" on to locations obtained by other apps.
It looks like using ACCESS_COARSE_LOCATION in the AndroidManifest.xml really cripples the app in terms of getting precise location data.
In conclusion, the only thing you can really do is hone in on the best combination of settings that work for you and your app, and hopefully the results of this test can help you make that decision.
Перевод статьи о нововведениях версии мобильной операционной системы Android Q. В этой статье речь пойдет о Location Permissions — разрешениях доступа к местоположению их типах и способах предоставления.
Недавно мы увидели анонс бета-версии Android Q. В этой версии Android появилась коллекция интересных изменений, к которым нам нужно подготовить наши приложения. В этом наборе статей я собираюсь углубиться в каждую из них, чтобы мы были полностью готовы к тому, чтобы подготовить наши приложения!
Примечание. Код этой статьи можно найти здесь.
Как указано в примечаниях к бета-версии для Android Q, одним из изменений, которые мы видим, является то, как мы работаем с пользовательскими местоположениями внутри наших приложений — эти изменения влияют на доступ к местоположению как на переднем, так и на заднем плане. Это дает нашим пользователям больший контроль над тем, когда они хотят, чтобы приложения могли иметь доступ к их местоположению, что позволяет им ограничивать его только в том случае, если приложение используется в данный момент. В этой статье я хочу кратко остановиться на том, как эти изменения повлияют на приложения, а также на то, что нам нужно сделать, чтобы адаптироваться к этим изменениям.
Foreground Location Permission
Могут быть случаи, когда вашему приложению требуется доступ к местоположению пользователя во время работы на переднем плане. Например, может быть, ваше приложение обеспечивает навигацию для пользователя — как только пользователь перейдет на свой домашний экран из вашего приложения, приложение продолжит получение доступа к местоположению, чтобы продолжить обслуживание навигации. Если вашему приложению требуется доступ к этим данным о местоположении, важно сообщить пользователю, о доступе приложения к его местоположению.
Для начала, любой сервис такого рода, который использует местоположение пользователей, должен быть объявлен как сервис переднего плана местоположения. Это можно сделать, используя foregroundServiceType при объявлении службы в файле манифеста.