[android-developers] Re: How to re-install & sign android built-in applications
Anything that requires root access to install an application is in no way how Android is designed to work. First you really need to separate developer restrictions from user restrictions. Whether or not a phone allows root access is ultimately a decision of the manufacturer, but generally for Android our preference is for users to have that kind of control of their phone. For what applications can do, however, yes we do have a lot of control over them, and that is very deliberate and not going to change. Giving the user trust that some random app they download from the market is not going to wreak havoc with their device is a basic goal of Android, and we think it is key to having a strong, robust, and open application environment. On Thu, Jan 22, 2009 at 2:09 AM, Marcio Alexandroni wrote: > >> I thought part of the point of the AOSP was that you could use those > apps as bases for your own development. (I can go digging for more > website/marketing/etc quotes if you really want, but..) > > Ok, perhaps we should move this discussion to android-discuss but as it > started and continued here... > > > > What it seems is that **Android** is based exactly on this idea but device > manufacturers don't want developers to do it, so if it does not happen that > a manufacturer sells an open device like dev phone to people in general, > Android will continue being a very good idea. Not that you can't jailbreak > your device, I did it and it works fine, but users in general won't do it. > > > > I've been working with PalmOS and Windows Mobile for years and I still feel > uncomfortable with the manu security issues on the OS and surprised with the > "you can't". In these operating systems, it's up to the user to decide what > is going to happen with his device and the worst case if a terrible > developer does something mad, you can always hard reset the device and you > are up and running again. > > > > I hope the future versions bring us your President's statement "Yes, we > can" (do what we developers want to do). > > > > Marcio Alexandroni. > > > -- > > *From:* android-developers@googlegroups.com [mailto: > android-develop...@googlegroups.com] *On Behalf Of *Disconnect > *Sent:* Wednesday, January 21, 2009 18:08 > *To:* android-developers@googlegroups.com > *Subject:* [android-developers] Re: How to re-install & sign android > built-in applications > > > > I don't understand why taking the AOSP launcher, for example, and modifying > it is "simply not correct" but writing one from scratch is..? > > I thought part of the point of the AOSP was that you could use those apps > as bases for your own development. (I can go digging for more > website/marketing/etc quotes if you really want, but..) > > On Wed, Jan 21, 2009 at 3:04 PM, Romain Guy wrote: > > > Replacing a core application is achieved using intent filters. This is > how you can replace Home with your own application or replace Browser > with your own web browser, et. > > > On Wed, Jan 21, 2009 at 11:58 AM, Disconnect > wrote: > > I thought one of the core tenants of Android was that developers could > > write, and end users could install, apps that replaced the default apps. > > (Such as k9 and k9sms.) > > > > Is this not, in fact, true? (And please don't try to claim that sms/mms > > isn't a core feature of a mobile phone OS. And both of those projects > are, > > from the start, forks of the AOSP applications.) > > > > Looking at the Android page (http://code.google.com/android/) I see: > > > > Any app on the mobile device can be replaced or extended -- even core > > components such as the dialer or home. > > > > ..the dialer has already been hashed over (at best, you can make > > non-emergency calls, but you cannot in fact "replace or extend" the > dialer > > completely.) Are you now saying that the entire statement is false? > > > > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn > > wrote: > >> > >> Yes in this case probably what is desired is changing the package name, > >> though that wasn't explicitly requested. But in Android that is how you > >> install an alternative version of an app -- by installing a -different- > app > >> with the same public capabilities (handling the same intents etc) as the > >> built-in app. Then the user is free to decide when and where they want > to > >> use that new app, if at all. > >> > >> For the desire to just install a custom version of a built-in app that > has > >> t
[android-developers] Re: How to re-install & sign android built-in applications
You just have an application with the same activities etc that support the same actions. Then the system will let the user pick your app when it is appropriate. On Thu, Jan 22, 2009 at 4:55 PM, Anonymous Anonymous < firewallbr...@googlemail.com> wrote: > Hi Romain, > > How this can be achieved using intent filter? Can you please show an > example assuming IM.apk? > > Thanks in Advance > Steve > > > On Thu, Jan 22, 2009 at 1:34 AM, Romain Guy wrote: > >> >> Replacing a core application is achieved using intent filters. This is >> how you can replace Home with your own application or replace Browser >> with your own web browser, et. >> >> On Wed, Jan 21, 2009 at 11:58 AM, Disconnect >> wrote: >> > I thought one of the core tenants of Android was that developers could >> > write, and end users could install, apps that replaced the default apps. >> > (Such as k9 and k9sms.) >> > >> > Is this not, in fact, true? (And please don't try to claim that sms/mms >> > isn't a core feature of a mobile phone OS. And both of those projects >> are, >> > from the start, forks of the AOSP applications.) >> > >> > Looking at the Android page (http://code.google.com/android/) I see: >> > >> > Any app on the mobile device can be replaced or extended -- even core >> > components such as the dialer or home. >> > >> > ..the dialer has already been hashed over (at best, you can make >> > non-emergency calls, but you cannot in fact "replace or extend" the >> dialer >> > completely.) Are you now saying that the entire statement is false? >> > >> > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn >> > wrote: >> >> >> >> Yes in this case probably what is desired is changing the package name, >> >> though that wasn't explicitly requested. But in Android that is how >> you >> >> install an alternative version of an app -- by installing a -different- >> app >> >> with the same public capabilities (handling the same intents etc) as >> the >> >> built-in app. Then the user is free to decide when and where they want >> to >> >> use that new app, if at all. >> >> >> >> For the desire to just install a custom version of a built-in app that >> has >> >> the same name, and is thus treated as a new version, of the built-in >> app, >> >> the basic answer is: >> >> >> >> - In the current platform, it is not possible to install an UPDATE (key >> >> word) to a built-in application in to the data partition; updates can >> only >> >> be done by replacing the app in /system. >> >> - In Cupcake we will have this facility, HOWEVER: >> >> 1. You still must be able to sign the app with the same certificate >> as >> >> the version in the system partition. If you can't, you can't update >> it. >> >> Only the original author of an application can create new versions of >> their >> >> own applications. You won't be able to do this with any of the >> built-in >> >> apps, because HTC and Google own the various certificates. >> >> 2. It simply is not correct to install a your own update to one of >> the >> >> system apps (contacts, calendar, etc) because those are part of the >> open >> >> source platform and the company who made the phone you are installing >> it on >> >> could have customized that app in significant ways. Your "update" >> could >> >> actually be a regression, or completely incompatible with how the >> built-in >> >> app stores its data. >> >> >> >> >> >> >> >> On Wed, Jan 21, 2009 at 9:42 AM, Disconnect >> >> wrote: >> >>> >> >>> ..android-platform covers building apps with the sdk? Thats new. >> >>> >> >>> I think he's looking for info on changing package names so that he can >> >>> replace the default apps. (I don't have that info handy, sorry..) >> >>> >> >>> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler >> >>> wrote: >> >> Wrong list. Please see android-platform, which covers topics such as >> this. >> >> http://source.android.com/discuss for more information. >> >> >> On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: >> > >> > Hi, >> > I want to customize some built-in applications on android, for >> example >> > Launcher or Contacts, etc. >> > I've downloaded the source code and compile it by eclipse >> > successfully. >> > But when I tried to run it, a signing error comes: >> > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... >> > [2009-01-20 16:17:35 - Launcher] Application already exists. >> > Attempting to re-install instead... >> > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to >> > different application signatures. >> > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall >> of >> > the application. WARNING: This will remove the application data! >> > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall >> > com.android.launcher' in a shell. >> > >> > I followed above instruction: adb uninstall com.android.launcher, >> but >> > it
[android-developers] Re: How to re-install & sign android built-in applications
Hi Romain, How this can be achieved using intent filter? Can you please show an example assuming IM.apk? Thanks in Advance Steve On Thu, Jan 22, 2009 at 1:34 AM, Romain Guy wrote: > > Replacing a core application is achieved using intent filters. This is > how you can replace Home with your own application or replace Browser > with your own web browser, et. > > On Wed, Jan 21, 2009 at 11:58 AM, Disconnect > wrote: > > I thought one of the core tenants of Android was that developers could > > write, and end users could install, apps that replaced the default apps. > > (Such as k9 and k9sms.) > > > > Is this not, in fact, true? (And please don't try to claim that sms/mms > > isn't a core feature of a mobile phone OS. And both of those projects > are, > > from the start, forks of the AOSP applications.) > > > > Looking at the Android page (http://code.google.com/android/) I see: > > > > Any app on the mobile device can be replaced or extended -- even core > > components such as the dialer or home. > > > > ..the dialer has already been hashed over (at best, you can make > > non-emergency calls, but you cannot in fact "replace or extend" the > dialer > > completely.) Are you now saying that the entire statement is false? > > > > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn > > wrote: > >> > >> Yes in this case probably what is desired is changing the package name, > >> though that wasn't explicitly requested. But in Android that is how you > >> install an alternative version of an app -- by installing a -different- > app > >> with the same public capabilities (handling the same intents etc) as the > >> built-in app. Then the user is free to decide when and where they want > to > >> use that new app, if at all. > >> > >> For the desire to just install a custom version of a built-in app that > has > >> the same name, and is thus treated as a new version, of the built-in > app, > >> the basic answer is: > >> > >> - In the current platform, it is not possible to install an UPDATE (key > >> word) to a built-in application in to the data partition; updates can > only > >> be done by replacing the app in /system. > >> - In Cupcake we will have this facility, HOWEVER: > >> 1. You still must be able to sign the app with the same certificate as > >> the version in the system partition. If you can't, you can't update it. > >> Only the original author of an application can create new versions of > their > >> own applications. You won't be able to do this with any of the built-in > >> apps, because HTC and Google own the various certificates. > >> 2. It simply is not correct to install a your own update to one of the > >> system apps (contacts, calendar, etc) because those are part of the open > >> source platform and the company who made the phone you are installing it > on > >> could have customized that app in significant ways. Your "update" could > >> actually be a regression, or completely incompatible with how the > built-in > >> app stores its data. > >> > >> > >> > >> On Wed, Jan 21, 2009 at 9:42 AM, Disconnect > >> wrote: > >>> > >>> ..android-platform covers building apps with the sdk? Thats new. > >>> > >>> I think he's looking for info on changing package names so that he can > >>> replace the default apps. (I don't have that info handy, sorry..) > >>> > >>> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler > >>> wrote: > > Wrong list. Please see android-platform, which covers topics such as > this. > > http://source.android.com/discuss for more information. > > > On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: > > > > Hi, > > I want to customize some built-in applications on android, for > example > > Launcher or Contacts, etc. > > I've downloaded the source code and compile it by eclipse > > successfully. > > But when I tried to run it, a signing error comes: > > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... > > [2009-01-20 16:17:35 - Launcher] Application already exists. > > Attempting to re-install instead... > > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to > > different application signatures. > > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall > of > > the application. WARNING: This will remove the application data! > > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall > > com.android.launcher' in a shell. > > > > I followed above instruction: adb uninstall com.android.launcher, > but > > it failed (Can't remove the application). > > The official document only provides "How to sign a new application", > > but it's not usable in my case. > > > > Does anyone know how to do it? > > Thank you very much > > > > Gerald > > > > > > > > > > >>> > >>> > >>> > >> > >> > >> > >> -- > >> Dianne Hackborn > >> Android framework engineer > >>
[android-developers] Re: How to re-install & sign android built-in applications
>> I thought part of the point of the AOSP was that you could use those apps as bases for your own development. (I can go digging for more website/marketing/etc quotes if you really want, but..) Ok, perhaps we should move this discussion to android-discuss but as it started and continued here... What it seems is that *Android* is based exactly on this idea but device manufacturers don't want developers to do it, so if it does not happen that a manufacturer sells an open device like dev phone to people in general, Android will continue being a very good idea. Not that you can't jailbreak your device, I did it and it works fine, but users in general won't do it. I've been working with PalmOS and Windows Mobile for years and I still feel uncomfortable with the manu security issues on the OS and surprised with the "you can't". In these operating systems, it's up to the user to decide what is going to happen with his device and the worst case if a terrible developer does something mad, you can always hard reset the device and you are up and running again. I hope the future versions bring us your President's statement "Yes, we can" (do what we developers want to do). Marcio Alexandroni. _ From: android-developers@googlegroups.com [mailto:android-develop...@googlegroups.com] On Behalf Of Disconnect Sent: Wednesday, January 21, 2009 18:08 To: android-developers@googlegroups.com Subject: [android-developers] Re: How to re-install & sign android built-in applications I don't understand why taking the AOSP launcher, for example, and modifying it is "simply not correct" but writing one from scratch is..? I thought part of the point of the AOSP was that you could use those apps as bases for your own development. (I can go digging for more website/marketing/etc quotes if you really want, but..) On Wed, Jan 21, 2009 at 3:04 PM, Romain Guy wrote: Replacing a core application is achieved using intent filters. This is how you can replace Home with your own application or replace Browser with your own web browser, et. On Wed, Jan 21, 2009 at 11:58 AM, Disconnect wrote: > I thought one of the core tenants of Android was that developers could > write, and end users could install, apps that replaced the default apps. > (Such as k9 and k9sms.) > > Is this not, in fact, true? (And please don't try to claim that sms/mms > isn't a core feature of a mobile phone OS. And both of those projects are, > from the start, forks of the AOSP applications.) > > Looking at the Android page (http://code.google.com/android/) I see: > > Any app on the mobile device can be replaced or extended -- even core > components such as the dialer or home. > > ..the dialer has already been hashed over (at best, you can make > non-emergency calls, but you cannot in fact "replace or extend" the dialer > completely.) Are you now saying that the entire statement is false? > > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn > wrote: >> >> Yes in this case probably what is desired is changing the package name, >> though that wasn't explicitly requested. But in Android that is how you >> install an alternative version of an app -- by installing a -different- app >> with the same public capabilities (handling the same intents etc) as the >> built-in app. Then the user is free to decide when and where they want to >> use that new app, if at all. >> >> For the desire to just install a custom version of a built-in app that has >> the same name, and is thus treated as a new version, of the built-in app, >> the basic answer is: >> >> - In the current platform, it is not possible to install an UPDATE (key >> word) to a built-in application in to the data partition; updates can only >> be done by replacing the app in /system. >> - In Cupcake we will have this facility, HOWEVER: >> 1. You still must be able to sign the app with the same certificate as >> the version in the system partition. If you can't, you can't update it. >> Only the original author of an application can create new versions of their >> own applications. You won't be able to do this with any of the built-in >> apps, because HTC and Google own the various certificates. >> 2. It simply is not correct to install a your own update to one of the >> system apps (contacts, calendar, etc) because those are part of the open >> source platform and the company who made the phone you are installing it on >> could have customized that app in significant ways. Your "update" could >> actually be a regression, or completely incompatible with how the built-in >> app stores its data. >> >> >> >> On
[android-developers] Re: How to re-install & sign android built-in applications
On Wed, Jan 21, 2009 at 12:22 PM, Jean-Baptiste Queru wrote: > It's not that easy, because aapt assumes that the android package name > is also the source code package name. At the very least you need a > custom post-processing step to move the generated R file into the > proper source code package, and none of the standard Android build > tools support that. Yes, better tools to help with this would be nice. The basic point of the package name is this: it provides a unique identity for an application under a particular author's control. It does not make any sense for someone to go and modify an application in the open-source platform and make it available with the same package name, because what you have done is created a -fork- and it needs a new identity. The existing system app will continue to evolve, and your own fork will continue to evolve, and there is no way to ensure they are compatible. And further, as I said, the apps that are available as part of the platform code are really owned by the manufacturer of the device they are running on (using the platform code as a base), so there is simply no way you can know that your version of the app forked off of some version of the platform will be able to actually replace the version built into a piece of hardware based on possibly some other version of the platform with who knows what customization done by the hardware manufacturer. So the way one replaces components is to create a -new- application that supplies the same features to the system as the built-in application, so the system can let the user pick which one to use where appropriate, use the built-in one where the replacement didn't actually happen to provide some functionality it has, etc. This is actually an -intrinsic- part of the claim about third parties being able to replace applications, in that it is done in such a way that it can be controlled and avoid breaking things on whatever device the replacement is being installed on. > On top of that, you've got to pray that the application you're working > with only uses SDK-accessible permissions. The vast majority of applications built into the system use normal application permissions. As we have already gone over numerous times, yes there are some parts of the UI that are more intimately tied with the system (in-call screen, lock screen, settings) and not so easy to extract at this point. That doesn't invalidate the general philosophy nor the extensive architecture in place to support that philosophy. -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to re-install & sign android built-in applications
It's not that easy, because aapt assumes that the android package name is also the source code package name. At the very least you need a custom post-processing step to move the generated R file into the proper source code package, and none of the standard Android build tools support that. On top of that, you've got to pray that the application you're working with only uses SDK-accessible permissions. JBQ On Wed, Jan 21, 2009 at 12:13 PM, Romain Guy wrote: > >> I don't understand why taking the AOSP launcher, for example, and modifying >> it is "simply not correct" but writing one from scratch is..? > > You can, Dianne just said that you need to change its package name to > avoid conflicting with the system apps. That's all. That's what K9 > does with Email. So take the launcher, modify it and install it but > change its package name. > >> >> I thought part of the point of the AOSP was that you could use those apps as >> bases for your own development. (I can go digging for more >> website/marketing/etc quotes if you really want, but..) >> >> >> On Wed, Jan 21, 2009 at 3:04 PM, Romain Guy wrote: >>> >>> Replacing a core application is achieved using intent filters. This is >>> how you can replace Home with your own application or replace Browser >>> with your own web browser, et. >>> >>> On Wed, Jan 21, 2009 at 11:58 AM, Disconnect >>> wrote: >>> > I thought one of the core tenants of Android was that developers could >>> > write, and end users could install, apps that replaced the default apps. >>> > (Such as k9 and k9sms.) >>> > >>> > Is this not, in fact, true? (And please don't try to claim that sms/mms >>> > isn't a core feature of a mobile phone OS. And both of those projects >>> > are, >>> > from the start, forks of the AOSP applications.) >>> > >>> > Looking at the Android page (http://code.google.com/android/) I see: >>> > >>> > Any app on the mobile device can be replaced or extended -- even core >>> > components such as the dialer or home. >>> > >>> > ..the dialer has already been hashed over (at best, you can make >>> > non-emergency calls, but you cannot in fact "replace or extend" the >>> > dialer >>> > completely.) Are you now saying that the entire statement is false? >>> > >>> > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn >>> > wrote: >>> >> >>> >> Yes in this case probably what is desired is changing the package name, >>> >> though that wasn't explicitly requested. But in Android that is how >>> >> you >>> >> install an alternative version of an app -- by installing a -different- >>> >> app >>> >> with the same public capabilities (handling the same intents etc) as >>> >> the >>> >> built-in app. Then the user is free to decide when and where they want >>> >> to >>> >> use that new app, if at all. >>> >> >>> >> For the desire to just install a custom version of a built-in app that >>> >> has >>> >> the same name, and is thus treated as a new version, of the built-in >>> >> app, >>> >> the basic answer is: >>> >> >>> >> - In the current platform, it is not possible to install an UPDATE (key >>> >> word) to a built-in application in to the data partition; updates can >>> >> only >>> >> be done by replacing the app in /system. >>> >> - In Cupcake we will have this facility, HOWEVER: >>> >> 1. You still must be able to sign the app with the same certificate >>> >> as >>> >> the version in the system partition. If you can't, you can't update >>> >> it. >>> >> Only the original author of an application can create new versions of >>> >> their >>> >> own applications. You won't be able to do this with any of the >>> >> built-in >>> >> apps, because HTC and Google own the various certificates. >>> >> 2. It simply is not correct to install a your own update to one of >>> >> the >>> >> system apps (contacts, calendar, etc) because those are part of the >>> >> open >>> >> source platform and the company who made the phone you are installing >>> >> it on >>> >> could have customized that app in significant ways. Your "update" >>> >> could >>> >> actually be a regression, or completely incompatible with how the >>> >> built-in >>> >> app stores its data. >>> >> >>> >> >>> >> >>> >> On Wed, Jan 21, 2009 at 9:42 AM, Disconnect >>> >> wrote: >>> >>> >>> >>> ..android-platform covers building apps with the sdk? Thats new. >>> >>> >>> >>> I think he's looking for info on changing package names so that he can >>> >>> replace the default apps. (I don't have that info handy, sorry..) >>> >>> >>> >>> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler >>> >>> wrote: >>> >>> Wrong list. Please see android-platform, which covers topics such as >>> this. >>> >>> http://source.android.com/discuss for more information. >>> >>> >>> On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: >>> > >>> > Hi, >>> > I want to customize some built-in applications on android, for >>> > example >>> > Launcher or Contacts, etc. >>> > I've downl
[android-developers] Re: How to re-install & sign android built-in applications
> I don't understand why taking the AOSP launcher, for example, and modifying > it is "simply not correct" but writing one from scratch is..? You can, Dianne just said that you need to change its package name to avoid conflicting with the system apps. That's all. That's what K9 does with Email. So take the launcher, modify it and install it but change its package name. > > I thought part of the point of the AOSP was that you could use those apps as > bases for your own development. (I can go digging for more > website/marketing/etc quotes if you really want, but..) > > > On Wed, Jan 21, 2009 at 3:04 PM, Romain Guy wrote: >> >> Replacing a core application is achieved using intent filters. This is >> how you can replace Home with your own application or replace Browser >> with your own web browser, et. >> >> On Wed, Jan 21, 2009 at 11:58 AM, Disconnect >> wrote: >> > I thought one of the core tenants of Android was that developers could >> > write, and end users could install, apps that replaced the default apps. >> > (Such as k9 and k9sms.) >> > >> > Is this not, in fact, true? (And please don't try to claim that sms/mms >> > isn't a core feature of a mobile phone OS. And both of those projects >> > are, >> > from the start, forks of the AOSP applications.) >> > >> > Looking at the Android page (http://code.google.com/android/) I see: >> > >> > Any app on the mobile device can be replaced or extended -- even core >> > components such as the dialer or home. >> > >> > ..the dialer has already been hashed over (at best, you can make >> > non-emergency calls, but you cannot in fact "replace or extend" the >> > dialer >> > completely.) Are you now saying that the entire statement is false? >> > >> > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn >> > wrote: >> >> >> >> Yes in this case probably what is desired is changing the package name, >> >> though that wasn't explicitly requested. But in Android that is how >> >> you >> >> install an alternative version of an app -- by installing a -different- >> >> app >> >> with the same public capabilities (handling the same intents etc) as >> >> the >> >> built-in app. Then the user is free to decide when and where they want >> >> to >> >> use that new app, if at all. >> >> >> >> For the desire to just install a custom version of a built-in app that >> >> has >> >> the same name, and is thus treated as a new version, of the built-in >> >> app, >> >> the basic answer is: >> >> >> >> - In the current platform, it is not possible to install an UPDATE (key >> >> word) to a built-in application in to the data partition; updates can >> >> only >> >> be done by replacing the app in /system. >> >> - In Cupcake we will have this facility, HOWEVER: >> >> 1. You still must be able to sign the app with the same certificate >> >> as >> >> the version in the system partition. If you can't, you can't update >> >> it. >> >> Only the original author of an application can create new versions of >> >> their >> >> own applications. You won't be able to do this with any of the >> >> built-in >> >> apps, because HTC and Google own the various certificates. >> >> 2. It simply is not correct to install a your own update to one of >> >> the >> >> system apps (contacts, calendar, etc) because those are part of the >> >> open >> >> source platform and the company who made the phone you are installing >> >> it on >> >> could have customized that app in significant ways. Your "update" >> >> could >> >> actually be a regression, or completely incompatible with how the >> >> built-in >> >> app stores its data. >> >> >> >> >> >> >> >> On Wed, Jan 21, 2009 at 9:42 AM, Disconnect >> >> wrote: >> >>> >> >>> ..android-platform covers building apps with the sdk? Thats new. >> >>> >> >>> I think he's looking for info on changing package names so that he can >> >>> replace the default apps. (I don't have that info handy, sorry..) >> >>> >> >>> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler >> >>> wrote: >> >> Wrong list. Please see android-platform, which covers topics such as >> this. >> >> http://source.android.com/discuss for more information. >> >> >> On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: >> > >> > Hi, >> > I want to customize some built-in applications on android, for >> > example >> > Launcher or Contacts, etc. >> > I've downloaded the source code and compile it by eclipse >> > successfully. >> > But when I tried to run it, a signing error comes: >> > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... >> > [2009-01-20 16:17:35 - Launcher] Application already exists. >> > Attempting to re-install instead... >> > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to >> > different application signatures. >> > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall >> > of >> > the application. WARNING: This will remove the
[android-developers] Re: How to re-install & sign android built-in applications
I don't understand why taking the AOSP launcher, for example, and modifying it is "simply not correct" but writing one from scratch is..? I thought part of the point of the AOSP was that you could use those apps as bases for your own development. (I can go digging for more website/marketing/etc quotes if you really want, but..) On Wed, Jan 21, 2009 at 3:04 PM, Romain Guy wrote: > > Replacing a core application is achieved using intent filters. This is > how you can replace Home with your own application or replace Browser > with your own web browser, et. > > On Wed, Jan 21, 2009 at 11:58 AM, Disconnect > wrote: > > I thought one of the core tenants of Android was that developers could > > write, and end users could install, apps that replaced the default apps. > > (Such as k9 and k9sms.) > > > > Is this not, in fact, true? (And please don't try to claim that sms/mms > > isn't a core feature of a mobile phone OS. And both of those projects > are, > > from the start, forks of the AOSP applications.) > > > > Looking at the Android page (http://code.google.com/android/) I see: > > > > Any app on the mobile device can be replaced or extended -- even core > > components such as the dialer or home. > > > > ..the dialer has already been hashed over (at best, you can make > > non-emergency calls, but you cannot in fact "replace or extend" the > dialer > > completely.) Are you now saying that the entire statement is false? > > > > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn > > wrote: > >> > >> Yes in this case probably what is desired is changing the package name, > >> though that wasn't explicitly requested. But in Android that is how you > >> install an alternative version of an app -- by installing a -different- > app > >> with the same public capabilities (handling the same intents etc) as the > >> built-in app. Then the user is free to decide when and where they want > to > >> use that new app, if at all. > >> > >> For the desire to just install a custom version of a built-in app that > has > >> the same name, and is thus treated as a new version, of the built-in > app, > >> the basic answer is: > >> > >> - In the current platform, it is not possible to install an UPDATE (key > >> word) to a built-in application in to the data partition; updates can > only > >> be done by replacing the app in /system. > >> - In Cupcake we will have this facility, HOWEVER: > >> 1. You still must be able to sign the app with the same certificate as > >> the version in the system partition. If you can't, you can't update it. > >> Only the original author of an application can create new versions of > their > >> own applications. You won't be able to do this with any of the built-in > >> apps, because HTC and Google own the various certificates. > >> 2. It simply is not correct to install a your own update to one of the > >> system apps (contacts, calendar, etc) because those are part of the open > >> source platform and the company who made the phone you are installing it > on > >> could have customized that app in significant ways. Your "update" could > >> actually be a regression, or completely incompatible with how the > built-in > >> app stores its data. > >> > >> > >> > >> On Wed, Jan 21, 2009 at 9:42 AM, Disconnect > >> wrote: > >>> > >>> ..android-platform covers building apps with the sdk? Thats new. > >>> > >>> I think he's looking for info on changing package names so that he can > >>> replace the default apps. (I don't have that info handy, sorry..) > >>> > >>> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler > >>> wrote: > > Wrong list. Please see android-platform, which covers topics such as > this. > > http://source.android.com/discuss for more information. > > > On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: > > > > Hi, > > I want to customize some built-in applications on android, for > example > > Launcher or Contacts, etc. > > I've downloaded the source code and compile it by eclipse > > successfully. > > But when I tried to run it, a signing error comes: > > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... > > [2009-01-20 16:17:35 - Launcher] Application already exists. > > Attempting to re-install instead... > > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to > > different application signatures. > > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall > of > > the application. WARNING: This will remove the application data! > > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall > > com.android.launcher' in a shell. > > > > I followed above instruction: adb uninstall com.android.launcher, > but > > it failed (Can't remove the application). > > The official document only provides "How to sign a new application", > > but it's not usable in my case. > > > > Does anyone know how to do
[android-developers] Re: How to re-install & sign android built-in applications
Replacing a core application is achieved using intent filters. This is how you can replace Home with your own application or replace Browser with your own web browser, et. On Wed, Jan 21, 2009 at 11:58 AM, Disconnect wrote: > I thought one of the core tenants of Android was that developers could > write, and end users could install, apps that replaced the default apps. > (Such as k9 and k9sms.) > > Is this not, in fact, true? (And please don't try to claim that sms/mms > isn't a core feature of a mobile phone OS. And both of those projects are, > from the start, forks of the AOSP applications.) > > Looking at the Android page (http://code.google.com/android/) I see: > > Any app on the mobile device can be replaced or extended -- even core > components such as the dialer or home. > > ..the dialer has already been hashed over (at best, you can make > non-emergency calls, but you cannot in fact "replace or extend" the dialer > completely.) Are you now saying that the entire statement is false? > > On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn > wrote: >> >> Yes in this case probably what is desired is changing the package name, >> though that wasn't explicitly requested. But in Android that is how you >> install an alternative version of an app -- by installing a -different- app >> with the same public capabilities (handling the same intents etc) as the >> built-in app. Then the user is free to decide when and where they want to >> use that new app, if at all. >> >> For the desire to just install a custom version of a built-in app that has >> the same name, and is thus treated as a new version, of the built-in app, >> the basic answer is: >> >> - In the current platform, it is not possible to install an UPDATE (key >> word) to a built-in application in to the data partition; updates can only >> be done by replacing the app in /system. >> - In Cupcake we will have this facility, HOWEVER: >> 1. You still must be able to sign the app with the same certificate as >> the version in the system partition. If you can't, you can't update it. >> Only the original author of an application can create new versions of their >> own applications. You won't be able to do this with any of the built-in >> apps, because HTC and Google own the various certificates. >> 2. It simply is not correct to install a your own update to one of the >> system apps (contacts, calendar, etc) because those are part of the open >> source platform and the company who made the phone you are installing it on >> could have customized that app in significant ways. Your "update" could >> actually be a regression, or completely incompatible with how the built-in >> app stores its data. >> >> >> >> On Wed, Jan 21, 2009 at 9:42 AM, Disconnect >> wrote: >>> >>> ..android-platform covers building apps with the sdk? Thats new. >>> >>> I think he's looking for info on changing package names so that he can >>> replace the default apps. (I don't have that info handy, sorry..) >>> >>> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler >>> wrote: Wrong list. Please see android-platform, which covers topics such as this. http://source.android.com/discuss for more information. On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: > > Hi, > I want to customize some built-in applications on android, for example > Launcher or Contacts, etc. > I've downloaded the source code and compile it by eclipse > successfully. > But when I tried to run it, a signing error comes: > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... > [2009-01-20 16:17:35 - Launcher] Application already exists. > Attempting to re-install instead... > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to > different application signatures. > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall of > the application. WARNING: This will remove the application data! > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall > com.android.launcher' in a shell. > > I followed above instruction: adb uninstall com.android.launcher, but > it failed (Can't remove the application). > The official document only provides "How to sign a new application", > but it's not usable in my case. > > Does anyone know how to do it? > Thank you very much > > Gerald > > > > >>> >>> >>> >> >> >> >> -- >> Dianne Hackborn >> Android framework engineer >> hack...@android.com >> >> Note: please don't send private questions to me, as I don't have time to >> provide private support. All such questions should be posted on public >> forums, where I and others can see and answer them. >> >> >> > > > > > -- Romain Guy Android framework engineer romain...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions shoul
[android-developers] Re: How to re-install & sign android built-in applications
I thought one of the core tenants of Android was that developers could write, and end users could install, apps that replaced the default apps. (Such as k9 and k9sms.) Is this not, in fact, true? (And please don't try to claim that sms/mms isn't a core feature of a mobile phone OS. And both of those projects are, from the start, forks of the AOSP applications.) Looking at the Android page (http://code.google.com/android/) I see: *Any app on the mobile device can be replaced or extended -- even core components such as the dialer or home.* ..the dialer has already been hashed over (at best, you can make non-emergency calls, but you cannot in fact "replace or extend" the dialer completely.) Are you now saying that the entire statement is false? On Wed, Jan 21, 2009 at 2:41 PM, Dianne Hackborn wrote: > Yes in this case probably what is desired is changing the package name, > though that wasn't explicitly requested. But in Android that is how you > install an alternative version of an app -- by installing a -different- app > with the same public capabilities (handling the same intents etc) as the > built-in app. Then the user is free to decide when and where they want to > use that new app, if at all. > > For the desire to just install a custom version of a built-in app that has > the same name, and is thus treated as a new version, of the built-in app, > the basic answer is: > > - In the current platform, it is not possible to install an UPDATE (key > word) to a built-in application in to the data partition; updates can only > be done by replacing the app in /system. > - In Cupcake we will have this facility, HOWEVER: > 1. You still must be able to sign the app with the same certificate as > the version in the system partition. If you can't, you can't update it. > Only the original author of an application can create new versions of their > own applications. You won't be able to do this with any of the built-in > apps, because HTC and Google own the various certificates. > 2. It simply is not correct to install a your own update to one of the > system apps (contacts, calendar, etc) because those are part of the open > source platform and the company who made the phone you are installing it on > could have customized that app in significant ways. Your "update" could > actually be a regression, or completely incompatible with how the built-in > app stores its data. > > > > > On Wed, Jan 21, 2009 at 9:42 AM, Disconnect wrote: > >> ..android-platform covers building apps with the sdk? Thats new. >> >> I think he's looking for info on changing package names so that he can >> replace the default apps. (I don't have that info handy, sorry..) >> >> >> On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler wrote: >> >>> >>> Wrong list. Please see android-platform, which covers topics such as >>> this. >>> >>> http://source.android.com/discuss for more information. >>> >>> >>> On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: >>> > >>> > Hi, >>> > I want to customize some built-in applications on android, for example >>> > Launcher or Contacts, etc. >>> > I've downloaded the source code and compile it by eclipse >>> > successfully. >>> > But when I tried to run it, a signing error comes: >>> > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... >>> > [2009-01-20 16:17:35 - Launcher] Application already exists. >>> > Attempting to re-install instead... >>> > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to >>> > different application signatures. >>> > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall of >>> > the application. WARNING: This will remove the application data! >>> > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall >>> > com.android.launcher' in a shell. >>> > >>> > I followed above instruction: adb uninstall com.android.launcher, but >>> > it failed (Can't remove the application). >>> > The official document only provides "How to sign a new application", >>> > but it's not usable in my case. >>> > >>> > Does anyone know how to do it? >>> > Thank you very much >>> > >>> > Gerald >>> > >>> > > >>> > >>> >>> >>> >> >> >> > > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to re-install & sign android built-in applications
Yes in this case probably what is desired is changing the package name, though that wasn't explicitly requested. But in Android that is how you install an alternative version of an app -- by installing a -different- app with the same public capabilities (handling the same intents etc) as the built-in app. Then the user is free to decide when and where they want to use that new app, if at all. For the desire to just install a custom version of a built-in app that has the same name, and is thus treated as a new version, of the built-in app, the basic answer is: - In the current platform, it is not possible to install an UPDATE (key word) to a built-in application in to the data partition; updates can only be done by replacing the app in /system. - In Cupcake we will have this facility, HOWEVER: 1. You still must be able to sign the app with the same certificate as the version in the system partition. If you can't, you can't update it. Only the original author of an application can create new versions of their own applications. You won't be able to do this with any of the built-in apps, because HTC and Google own the various certificates. 2. It simply is not correct to install a your own update to one of the system apps (contacts, calendar, etc) because those are part of the open source platform and the company who made the phone you are installing it on could have customized that app in significant ways. Your "update" could actually be a regression, or completely incompatible with how the built-in app stores its data. On Wed, Jan 21, 2009 at 9:42 AM, Disconnect wrote: > ..android-platform covers building apps with the sdk? Thats new. > > I think he's looking for info on changing package names so that he can > replace the default apps. (I don't have that info handy, sorry..) > > > On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler wrote: > >> >> Wrong list. Please see android-platform, which covers topics such as >> this. >> >> http://source.android.com/discuss for more information. >> >> >> On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: >> > >> > Hi, >> > I want to customize some built-in applications on android, for example >> > Launcher or Contacts, etc. >> > I've downloaded the source code and compile it by eclipse >> > successfully. >> > But when I tried to run it, a signing error comes: >> > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... >> > [2009-01-20 16:17:35 - Launcher] Application already exists. >> > Attempting to re-install instead... >> > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to >> > different application signatures. >> > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall of >> > the application. WARNING: This will remove the application data! >> > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall >> > com.android.launcher' in a shell. >> > >> > I followed above instruction: adb uninstall com.android.launcher, but >> > it failed (Can't remove the application). >> > The official document only provides "How to sign a new application", >> > but it's not usable in my case. >> > >> > Does anyone know how to do it? >> > Thank you very much >> > >> > Gerald >> > >> > > >> > >> >> >> > > > > -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to re-install & sign android built-in applications
..android-platform covers building apps with the sdk? Thats new. I think he's looking for info on changing package names so that he can replace the default apps. (I don't have that info handy, sorry..) On Wed, Jan 21, 2009 at 12:14 PM, Andrew Stadler wrote: > > Wrong list. Please see android-platform, which covers topics such as this. > > http://source.android.com/discuss for more information. > > > On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: > > > > Hi, > > I want to customize some built-in applications on android, for example > > Launcher or Contacts, etc. > > I've downloaded the source code and compile it by eclipse > > successfully. > > But when I tried to run it, a signing error comes: > > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... > > [2009-01-20 16:17:35 - Launcher] Application already exists. > > Attempting to re-install instead... > > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to > > different application signatures. > > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall of > > the application. WARNING: This will remove the application data! > > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall > > com.android.launcher' in a shell. > > > > I followed above instruction: adb uninstall com.android.launcher, but > > it failed (Can't remove the application). > > The official document only provides "How to sign a new application", > > but it's not usable in my case. > > > > Does anyone know how to do it? > > Thank you very much > > > > Gerald > > > > > > > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
[android-developers] Re: How to re-install & sign android built-in applications
Wrong list. Please see android-platform, which covers topics such as this. http://source.android.com/discuss for more information. On Tue, Jan 20, 2009 at 12:24 AM, Gerald wrote: > > Hi, > I want to customize some built-in applications on android, for example > Launcher or Contacts, etc. > I've downloaded the source code and compile it by eclipse > successfully. > But when I tried to run it, a signing error comes: > [2009-01-20 16:17:27 - Launcher] Installing Launcher.apk... > [2009-01-20 16:17:35 - Launcher] Application already exists. > Attempting to re-install instead... > [2009-01-20 16:17:43 - Launcher] Re-installation failed due to > different application signatures. > [2009-01-20 16:17:43 - Launcher] You must perform a full uninstall of > the application. WARNING: This will remove the application data! > [2009-01-20 16:17:43 - Launcher] Please execute 'adb uninstall > com.android.launcher' in a shell. > > I followed above instruction: adb uninstall com.android.launcher, but > it failed (Can't remove the application). > The official document only provides "How to sign a new application", > but it's not usable in my case. > > Does anyone know how to do it? > Thank you very much > > Gerald > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~--~~~~--~~--~--~---
