[android-developers] Storing IMEI on Android M
Hi, I am developing a payment domain application. My application have extensive use of IMEI number, so I block the user at the very first start of the application for phone permission and when user allow the phone permission application stores IMEI number in DB. I wants to make sure that storing IMEI on android M device should not be an issue. Would like to have thoughts from others about it. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/5554f88c-5be9-42a7-8107-0344937f5dfd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[android-developers] Extending the SurfaceFlinger Layers in NDK
Hi, Is it possible to extend SurfaceFlinger/Layer in an app built with the NDK? I want to do something like this: http://jsharkey.org/blog/2010/07/01/android-surfaceflinger-tricks-for-fun-and-profit/ By looking at the surfaceflinger code it seems conceptually possible. However I have not used the NDK much and haven't seen an example of this on the internet. Hence, would like to know if there are any known gotchas, before I dive deep into this rabbit hole. thanks, Harshad -- -- 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 --- You received this message because you are subscribed to the Google Groups Android Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to android-developers+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [android-developers] Android Library Project Changes
On Fri, Mar 23, 2012 at 10:33 AM, Nikolay Elenkov nikolay.elen...@gmail.com wrote: Library projects now (since ADT15?) produce a jar. Linked source folders are now longer used, so there is no code merging. Thanks Nikolay for confirming that. Don't refer to A.java directly. Put an abstract class or interface in the library project, different implementations in the app projects, etc. That is a good solution when there are few well separated classes. In my case there are many intricate dependencies which makes this cumbersome. I found a workaround. I moved the contents of the *src* folder in the Library project into a new folder called *libsrc* (some name different from src). I then link this folder into my dependent projects (Project - Properties - Java Build Path - Source - Link Source). So, Eclipse does the code merging now, instead of the Android SDK. Works like a charm and I didn't have to make any changes to the source code! Another benefit is that when I try to navigate to a class (with say Ctrl+T), I don't see duplicate classes from the Library project. Ditto for duplicate errors, search results, etc. The only hitch is I haven't figured out the Ant equivalent of this. (I may not need it anyway since the new SDK+ADT has good Proguard support). cheers, -- Harshad RJ http://lavadip.com -- 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: Can't get SdkControllerSensorActivity to compile
On Thursday, 22 March 2012 13:12:58 UTC+5:30, kingtut wrote: I am trying to get the SdkControllerSensorActivity to compile to run on my device, I keep getting the following error: *The container 'Android Dependencies' references non existing library '[SDK_PATH]/tools/apps/SdkController/SdkControllerLib/bin/com_android_tools_sdkcontroller_lib.jar' SdkControllerSensorActivity Build Path Problem * even though I included the SDKControllerLib as a library project. I am having the same problem with a project that has a dependency on an Android library project. -- 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: Can't get SdkControllerSensorActivity to compile
On Thursday, 22 March 2012 17:15:06 UTC+5:30, Harshad wrote: On Thursday, 22 March 2012 13:12:58 UTC+5:30, kingtut wrote: I am trying to get the SdkControllerSensorActivity to compile to run on my device, I keep getting the following error: *The container 'Android Dependencies' references non existing library '[SDK_PATH]/tools/apps/SdkController/SdkControllerLib/bin/com_android_tools_sdkcontroller_lib.jar' SdkControllerSensorActivity Build Path Problem * even though I included the SDKControllerLib as a library project. I am having the same problem with a project that has a dependency on an Android library project. Sorry for spamming; I forgot to mention I have: - Eclipse Indigo - SDK and ADT version 17, which I just updated to from 16. Didn't have this problem earlier. -- 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] Android Library Project Changes
Hi, I am trying to migrate to the newly released SDK and ADT 17 from my earlier setup of SDK 12. (I couldn't use the intermediate SDK releases because of some problems that were fixed only in SDK 17). One of the problems I am facing now is that Projects which use an Android Library Project are not building properly. From what I understand, in the newer SDKs, the Library project needs to be compilable by itself, while in earlier versions that was not necessary. In earlier versions, the source code from the library projects was merged with the final project and then compiled. Is that correct? For example, if I have the following files: *Free Project / A.java* *Pro Project / A.java* *Library Project / B.java** // Refers to A.java* This used to work fine in earlier SDKs and allow me to keep common source code between free and Pro versions in the Library Project. But this isn't supported now. Is my understanding correct? If so, what are the best practices for handling such a scenario? One idea is: add a dummy A.java to the Library Project so that the library project compiles. I am hoping that the A.class from the Library Project will get overridden by the A.class from the dependent projects. Could there be problems with such an approach? thanks, Harshad -- 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: lights out mode PLUS menu soft key?
I hit the same problem with my app. Why is the menu button hidden in the higher Android versions? If the Home and Back buttons are going to be there, why not also keep the menu button in the status bar? Is the menu system deprecated? I don't want to create a separate UI for this when there is already space at the bottom for such options. Moreover the Menu thing is an established paradigm for years; why should users and developers change the paradigm for no apparent reason. -- 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
Re: [android-developers] Re: lights out mode PLUS menu soft key?
On Tue, Mar 13, 2012 at 6:50 AM, Dianne Hackborn hack...@android.comwrote: Yes the menu button is deprecated. The menu is now part of the ActionBar as described at http://developer.android.com/design/patterns/actionbar.html Thanks for the clear response Dianne. I wasn't aware of it being deprecated. If managers of the AOSP care for feedback, let me just say *this sucks!* Single developers have to already break their backs to handle hardware fragmentation. On top of this, there is software fragmentation due to manufacturer/vendor added skins (though I appreciate efforts like the Halo theme). And now basic paradigms are also changing between Android versions. All the design effort in my app for previous versions of Android is wasted; there is absolutely no space left for an on-screen menu button in my app, and certainly not for an action bar, so I will have to redesign everything or walk the low path and just tuck the button in there somewhere :) Also, from user point of view, if he/she has multiple devices with different Android versions, they are going to see different UIs for the same app! Please lets channel our collective energies into something more productive. cheers, -- Harshad RJ http://lavadip.com -- 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
Re: [android-developers] Re: lights out mode PLUS menu soft key?
On Tue, Mar 13, 2012 at 6:50 AM, Dianne Hackborn hack...@android.comwrote: Yes the menu button is deprecated. The menu is now part of the ActionBar as described at http://developer.android.com/design/patterns/actionbar.html There's also an Android Developers blog post on this: http://android-developers.blogspot.in/2012/01/say-goodbye-to-menu-button.html I had somehow missed that. Hopefully that's useful to the next person who bumps into this thread. In that post: The only exception is that if you set minSdkVersion to 10 or lower, set targetSdkVersion to 11, 12, or 13, and you do not use ActionBarhttp://developer.android.com/reference/android/app/ActionBar.html, the system *will* add the legacy overflow button when running your app *on a handset* with Android 4.0 or higher. I am not able to trigger the overflow button this way. In my AndroidManifest.xml I have: uses-sdk android:minSdkVersion=7 android:targetSdkVersion=11 / and application android:theme=@android:style/Theme.Holo.NoActionBar But this doesn't show the legacy overflow buttons. If I could get that to work, it will solve the immediate problem I am facing which is to get into Lights off mode and yet have a way to go to the legacy options menu from the navigation bar on the bottom . thanks, -- Harshad RJ http://lavadip.com -- 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
Re: [android-developers] search hardware button
But as far as I know, long pressing the menu button triggers an (emulated) hardware search button. This is based on my experience with Samsung Galaxy 3 -- 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] [RFC] URL Fetch service
Have any of you app developers faced this situation: You have an app that needs to download data from the Internet, but don't want to add the Internet permission to your application, because it may deter some users from installing the app. Moreover, the data may be large and may need to be saved to the SD card, which requires yet another permission. You also need to ensure that a network is available currently, which means more permissions (WiFi state, etc). Here's my proposed solution: *A URL fetch service* This will be a simple app which accepts URL fetch requests from other applications and fetches them (HTTP GET) from the internet as a background service. Upon completion, the data can be returned to the application as a string or optionally saved to the SD card (and served via a content provider). Since this is based on a callback, the network need not be currently available. The service will (optionally) queue the request and fetch whenever a network is available. Another useful feature would be avoiding duplicate requests. For example, an app may want to fetch some data periodically, say every two hours. But if the network is not available for two days, then only one request should be made when the network becomes available, not 50! This could be done by letting the app assign a unique id to the request. Requests that have the same id will over-write other requests from the same app with the same id. *Logging and Filtering* From the user point of view, there is tremendous advantage in having a centralized URL Fetcher, because she will be able to Log the requests that go through it, and also filter some requests. For example, she could filter an app that she doesn't want to be updated (for whatever reason). *Distribution:* The app will be open-source and made available on all App markets and also as a direct APK download. The only hurdle to this idea that I can see is that the app will have to be installed separately by the user. The problem will be reduced over time as more and more apps use this service. So the chances of the app being already present will increase. Also, custom and vendor supplied ROMs might pre-package this app, so it will be present by default. __ Your thoughts? -- 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
