[android-developers] Digest for android-developers@googlegroups.com - 12 Messages in 10 Topics

Group: http://groups.google.com/group/android-developers/topics

    galapogos <goister@gmail.com> Dec 30 08:43PM -0800  

    Is there any way of removing the private APIs so that the AOSP launcher may
    be used with any Android device? I'm specifically trying to first get the
    ICS AOSP launcher to install on any ICS phone, and then modify it with some
    Would appreciate any pointers on how to remove the private APIs. I don't
    necessarily have to use Eclipse, I'm fine with "make Launcher2".
    On Wednesday, September 22, 2010 1:14:09 AM UTC+8, Dianne Hackborn wrote:


    galapogos <goister@gmail.com> Dec 30 08:36PM -0800  

    Is it possible to build the ICS AOSP launcher without private APIs so that
    it will install into any ICS device? I've tried to build the ICS AOSP
    launcher from the AOSP source but had trouble installing it into regular
    ICS devices. I keep getting the error INSTALL_FAILED_DEXOPT.


    William Ferguson <william.ferguson@xandar.com.au> Dec 30 02:24PM -0800  

    Use case:
    I have a log file (courtesy of the changes to log access in Jellybean) that
    I want to allow a user to send me along with some notes that they make etc.
    I want the process to be transparent to the user. I want to reuse existing
    rather build a lot of infrastructure myself. And I don't want to add any
    new permissions like WRITE_EXTERNAL_STORAGE. I want this simple as it is
    far from core functionality .
    Current design:
    I create a the log file using
    http://developer.android.com/reference/android/content/Context.html#MODE_WORLD_READABLEand use a send Intent with the Uri to the file passed as
    Intent.EXTRA_STREAM along with the contact email address. This hands off to
    the email client and the user send an email containing the attached logs
    plus any notes. This is almost ideal except that MODE_WORLD_READABLE has
    been deprecated as of API#17.
    So considering the use case how do I rebuild without using


    Mark Murphy <mmurphy@commonsware.com> Dec 30 05:45PM -0500  

    On Sun, Dec 30, 2012 at 5:24 PM, William Ferguson
    > So considering the use case how do I rebuild without using
    Create a ContentProvider to serve the file using openFile(). Then use
    a content:// Uri instead of a file:// Uri. This may reduce the number
    of apps that can handle the ACTION_SEND Intent -- those that
    advertised that they specifically support file:// instead of just
    generically supporting the MIME type will not show up in your chooser.
    Here is a sample project that packages a PDF file in an asset, unpacks
    it on first run, then makes that PDF available via a ContentProvider
    and views it using ACTION_SEND and your chosen PDF viewer:
    Mark Murphy (a Commons Guy)
    http://commonsware.com | http://github.com/commonsguy
    http://commonsware.com/blog | http://twitter.com/commonsguy
    In questi siti web puoi chiedere o rispondere a domande relative allo
    sviluppo di applicazioni Android: http://www.andglobe.com


    TreKing <trekingapp@gmail.com> Dec 30 09:54PM -0600  

    On Sun, Dec 30, 2012 at 4:24 PM, William Ferguson <
    > rather build a lot of infrastructure myself. And I don't want to add any
    > new permissions like WRITE_EXTERNAL_STORAGE. I want this simple as it is
    > far from core functionality .
    You could use ACRA, or it's core idea: keep a local log file and then
    upload it to a Google Document or server where you can view the data. It's
    a pretty straightforward implementation.
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices


    TreKing <trekingapp@gmail.com> Dec 30 09:50PM -0600  

    > But there is no way to delete it !!!!
    What do you mean by this? What exactly is the issue you're having?
    TreKing <http://sites.google.com/site/rezmobileapps/treking> - Chicago
    transit tracking app for Android-powered devices


    Etienne <lawloretienne@gmail.com> Dec 30 04:19PM -0800  

    I am not clear whether this is an issue with different versions of Android,
    or different screen sizes, but I am getting some unpredictable behavior.
    I am testing the UI of the dropdown of a MultiAutoCompleteTextView on a Nexus
    S which is onAndroid v4.1.2 and I am testing on a Nexus 4 which is on Android
    When I begin to enter text into the MultiAutoCompleteTextView it returns
    some results. I have created a custom view which contains an ImageView to
    the left of a TextView. When the a row is first displayed, the ImageView will
    have a certain height, however once you scroll through the list of results
    and back up to that original row one of two things happens. Either the
    ImageView stays the same dimensions, or the dimensions of the ImageView will
    change. This specific behavior is happening on the Nexus 4, but I cannot
    reproduce this on the Nexus S.
    I am loading Bitmaps into ImageViews just like it is done in the developer
    training Loading Large Bitmaps Efficiently<http://developer.android.com/training/displaying-bitmaps/load-bitmap.html>
    Can anyone point me in the right direction as far as what to look into? Is
    this a screen resolution issue, or does the latest version of Android
    handle this situation differently than previous versions?


    niko20 <nikolatesla20@yahoo.com> Dec 30 03:36PM -0800  

    Put a boolean flag in there and you'll have to handle it yourself in some
    On Monday, December 24, 2012 5:16:52 AM UTC-6, Tamás Kovács wrote:


    niko20 <nikolatesla20@yahoo.com> Dec 30 03:35PM -0800  

    I'm not sure if that would be useful. From what I've read, OpenGL ES is
    actually more modern and streamlined and loses a lot of the crud that
    OpenGL has gained over the years. In effect it's a cleaner more modern
    implementation anyway.
    On Wednesday, December 26, 2012 11:21:42 AM UTC-6, bob wrote:


    Lew <lewbloch@gmail.com> Dec 30 02:45PM -0800  

    sebouh00 wrote:
    > Wouldn't I need a lock on the GPS location in order to get the altitude? I
    > would assume that would take more time, hence more power then just using
    > the barometer.
    Less power + wrong answer/no answer = ?
    What about the altitude apps. How do they usually determine the approximate
    > altitude. Do they suffer from +/- 500 meter inaccuracy?
    My brief Google search indicates GPS. I think not.
    What does your online search tell you?

    Mark Murphy (a Commons Guy) wrote:
    > of premature optimization, unless you have already implemented the
    > GPS-based solution and proven that the power consumption is over your
    > budget.
    Here Mark sends you to basic information about what you're trying to do.
    Your next
    response repeats the plaint that you don't know what you're doing. This
    despite your
    having just received relevant information. I suggest that you digest the
    information and
    utility of advice already offered.
    In case you missed it:
    - Barometric pressure will not do what you're asking /per se/.
    - You have not provided evidence that the GPS power requirements are
    - You have not commented on whether comparison with a topographic map plus
    recalibration, as suggested, will solve your problem. I'm guessing you
    haven't even
    tried it.


You received this message because you are subscribed to the Google Group android-developers.
You can post via email.
To unsubscribe from this group, send an empty message.
For more options, visit this group.

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
For more options, visit this group at

No comments:

Post a Comment