Things That Cannot Change 发布后不能修改的东西
Things That Cannot Change
(发布后不能修改的东西)
转自：http://android-developers.blogspot.com/2011/06/things-that-cannot-change.htmlhttp://
由于android的博客需要FQ，为了方便查阅
Sometimes a developer will make a change to an application that has
surprising results when installed as an update to a previous version — shortcuts
break, widgets disappear, or it can’t even be installed at all. There are
certain parts of an application that are immutable once you publish it, and you
can avoid surprises by understanding them.
certificate
The most obvious and visible of these is the “manifest package name,” the
unique name you give to your application in its AndroidManifest.xml. The name
uses a Java-language-style naming convention, with Internet domain ownership
helping to avoid name collisions. For example, since Google owns the domain
“google.com”, the manifest package names of all of our applications should start
with “com.google.” It’s important for developers to follow this convention in
order to avoid conflicts with other developers.
Once you publish your application under its manifest package name, this is
the unique identity of the application forever more. Switching to a different
name results in an entirely new application, one that can’t be installed as an
update to the existing application.
Just as important as the manifest package name is the certificate that
application is signed with. The signing certificate represents the author of the
application. If you change the certificate an application is signed with, it is
now a different application because it comes from a different author. This
different application can’t be uploaded to Market as an update to the original
application, nor can it be installed onto a device as an update.
The exact behavior the user sees when installing an application that has
changed in one of these two ways is different:
If the manifest package name has changed, the new application will be
installed alongside the old application, so they both co-exist on the user’s
device at the same time.
If the signing certificate changes, trying to install the new
application on to the device will fail until the old version is uninstalled.
If you change the signing certificate of your application, you should
always change its manifest package name as well to avoid failures when it’s
installed. In other words, the application coming from a different author makes
it a different application, and its package name should be changed appropriately
to reflect that. (Of course it’s fine to use the same package name for the
development builds of your app signed with your test keys, because these are not
published.)
More than just your package name that is immutable. A major function of theAndroidManifest.xmlis
essentially to declare a public API from your application for use by other
applications and the Android system. Every component you declare in the manifest
that is not private(that is whoseandroid:exportedstate
is true,表示是否允许activity被其它程序调用) should be treated as a public API and never
changed in a way that breaks compatibility.
A subtle but important aspect of what constitutes a break in compatibility is
the android:name
attribute of your activity, service, and receiver
components. This can be surprising because we think of android:name as
pointing to the private code implementing our application, but it is also (in
combination with the manifest package name) the official unique public name for
that component, as represented by theComponentNameclass.
Changing the component name inside of an application can have negative
consequences for your users. Some examples are:
If the name of a main activity of your application is
changed, any shortcuts（快捷方式） the user made to it will no longer work. A shortcut
is an Intent that directly specifies the ComponentName it should run.
If the name of a service implementing a Live Wallpaper changes, then a
user who has enabled your Live Wallpaper will have their wallpaper revert to the
system default when getting the new version of your app. The same is true for
Input Methods, Accessibility Services, Honeycomb’s new advanced Widgets, and so
on.
If the name of a receiver implementing a Device Admin changes, then as
with the live wallpaper example, the device admin will be disabled when the
application is updated. This also applies to other kinds of receivers, such as
App Widgets.
These behaviors are an outcome of how the Intent system is used on Android.
There are two main kinds of Intents:
Implicit Intents only specify “what” they should match, using
actions, categories, data, MIME types, and so on. The exact components that they
will find are only determined at run-time, by the Package Manager matching it
against the current applications.
Explicit Intents specify a single explicit “who” they
should match, through a ComponentName. Regardless of whatever else is in the
Intent, it is only associated with the exact manifest package name and class
name as given in its ComponentName.
Both of these types of Intents are important to how Android interacts with
your application. A typical example of this is how users browse and select live
wallpapers.
To let the user pick a live wallpaper, the first thing Android must do is
show them a list of the available live wallpaper services. It does this by
building an implicit Intent with the appropriate action for a live wallpaper and
asking the Package Manager for all services that support this Intent. The result
is then the list of live wallpapers shown to the user.
When the user actually selects a specific live wallpaper they want to use,
however, Android now must build an explicit Intent that identifies that
particular live wallpaper. This is what is handed to the WallpaperManager to
tell it which wallpaper to show.
This is why changing the name of the component in your manifest will cause
the wallpaper to disappear: the explicit Intent that was previously saved is now
invalid because the ComponentName it references no longer exists. There is no
information available to indicate what the new name of the component is. (For
example consider if your application had two different live wallpaper services
the user could select.) Instead, Android must treat that live wallpaper as
uninstalled and revert to its default wallpaper.
This is how input methods, device administrators, account managers, app
widgets, and even application shortcuts work. The ComponentName is the public
unique name of the components you declare in your manifest, and must not change
if they are visible to other applications.
In conclusion: There aresome parts of your application that can not
change. Please be careful.
浙公网安备 33010602011771号