All the builds with the same build fingerprint are binary wise equal.
I am curious to know does this information from the /system/etc/
permissions/*.xml - all of it gets transmitted back to market server
from every single device or happens only for the first device with
that build fingerprint.
The filtering doesn't seem to happen for search (I can see the app on
the device which doesn't have the library defined as required in the
apk), but mostly when the user clicks on the app to get more info.
Then it shows a dialog saying - "Not found - The requested item could
not be found"
(I am testing this on the cupcake 1.5 device)
-Dan
On Nov 10, 8:10 pm, dan raaka <danra...@gmail.com> wrote:
> You answered my Q in your last sentence. Thanks :)
>
> -Dan
>
> On Mon, Nov 9, 2009 at 3:25 PM, Dianne Hackborn <hack...@android.com> wrote:
> > Sorry I don't understand what you are asking. When you set up the
> > configuration for your build, you can decide whatever files you want in your
> > system image, so you would just have your library's XML file included. When
> > market runs, it asks the system what shared libraries are available (which
> > is just an array of library package names), and sends this information to
> > the server for it to appropriately filter the apps that are shown.
>
> > On Mon, Nov 9, 2009 at 1:52 PM, dan raaka <danra...@gmail.com> wrote:
>
> >> 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 <hack...@android.com>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 <danra...@gmail.com> 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 <hack...@android.com> 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
> >>>> > hack...@android.com
>
> >>>> > 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:
> >>>> android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com>
> >>>> website:http://groups.google.com/group/android-porting
>
> >>> --
> >>> 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, 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:
> >>> android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com>
> >>> website:http://groups.google.com/group/android-porting
>
> >> --
> >> unsubscribe:
> >> android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com>
> >> website:http://groups.google.com/group/android-porting
>
> > --
> > 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, 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:
> > android-porting+unsubscr...@googlegroups.com<android-porting%2bunsubscr...@googlegroups.com>
> > website:http://groups.google.com/group/android-porting
--
unsubscribe: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
