Полный список
— разбираемся, что такое Package для приложения
Package можно перевести как пакет. Этот вариант перевода я и буду использовать в уроке.
Пакет приложения мы прописываем в визарде создания приложения.
Потом его можно найти в манифесте.
Он же по дефолту становится пакетом для Java-классов
Как-то не особо значимая цель .
Может быть он используется как-то еще? Оказывается да. Более того, пакет — это крайне важная вещь при создании приложения. Пакет является идентификатором приложения в системе. Т.е. когда вы устанавливаете приложение, система смотрит его пакет и ищет уже установленное приложение с таким пакетом. Если не нашлось, то все ок и приложение устанавливается.
А вот если нашлось, то тут в дело вступает механизм подписи приложения ключом, который мы рассмотрели на прошлом уроке. Система проверяет, если установленное и устанавливаемое приложения подписаны одним и тем же ключом, то, вероятнее всего, это означает, что оба приложения создал один автор. И устанавливаемое приложение является обновлением установленного, т.к. их пакеты и ключи одинаковы. Система устанавливает новое приложение, заменяя старое — т.е. обновляет старое.
Если же система определила, что приложения были подписаны разными ключами, то это значит, что приложения были созданы разными авторами, пакеты совпали случайно, и новое вовсе не является обновлением старого. В этом случае при установке нового, старое было бы заменено, а значит потеряно (а не обновлено), т.к. приложения абсолютно разные. И система не дает поставить новое приложение, пока не будет вручную удалено старое.
Проведем пару тестов. Я создам два приложения Package1 и Package2 с одинаковым пакетом.
Установлю первое. Оно появилось в списке.
Теперь не удаляя первое, установлю второе.
Первое исчезло. Осталось только второе.
Система решила, что второе является обновлением первого (т.к. пакеты и ключи совпадают), поэтому первое благополучно снесла и заменила вторым. Собственно, это и происходит при обычном обновлении.
Теперь подпишу Package2 другим ключом, чем оно было подписано изначально и попробую обновить через adb.
Параметр r здесь означает, что приложение надо переустановить, если оно уже существует.
Видим ошибку Failure [INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES]. Система сверила ключи у установленного и устанавливаемого приложений, увидела, что они разные и решила, что это будет не обновление, а просто приложение от другого разработчика ломится с тем же пакетом. И вполне разумно решила не удалять имеющееся приложение, а предупредить пользователя, что не совпадают ключи.
Если закинуть это приложение на эмулятор и поставить через файловый менеджер, получим примерно то же сообщение.
Из вышесказанного можно сделать следующий вывод: ваш ключ, которым вы подписываете приложение ни в коем случае нельзя терять или давать кому-либо.
Если вы ключ потеряете, то ваше приложение навсегда потеряет возможность быть обновленным. Даже если вы создадите новый ключ с тем же алиасом, паролем и данными владельца, это все равно будет другой ключ. И подписанная им следующая версия приложения будет рассматриваться системой не как обновление, а как попытка приложения от другого разработчика заменить ваше приложение и не даст его установить, пока не удалите установленное.
Если же вы ключ кому-то предоставите, то этот человек сможет сделать обновление для вашего приложения без вашего участия. И если этот человек имеет доступ и к вашей учетке разработчика в маркете, то он сможет залить туда свою версию вашего приложения.
Также не забывайте пароли от хранилища и от ключа. Это будет равносильно тому, что вы потеряли ключ. В общем, относитесь к вашим ключам со всей серьезностью.
И в конце урока небольшой ликбез. Пакет имеет еще одно значение. Как вы уже наверно заметили по вкладке Devices в Eclipse, пакет используется в качестве имени процесса, в котором запускается приложение. При этом, под каждое приложение система создает пользователя. Это позволяет разграничить доступ к данным. Каждое приложение запускается и работает со своими данными в отдельном процессе под отдельным пользователем. Соответственно, другие приложения не имеют к этим данным доступа, т.к. запущены под другими пользователями.
На следующем уроке:
— разбираемся с ViewPager
Присоединяйтесь к нам в Telegram:
— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.
— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Kotlin, RxJava, Dagger, Тестирование
— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня
— новый чат Performance для обсуждения проблем производительности и для ваших пожеланий по содержанию курса по этой теме
Источник
Naming a Package
With programmers worldwide writing classes and interfaces using the Java programming language, it is likely that many programmers will use the same name for different types. In fact, the previous example does just that: It defines a Rectangle class when there is already a Rectangle class in the java.awt package. Still, the compiler allows both classes to have the same name if they are in different packages. The fully qualified name of each Rectangle class includes the package name. That is, the fully qualified name of the Rectangle class in the graphics package is graphics.Rectangle , and the fully qualified name of the Rectangle class in the java.awt package is java.awt.Rectangle .
This works well unless two independent programmers use the same name for their packages. What prevents this problem? Convention.
Naming Conventions
Package names are written in all lower case to avoid conflict with the names of classes or interfaces.
Companies use their reversed Internet domain name to begin their package namesfor example, com.example.mypackage for a package named mypackage created by a programmer at example.com .
Name collisions that occur within a single company need to be handled by convention within that company, perhaps by including the region or the project name after the company name (for example, com.example.region.mypackage ).
Packages in the Java language itself begin with java. or javax.
In some cases, the internet domain name may not be a valid package name. This can occur if the domain name contains a hyphen or other special character, if the package name begins with a digit or other character that is illegal to use as the beginning of a Java name, or if the package name contains a reserved Java keyword, such as «int». In this event, the suggested convention is to add an underscore. For example:
Источник
Каким должно быть имя пакета приложения Android?
Я хочу знать, что должно быть имя пакета приложения для android? Значит обычно мы использовали com.appname или com.имя_организации.appName, но когда мы отправляем наше приложение на рынок, иногда он показывает ошибки, связанные с именем пакета, которые — пожалуйста, измените имя пакета. Его не следует запускать с com и т. д..
Я хочу знать, почему это happnes? И как правильно название пакета для Android?
Если кто знает причина или ответ на этот вопрос, пожалуйста, дайте мне знать.
6 ответов
Как указано здесь: имена пакетов записываются в нижнем регистре, чтобы избежать конфликтов с именами классов или интерфейсов.
компании используют свое обратное доменное имя Интернета, чтобы начать свои имена пакетов-например, com.example.mypackage for a package named mypackage created by a programmer at example.com .
коллизии имен, которые происходят в одной компании, должны обрабатываться соглашением внутри этой компании, возможно, путем включения региона или имени проекта после названия компании (например, com.образец.регион.пакета mypackage).
пакеты на самом языке Java начинаются с java. или javax.
в некоторых случаях имя домена интернета может быть недопустимым именем пакета. Это может произойти, если имя домена содержит дефис или другой специальный символ, если имя пакета начинается с цифры или другого символа, который незаконно использовать в качестве начала имени Java, или если имя пакета содержит зарезервированное ключевое слово Java, такое как «int». В этом случае предлагаемое соглашение заключается в добавлении подчеркивания. Например:
Android следует тем же соглашениям об именах, что и Java,
Именования
имена пакетов записываются в нижнем регистре, чтобы избежать конфликтов с именами классов или интерфейсов.
компании используют свое обратное доменное имя Интернета, чтобы начать свои имена пакетов-например, com.образец.mypackage для пакета с именем mypackage, созданного программистом на example.com.
конфликты имен, которые происходят в пределах одного компания должна обрабатываться по соглашению внутри этой компании, возможно, путем включения региона или названия проекта после названия компании (например, com.образец.регион.пакета mypackage).
пакеты на самом языке Java начинаются с java. или javax.
в некоторых случаях имя домена интернета может быть недопустимым именем пакета. Это может произойти, если имя домена содержит дефис или другой специальный символ, если имя пакета начинается с цифры или другого символа, который запрещено использовать в качестве начала имени Java, или если имя пакета содержит зарезервированное ключевое слово Java, такое как «int». В этом случае предлагаемое соглашение должно добавить подчеркивание. Например:
Легализация Имен Пакетов:
Как вы заявили, имена пакетов обычно находятся в форме ‘com.имя_организации.appName’ — все строчные и без пробелов. Похоже, имя пакета, которое вы ввели при загрузке приложения, отличалось от имени, объявленного в AndroidManifest.
В настоящее время имя пакета, начинающееся с «com.пример » не разрешается загружать в app-store. В противном случае все остальные имена пакетов, начинающиеся с «com», разрешены .
имя пакета с 0 может вызвать проблему для sharedPreference.
(OK) con = createPackageContext(«com.example.android.sf1», 0);
(проблема, но без ошибок)
посетить https://developers.google.com/mobile/add и попробуйте заполнить «имя пакета Android». В некоторых случаях он может написать ошибку: «недопустимое имя пакета Android».
и хотя идентификатор приложения выглядит как традиционный пакет Java имя, правила именования для идентификатора приложения немного больше ограничительный:
- он должен иметь по крайней мере два сегмента (одну или несколько точек).
- каждый сегмент должен начинаться с буквы.
- все символы должны быть буквенно-цифровыми или подчеркиванием [a-zA-Z0-9_].
Итак, «0com.образец.app » и » com.1example.приложение» ошибки.
Источник
How To Find Package Name Of An Android App
Last updated on 04/12/2017 by Pradeep Kumar ( 
Twitter) | Short URL: https://device.is/2Bw4Yvu
This is a very simple tip to find the package name of an Android app. This tip will be useful for you when you download APK files from Google Play Store. Some online tools require you to provide package name for the Android app you are going to download, so we decided to write this tip here. When I first heard the word “package name” I thought this will be technical, but honestly it is no where near to that.
Package Name Of An Android App
Go to Google Play Store, search and open your desired Android app. Now see the link in the address bar. I decided to open the link of “Subway Surfers” app. It’ll look like this:
Here the Package name of “Subway Surfers” Android app is com.kiloo.subwaysurf
https://play.google.com/store/apps/details?id=com.kiloo.subwaysurf
Similarly you can check this with other popular Android apps, we tried it once again with “WhatsApp” app. See the screenshot below.
Almost all the Android application package names will begin with “com”, heard it is used to avoid name-collisions between applications. After finding the package name for your desired app, you can easily download its APK file from Google Play Store.
Having any queries regarding this? Facing any trouble? Do you have any other easy method? Feel free to share them in the comments below.
Источник
Android Package Name Vs Application ID
Creating multiple APKs for different purposes.
PackageName vs ApplicationId
Nowadays, many times we come to the situation that we need the APK with another different package name. Most of us do it easily, but sometimes we got stuck because of applicationId and packageName.We must know the difference between packageName and applicationId. And the other thing is Java package.
The following are the three which keeps us confusing:
- applicationId: BuildConfig.APPLICATION_ID
- packageName: getApplicationContext().getPackageName()
- Java package: BuildConfig.class.getPackage().toString()
Let’s see with an example
The following is the snippet from the gradle of a sample Android application.
Here we will be having two different APKs.
- Release APK with com.mindorks.example.release
- Debug APK with com.mindorks.example.debug
The following is the snippet from manifest of the same sample Android application.
The following is the project package snippet of the same sample Android application.
So, let’s create a debug APK and see what are the values of all the three.
Read the values carefully.
The following shows the final AndroidManifest file after APK creation.
getPackageName gives the same applicationId which is created at the final moment from the gradle file and it overrides the AndroidManifest package. So the final AndroidManifest contains the same applicationId. So, the getPackageName is the same as the applicationId as the applicationId overrides the packageName in the AndroidManifest at the final moment.
But for the Java code, the package is same as the project structure. The package that is used in your source code to refer to your R class, and to resolve any relative activity, service registrations, continues to be called the package as defined in your manifest. So, the AndroidManifest should have the package same as Java package to resolve relative activity, service.
So, with the same java package, we can create any number of APKs with all unique applicationId.
But the final AndroidManifest contains the package as the unique applicationId only.
If you have to actually change the structure of your project, then you have to change your packageName in Manifest.xml.
If you rename the package name from manifest file, it will have NO impact on the applicationId even if they have the same name.
We can also create multiple APKs through productFlavors like above.
Remember, once an app has been published to Google Play store, the ApplicationId should never be changed.
Источник
