I understand the system inclusion part but currently in build submissions for approval process, there is now where one specifies details of additional libraries included in the build.
My question is how do you get this info then? I am guessing .. permissions file from the build is sent to from the device to the Google servers by one of the GMS components? -Dan On Mon, Nov 9, 2009 at 1:26 PM, Dianne Hackborn <[email protected]> wrote: > As the PlatformLibrary shows, you place an xml file in > /system/etc/permissions which defines the library, and the system picks this > up. For example Google's maps library is in the file > /system/etc/permissions/com.google.android.maps.xml with the contents: > > <?xml version="1.0" encoding="utf-8"?> > <permissions> > <library name="com.google.android.maps" > file="/system/framework/com.google.android.maps.jar" /> > </permissions> > > > On Mon, Nov 9, 2009 at 10:57 AM, Dan Raaka <[email protected]> wrote: > >> Where do you get the information about these extended libraries from >> the a OEM build ? >> >> -Dan >> >> On Oct 7, 9:53 pm, Dianne Hackborn <[email protected]> wrote: >> > Hi all, >> > >> > I would like to make a request for the people who are making custom >> builds >> > of Android for users to install on their phones. >> > >> > If you are going to allow the user to keep Market on their phone, and >> are >> > adding any new features, please do this the official way: include your >> own >> > shared library with the features that applications use, rather than >> having >> > magic hacks in the framework for them. (Some of the things I am talking >> > about is redefining MotionEvent for multi-touch data, or I believe the >> magic >> > permission that is used for apps to be root.) >> > >> > In the source base you can find the PlatformLibrary sample code, which >> shows >> > the official way to add custom extensions to the platform. Some key >> points >> > about this: >> > >> > - For applications to use your new features, they must explicitly link >> with >> > the library (via <uses-library> in their manifest), ensuring there are >> no >> > conflicts with future changes to the platform or other vendors. >> > >> > - Market keeps track of the libraries available on a device and the >> > libraries needed by an application, to only show applications to the >> user >> > that are compatible with a device. No more need for for developers to >> say >> > "works only with rooted phones" or what not, no more making users dig >> > through apps that are not relevant to them. >> > >> > - This allows you to supply an AVD add-on for developers to use your >> APIs in >> > the standard development environment. >> > >> > Some examples of how you may use this: >> > >> > - For adding multitouch to the platform, the MotionEvent API should be >> left >> > alone. Instead, you can add new (hidden) parts to it containing the >> > multitouch information. Then in your platform library you can have a >> class >> > like MultiTouchAccessor that allows applications to retrieve the >> extended >> > multitouch data from the event for example like this: >> > >> > public class MultiTouchAccessor { >> > public static float getSecondaryX(MotionEvent event) { >> > return event.getSeconaryX(); >> > } >> > public static float getSecondaryY(MotionEvent event) { >> > return event.getSeconaryY(); >> > } >> > } >> > >> > For a permission that allows an application to be root, it is okay to >> add >> > the permission to the framework as long as it is not in the android.* or >> > com.android.* namespace, but in a namespace someone else owns. However, >> > there still must be some kind of shared library (even if it is a stub) >> for >> > the application to request along with it, and the package manager should >> not >> > allow the application get this permission unless they also request the >> > shared library. This is to ensure that developers mark their apps as >> > requiring this new "api", so that market can filter them. >> > >> > Thanks! >> > >> > -- >> > Dianne Hackborn >> > Android framework engineer >> > [email protected] >> > >> > Note: please don't send private questions to me, as I don't have time to >> > provide private support, and so won't reply to such e-mails. All such >> > questions should be posted on public forums, where I and others can see >> and >> > answer them. >> >> -- >> unsubscribe: >> [email protected]<android-porting%[email protected]> >> website: http://groups.google.com/group/android-porting >> > > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > > Note: please don't send private questions to me, as I don't have time to > provide private support, and so won't reply to such e-mails. All such > questions should be posted on public forums, where I and others can see and > answer them. > > -- > unsubscribe: > [email protected]<android-porting%[email protected]> > website: http://groups.google.com/group/android-porting > -- unsubscribe: [email protected] website: http://groups.google.com/group/android-porting
