Androidmanifest xml чем открыть
Обновлено: 07.07.2024
Внешнее хранилище относится к хранилищу файлов, которое находится не во внутреннем хранилище и доступно не только для приложения, отвечающего за файл. Основное предназначение внешнего хранилища — предоставление места для размещения файлов для совместного использования приложениями или файлов слишком большого размера для внутреннего хранилища.
Ранее внешним хранилищем назывался раздел диска на съемном носителе, таком как SD-карта (также известном как переносное устройство). Это различие уже неактуально, так как устройства Android существенно изменились и многие устройства Android больше не поддерживают съемные носители. Вместо этого некоторые устройства будут выделять часть внутренней энергонезависимой памяти, которую Android использует для выполнения той же функции съемного носителя. Это называется эмулированным хранилищем и по-прежнему считается внешним. Кроме того, у некоторых устройств Android может быть несколько внешних разделов хранилища. Например, в планшете Android (помимо его внутреннего хранилища) может быть эмулированное хранилище и один или несколько слотов для SD-карты. Все эти разделы рассматриваются Android как внешнее хранилище.
На устройствах с несколькими пользователями у каждого пользователя будет выделенный каталог в основном разделе внешнего хранилища для внешнего хранилища. Приложения, в которых работает один пользователь, не будут иметь доступа к файлам другого пользователя на устройстве. Файлы для всех пользователей по-прежнему будут доступны всем для чтения и записи. Тем не менее, Android будет изолировать каждый профиль пользователя от других.
В этом руководстве описываются основные понятия и API в Android, относящиеся к внешнему хранилищу.
Общедоступные и частные файлы во внешнем хранилище
Существует два разных типа файлов, которые приложение может хранить во внешнем хранилище:
Частные файлы — это файлы, зависящие от приложения (но все еще доступные всем для чтения и записи). В Android предполагается, что частные файлы хранятся в определенном каталоге во внешнем хранилище. Несмотря на то, что файлы называются "частными", они по-прежнему видимы и доступны для других приложений на устройстве, Android не предоставляет им специальные меры защиты.
Общедоступные файлы — это файлы, которые не считаются зависящими от приложения и предназначены для свободного использования.
Частные внешние файлы
Частные внешние файлы считаются привязанными к приложению (аналогично внутренним файлам), но содержатся во внешнем хранилище по разным причинам (например, файлы слишком большие для внутреннего хранилища). Как и внутренние файлы, эти файлы будут удалены, если пользователь удалит приложение.
В этом документе будут ссылки на каталог хранилища частных файлов во внешнем хранилище как на PRIVATE_EXTERNAL_STORAGE.
Параметр для GetExternalFilesDir() представляет собой строку, которая указывает каталог приложения. Этот каталог предназначен для стандартного расположения в логической организации файлов. Строковые значения доступны через константы класса Android.OS.Environment :
| Android.OS.Environment | Каталог |
|---|---|
| DirectoryAlarms | PRIVATE_EXTERNAL_STORAGE/Alarms |
| DirectoryDcim | PRIVATE_EXTERNAL_STORAGE/DCIM |
| DirectoryDownloads | PRIVATE_EXTERNAL_STORAGE/Download |
| DirectoryDocuments | PRIVATE_EXTERNAL_STORAGE/Documents |
| DirectoryMovies | PRIVATE_EXTERNAL_STORAGE/Movies |
| DirectoryMusic | PRIVATE_EXTERNAL_STORAGE/Music |
| DirectoryNotifications | PRIVATE_EXTERNAL_STORAGE/Notifications |
| DirectoryPodcasts | PRIVATE_EXTERNAL_STORAGE/Podcasts |
| DirectoryRingtones | PRIVATE_EXTERNAL_STORAGE/Ringtones |
| DirectoryPictures | PRIVATE_EXTERNAL_STORAGE/Pictures |
Для устройств с несколькими разделами во внешнем хранилище каждый раздел будет содержать каталог, предназначенный для частных файлов. Метод Android.Content.Context.GetExternalFilesDirs(string type) возвращает массив Java.IO.Files . Каждый объект будет представлять частный каталог приложения для всех совместно используемых устройств с внешними хранилищами, где приложение может размещать принадлежащие ему файлы.
Точный путь к частному каталогу внешнего хранилища может отличаться в зависимости от устройства и версии Android. По этой причине приложения не должны жестко задавать путь к этому каталогу. Вместо этого они должны использовать API-интерфейсы Xamarin.Android, например Android.Content.Context.GetExternalFilesDir() .
Общедоступные внешние файлы
Общедоступные файлы — это файлы, которые существуют во внешнем хранилище и не хранятся в каталоге, который Android выделяет для частных файлов. Общедоступные файлы не удаляются при удалении приложения. Приложения Android должны получить разрешение, прежде чем они смогут считывать или записывать любые общедоступные файлы. Общедоступные файлы могут существовать везде во внешнем хранилище, но по соглашению в Android предусматривается, что общедоступные файлы будут существовать в каталоге, указанном свойством Android.OS.Environment.ExternalStorageDirectory . Это свойство будет возвращать объект Java.IO.File , который представляет основной каталог во внешнем хранилище. В качестве примера Android.OS.Environment.ExternalStorageDirectory может ссылаться на следующий каталог:
В этом документе будут ссылки на каталог хранилища общедоступных файлов во внешнем хранилище как на PUBLIC_EXTERNAL_STORAGE.
Android также поддерживает концепцию каталогов приложений для PUBLIC_EXTERNAL_STORAGE. Эти каталоги в точности совпадают с каталогами приложений для PRIVATE_EXTERNAL_STORAGE и описаны в таблице в предыдущем разделе. Метод Android.OS.Environment.GetExternalStoragePublicDirectory(string directoryType) возвращает объект Java.IO.File , который соответствует общедоступному каталогу приложения. Параметр directoryType является обязательным и не может иметь значение null .
Например, вызов Environment.GetExternalStoragePublicDirectory(Environment.DirectoryDocuments).AbsolutePath вернет строку, которая будет выглядеть так:
Точный путь к общедоступному каталогу во внешнем хранилище может отличаться в зависимости от устройства и версии Android. По этой причине приложения не должны жестко задавать путь к этому каталогу. Вместо этого они должны использовать API-интерфейсы Xamarin.Android, например Android.OS.Environment.ExternalStorageDirectory .
Работа с внешним хранилищем
- Проверка внешнего хранилища. В зависимости от характера внешнего хранилища существует возможность, что оно не будет подключено и не будет использоваться приложением. Все приложения должны проверять состояние внешнего хранилища, прежде чем пытаться его использовать.
- Выполнение проверки разрешений во время выполнения. Приложение Android должно запросить разрешение у пользователя для доступа к внешнему хранилищу. Это означает, что запрос на разрешение во время выполнения должен быть сделан до осуществления любого доступа к файлу. Руководство Разрешения в Xamarin.Android содержит более подробные сведения о разрешениях Android.
Каждая из этих двух задач будет описана ниже.
Проверка доступности внешнего хранилища
Первым действием перед записью во внешнее хранилище является проверка его доступности для чтения или записи. Свойство Android.OS.Environment.ExternalStorageState содержит строку для определения состояния внешнего хранилища. Это свойство будет возвращать строку, которая представляет состояние. Эта таблица представляет собой список значений ExternalStorageState , которые могут быть возвращены Environment.ExternalStorageState :
| ExternalStorageState | Описание |
|---|---|
| MediaBadRemoval | Носитель внезапно удален без отключения надлежащим образом. |
| MediaChecking | Носитель присутствует, но проходит проверку диска. |
| MediaEjecting | Носитель пребывает в процессе отключения и извлечения. |
| MediaMounted | Носитель подключен, в нем можно выполнять операции чтения и записи. |
| MediaMountedReadOnly | Носитель подключен, но в нем можно выполнять только операции чтения. |
| MediaNofs | Носитель присутствует, но не содержит файловой системы, подходящей для Android. |
| MediaRemoved | Носитель отсутствует. |
| MediaShared | Носитель присутствует, но не подключен. Его использует через USB-порт другое устройство. |
| MediaUnknown | Состояние носителя не распознано Android. |
| MediaUnmountable | Носитель присутствует, но его не удалось подключить к Android. |
| MediaUnmounted | Носитель присутствует, но отключен. |
Большинству приложений Android нужно будет только проверить, подключено ли внешнее хранилище. В следующем фрагменте кода показано, как проверить, подключено внешнее хранилище только для чтения или для чтения и записи:
Разрешения внешнего хранилища
Android рассматривает доступ к внешнему хранилищу как опасное разрешение, поэтому обычно запрашивает у пользователя предоставление разрешения на доступ к ресурсу. Пользователь может отозвать это разрешение в любое время. Это означает, что запрос на разрешение во время выполнения должен быть сделан до осуществления любого доступа к файлу. Приложениям автоматически предоставляются разрешения на чтение и запись собственных частных файлов. Приложения могут считывать и записывать частные файлы, принадлежащие другим приложениям, после получения разрешения от пользователя.
Все приложения Android должны объявить одно из двух разрешений для внешнего хранилища в AndroidManifest.xml. Чтобы определить разрешения, один из следующих двух элементов uses-permission должен быть добавлен в AndroidManifest.xml:
Если пользователь предоставил разрешение WRITE_EXTERNAL_STORAGE , то также неявно предоставляется и READ_EXTERNAL_STORAGE . Нет необходимости запрашивать оба разрешения в AndroidManifest.xml.
Разрешения также можно добавить на вкладке Манифест Android в разделе свойств решения:
Разрешения также можно добавить с помощью вкладки Манифест Android на панели свойств решения:
В общем, все опасные разрешения подлежат одобрению пользователем. Разрешения для внешнего хранилища являются аномалией в том смысле, что есть исключения из этого правила в зависимости от версии Android, на которой работает приложение:
Я только что изменил расширение до zip . Это содержит . Но я не могу просмотреть содержимое Androidmanifest.xml . Он полностью зашифрован.
как я могу посмотреть ?
Да, вы можете посмотреть XML файлы . Для этого есть инструмент: android-apktool
это инструмент для обратного проектирования 3rd партии, закрытые, бинарные приложения для Android
как это сделать в вашей системе Windows:
- скачать apktool-установить-windows - * файл
- скачать apktool-файл*
- распаковать оба в Windows каталог
скопировать APK файл также в этом каталоге и выполните следующую команду в командной строке:
это создаст каталог" HelloWorld " в текущем каталоге. Внутри него вы можете найти AndroidManifest.xml файл в расшифрованном формате, и вы также можете найти другие XML файлы внутри .
здесь HelloWorld.apk ваш Android APK файл.
см. ниже снимок экрана для более информация:
вы можете напрямую использовать aapt l -a name.apk команда для просмотра манифеста.XML.
(это также приведет к сбросу таблицы ресурсов.)
Android Studio теперь может показать это. Перейти к Build > Analyze APK. и выберите apk. Затем вы можете увидеть содержимое файла AndroidManifset.
в этой нить, С Dianne Hackborn говорит нам, что мы можем получить информацию из AndroidManifest с помощью aapt.
Я взбил эту быструю команду unix, чтобы захватить информацию о версии:
aapt d xmltree com.package.apk AndroidManifest.xml
свалка в AndroidManifest.xml из указанного APK. Это не в форме XML, но вы все равно можете прочитать его.
aapt (Android Asset Packaging Tool) - это встроенный инструмент, который поставляется с Android SDK.
Google только что выпустила кросс-платформенный инструмент с открытым исходным кодом для проверки APKs (среди многих других бинарных форматов Android):
ClassyShark является автономным инструментом бинарной проверки для разработчиков Android. Он может надежно просматривать любой исполняемый файл Android и показывать важную информацию, такую как интерфейсы и члены класса, количество dex и зависимости. ClassyShark поддерживает несколько форматов, включая библиотеки (.Декс .ААР .Итак), исполняемые файлы (.apk,.сосуд. ,класс) и всех двоичных файлов XML Андроид: AndroidManifest, ресурсы, макеты и т. д.
Вы можете использовать эту команду: "сохранить в файл" AndroidManifest.txt
на AXMLParser и APKParser.Джар можно также сделать работу, вы можете увидеть ссылку. AXMLParser
также, если вы хотите просто проверить некоторые параметры, которые вы можете, их UI
Это старый поток, но я думал, что упомяну, что у вашего телефона есть root, вы можете просмотреть его прямо на своем телефоне с помощью приложения root explorer. Вам даже не нужно извлекать его, чтобы увидеть.
вы также можете использовать мое приложение, App Детектив для просмотра файла манифеста любого приложения, установленного на вашем устройстве.
файл должен быть декомпилирован (или deodex'D не уверен, какой из них). Но есть и другой способ сделать это:--2-->
AndroidManifest.xml на платформе Android — это мощный файл, который позволяет описать функциональные возможности и требования приложения для Android. Но работать с ним непросто. Xamarin.Android помогает упростить работу, позволяя добавлять в классы настраиваемые атрибуты, которые будут использоваться для автоматического создания манифеста. Наша цель заключается в том, чтобы 99 % наших пользователей никогда не испытывали потребности вручную изменять AndroidManifest.xml.
AndroidManifest.xml создается в процессе сборки, а найденный в Properties/AndroidManifest.xml XML-код объединяется с XML, созданным на основе настраиваемых атрибутов. Итоговый файл AndroidManifest.xml помещается в подкаталог obj, например для отладочных сборок. Например, он может находиться в папке obj/Debug/android/AndroidManifest.xml. Используется стандартный процесс слияния. Настраиваемые атрибуты в коде используются для создания XML-элементов, и эти элементы вставляются в AndroidManifest.xml.
Основы
В процессе компиляции в сборках выполняется поиск классов, которые не являются abstract , наследуют от класса Activity и имеют объявленный атрибут [Activity] . На основе этих классов и атрибутов создается манифест. Рассмотрим следующий пример кода:
В результате файл AndroidManifest.xml будет пустым. Если вам нужен элемент <activity/> , необходимо использовать настраиваемый атрибут [Activity] :
Этот пример приводит к добавлению следующего фрагмента XML в файл AndroidManifest.xml:
Атрибут [Activity] не влияет на типы abstract . Все типы abstract игнорируются.
Имя действия
Начиная с Xamarin.Android 5.1, имена типов для действий основаны на MD5SUM от имени экспортируемого типа с указанием сборки. Это позволяет предоставить одно и то же полное имя из двух разных сборок и не получить ошибку упаковки (до версии Xamarin.Android 5.1 имя типа действия по умолчанию составлялось из имени пространства имен и имени класса в нижнем регистре).
Если вы хотите переопределить это поведение по умолчанию и указать имя действия явным образом, используйте свойство Name :
В этом примере создается следующий фрагмент XML:
Свойство Name следует использовать только для поддержки обратной совместимости, так как такое переименование может замедлить поиск типов во время выполнения. Если у вас есть старый код, который ожидает, что в качестве имени типа для действия по умолчанию используется имя пространства имен и имя класса в нижнем регистре, воспользуйтесь рекомендациями по сохранению совместимости, касающимися имени вызываемой программы-оболочки.
Заголовок действия
По умолчанию Android присваивает приложению заголовок при выполнении. Для этого используется значение /manifest/application/activity/@android:label . В большинстве случаев это значение отличается от имени класса. Чтобы указать в приложении метку для заголовка окна, используйте свойство Label . Пример:
В этом примере создается следующий фрагмент XML:
Возможность запуска из средства выбора приложений
По умолчанию действие не отображается на экране запуска приложений Android. Это связано с тем, что в приложении может быть много действий. Вам не потребуется значок для каждого из них. Чтобы указать, какие из них должны запускаться через средство запуска приложений, используйте свойство MainLauncher . Пример:
В этом примере создается следующий фрагмент XML:
Значок действия
По умолчанию действию присваивается значок запуска, предоставляемый системой. Чтобы использовать пользовательский значок, добавьте нужный файл .jpg в папку Resources/drawable, задайте для него действие сборки AndroidResource и с помощью свойства Icon укажите этот файл в качестве значка. Пример:
В этом примере создается следующий фрагмент XML:
Разрешения
При добавлении разрешений в манифест Android (как описано в этой статье) такие разрешения записываются в файл Properties/AndroidManifest.xml. Например, если задать разрешение INTERNET , то в Properties/AndroidManifest.xml будет добавлен следующий элемент:
Отладочные сборки автоматически устанавливают некоторые разрешения, чтобы упростить отладку (например INTERNET и READ_EXTERNAL_STORAGE ) – эти параметры задаются только в созданном obj/Debug/android/AndroidManifest.xml и не отображаются как включенные в параметрах необходимых разрешений.
Например, если вы изучите созданный файл манифеста в obj/Debug/android/AndroidManifest.xml, то увидите следующие добавленные элементы разрешений:
В версии сборки выпуска эти разрешения не включаются в манифест автоматически (obj/Debug/android/AndroidManifest.xml). Если обнаружится, что при переключении на сборку выпуска приложение теряет разрешение, которое было доступно в сборке отладки, убедитесь, что это разрешение явным образом включено в параметрах необходимых разрешений для этого приложения (в разделе Сборка > Приложение Android в Visual Studio для Mac или Свойства > Манифест Android в Visual Studio).
Дополнительные функции
Действия и функции намерения
Манифест Android предоставляет способ для описания возможностей действия. Это делается с помощью намерений и настраиваемого атрибута [IntentFilter] . Вы можете указать действия для своего действия с помощью конструктора IntentFilter , а подходящие категории — через свойство Categories . Необходимо указать хотя бы одно действие (именно поэтому действия предоставляются в конструкторе). [IntentFilter] может предоставляться несколько раз. При каждом его использовании в <activity/> создается отдельный элемент <intent-filter/> . Пример:
В этом примере создается следующий фрагмент XML:
Элемент Application
Кроме того, в манифесте Android можно объявлять свойства для всего приложения. Это делается с помощью элемента <application> и его аналога, настраиваемого атрибута Application. Обратите внимание, что это параметры уровня приложения (сборки), а не отдельные параметры для каждого действия. Как правило, свойства <application> объявляются для всего приложения, а затем переопределяются (по мере необходимости) для каждого действия.
Например, следующий атрибут Application , добавленный в AssemblyInfo.cs, означает, что приложение доступно для отладки, у него есть понятное для пользователя имя My App и в нем используется стиль Theme.Light в качестве темы по умолчанию для всех действий:
Это объявление приводит к созданию следующего фрагмента XML в файле obj/Debug/Android/AndroidManifest.xml:
В этом примере все действия в приложении будут по умолчанию использовать стиль Theme.Light . Если задать для действия тему Theme.Dialog , то стиль Theme.Dialog будет применен только к этому действию. Все остальные действия в приложении будут использовать стиль по умолчанию Theme.Light , который задан в элементе <application> .
Элемент Application — не единственный способ настройки атрибутов <application> . Вместо этого вы можете вставлять атрибуты непосредственно в элемент <application> файла Properties/AndroidManifest.xml. Эти параметры объединяются в последний элемент <application> в файле obj/Debug/Android/AndroidManifest.xml. Обратите внимание, что содержимое Properties/AndroidManifest.xml всегда переопределяет данные, предоставленные пользовательскими атрибутами.
Есть множество атрибутов на уровне приложения, которые можно настроить в элементе <application> . Дополнительные сведения об этих параметрах см. в разделе документации по ApplicationAttribute, посвященном открытым свойствам.
AndroidManifest.xml is a powerful file in the Android platform that allows you to describe the functionality and requirements of your application to Android. However, working with it is not easy. Xamarin.Android helps to minimize this difficulty by allowing you to add custom attributes to your classes, which will then be used to automatically generate the manifest for you. Our goal is that 99% of our users should never need to manually modify AndroidManifest.xml.
AndroidManifest.xml is generated as part of the build process, and the XML found within Properties/AndroidManifest.xml is merged with XML that is generated from custom attributes. The resulting merged AndroidManifest.xml resides in the obj subdirectory; for example, it resides at obj/Debug/android/AndroidManifest.xml for Debug builds. The merging process is trivial: it uses custom attributes within the code to generate XML elements, and inserts those elements into AndroidManifest.xml.
The Basics
At compile time, assemblies are scanned for non- abstract classes that derive from Activity and have the [Activity] attribute declared on them. It then uses these classes and attributes to build the manifest. For example, consider the following code:
This results in nothing being generated in AndroidManifest.xml. If you want an <activity/> element to be generated, you need to use the [Activity] custom attribute:
This example causes the following xml fragment to be added to AndroidManifest.xml:
The [Activity] attribute has no effect on abstract types; abstract types are ignored.
Activity Name
Beginning with Xamarin.Android 5.1, the type name of an activity is based on the MD5SUM of the assembly-qualified name of the type being exported. This allows the same fully-qualified name to be provided from two different assemblies and not get a packaging error. (Before Xamarin.Android 5.1, the default type name of the activity was created from the lowercased namespace and the class name.)
If you wish to override this default and explicitly specify the name of your activity, use the Name property:
This example produces the following xml fragment:
You should use the Name property only for backward-compatibility reasons, as such renaming can slow down type lookup at runtime. If you have legacy code that expects the default type name of the activity to be based on the lowercased namespace and the class name, see Android Callable Wrapper Naming for tips on maintaining compatibility.
Activity Title Bar
By default, Android gives your application a title bar when it is run. The value used for this is /manifest/application/activity/@android:label . In most cases, this value will differ from your class name. To specify your app's label on the title bar, use the Label property. For example:
This example produces the following xml fragment:
Launchable from Application Chooser
By default, your activity will not show up in Android's application launcher screen. This is because there will likely be many activities in your application, and you don't want an icon for every one. To specify which one should be launchable from the application launcher, use the MainLauncher property. For example:
This example produces the following xml fragment:
Activity Icon
By default, your activity will be given the default launcher icon provided by the system. To use a custom icon, first add your .jpg to Resources/drawable, set its Build Action to AndroidResource, then use the Icon property to specify the icon to use. For example:
This example produces the following xml fragment:
Permissions
When you add permissions to the Android Manifest (as described in Add Permissions to Android Manifest), these permissions are recorded in Properties/AndroidManifest.xml. For example, if you set the INTERNET permission, the following element is added to Properties/AndroidManifest.xml:
Debug builds automatically set some permissions to make debug easier (such as INTERNET and READ_EXTERNAL_STORAGE ) – these settings are set only in the generated obj/Debug/android/AndroidManifest.xml and are not shown as enabled in the Required permissions settings.
For example, if you examine the generated manifest file at obj/Debug/android/AndroidManifest.xml, you may see the following added permission elements:
In the Release build version of the manifest (at obj/Debug/android/AndroidManifest.xml), these permissions are not automatically configured. If you find that switching to a Release build causes your app to lose a permission that was available in the Debug build, verify that you have explicitly set this permission in the Required permissions settings for your app (see Build > Android Application in Visual Studio for Mac; see Properties > Android Manifest in Visual Studio).
Advanced Features
Intent Actions and Features
The Android manifest provides a way for you to describe the capabilities of your activity. This is done via Intents and the [IntentFilter] custom attribute. You can specify which actions are appropriate for your activity with the IntentFilter constructor, and which categories are appropriate with the Categories property. At least one activity must be provided (which is why activities are provided in the constructor). [IntentFilter] can be provided multiple times, and each use results in a separate <intent-filter/> element within the <activity/> . For example:
This example produces the following xml fragment:
Application Element
The Android manifest also provides a way for you to declare properties for your entire application. This is done via the <application> element and its counterpart, the Application custom attribute. Note that these are application-wide (assembly-wide) settings rather than per-Activity settings. Typically, you declare <application> properties for your entire application and then override these settings (as needed) on a per-Activity basis.
For example, the following Application attribute is added to AssemblyInfo.cs to indicate that the application can be debugged, that its user-readable name is My App, and that it uses the Theme.Light style as the default theme for all activities:
This declaration causes the following XML fragment to be generated in obj/Debug/android/AndroidManifest.xml:
In this example, all activities in the app will default to the Theme.Light style. If you set an Activity's theme to Theme.Dialog , only that Activity will use the Theme.Dialog style while all other activities in your app will default to the Theme.Light style as set in the <application> element.
The Application element is not the only way to configure <application> attributes. Alternately, you can insert attributes directly into the <application> element of Properties/AndroidManifest.xml. These settings are merged into the final <application> element that resides in obj/Debug/android/AndroidManifest.xml. Note that the contents of Properties/AndroidManifest.xml always override data provided by custom attributes.
There are many application-wide attributes that you can configure in the <application> element; for more information about these settings, see the Public Properties section of ApplicationAttribute.
Читайте также: