• Breaking News

    [Android][timeline][#f39c12]

    Tuesday, January 1, 2019

    Home Unlabelled OkHttp will drop Support for Android 4 in their next release Android Dev

    OkHttp will drop Support for Android 4 in their next release Android Dev

    January 01, 2019

    OkHttp will drop Support for Android 4 in their next release Android Dev

    OkHttp will drop Support for Android 4 in their next release

    Posted: 01 Jan 2019 06:21 AM PST

    Is it time to drop pre-lollipop support for your app(s)?

    Posted: 01 Jan 2019 12:19 PM PST

    Hi all,

    What is your recommendation for dropping support for the pre-lollipop versions of Android? Are there enough people to consider building for those releases of Android? Any other reason you might think of for not doing so. It would help out a lot of us guys write more stable code. Thanks!

    submitted by /u/nulless
    [link] [comments]

    Guidelines for Call Recorder apps for Google's Jan 9, 2019 deadline - and references to previous posts on Call/SMS fiasco

    Posted: 01 Jan 2019 02:04 AM PST

    EDIT: thanks to u/NLL-APPS correction, the restrictions may also apply to outgoing calls as well, if PROCESS_OUTGOING_CALLS is also now included in the 'CALL_LOG permissions group' for Pie (prior to Pie, PROCESS_OUTGOING_CALLS was in the 'PHONE permissions group'). So if an app were to remove not only READ_CALL_LOG permission from AndriodManifest (and run-time permissions), but also PROCESS_OUTGOING_CALLS, then that would mean both incoming, as well as outgoing calls would be anonymous i.e. no call number info would be available to the app. The app would be forced to show the recordings as uncategorized - only into incoming and outgoing categories. This would severely limit the UI or presentation of call recordings to the user. I have corrected the text below to reflect removal of PROCESS_OUTGOING_CALLS permission as well.

    EDIT: also added an anti-trust section, and the text of an e-mail to legal@google.com, sent out on a whim - so they are apprised of the mess the policy makers maybe getting Google into with their control over Google Play store in a future anti-trust fight.

    Guidelines for Call Recorder apps for Google's Jan 9, 2019 deadline - and references to previous posts on Call/SMS fiasco

    Starting with Android Pie 9.0, call recorder apps started using READ_CALL_LOG permission - without it their apps were not able to retrieve the incoming phone call number. One would think both incoming and outgoing call numbers would be unavailable, but practically it has been observed that just the incoming call number is not delivered (without READ_CALL_LOG) - the string returns null. This is what is observed when an app targets API 27 (Oreo 8.1), but is running on Pie 9.0 device (I have not tested what happens when app sets targetSdkVersion="28" (Pie 9.0) in AndroidManifest.xml i.e. starts targeting Pie).

    This means if apps are to remove the READ_CALL_LOG permission before the Jan 9, 2019 Google deadline for removal of Call/SMS permissions, then call recorder apps running on pre-Pie devices will function as before, but when running on Pie they would not be able to know the incoming call number for the call recording.

    However, call recorder app developers (and SMS backup app developers etc.) are under compulsion to remove 'CALL_LOG permissions group' permissions before the deadline, or face expulsion - so READ_CALL_LOG permissions will have to be removed, which means incoming phone number detection will have to be sacrificed.

     

    EDIT: However, (as u/NLL_APPS has pointed out in comments), the 'CALL_LOG permissions group' has been structured in Pie to now include:

    READ_CALL_LOG

    WRITE_CALL_LOG

    PROCESS_OUTGOING_CALLS

     

    EDIT: this means to fully comply with Google directive to remove 'CALL_LOG permissions group', you need to not only remove READ_CALL_LOG, but also PROCESS_OUTGOING_CALLS. When this happens, outgoing calls will become anonymous as well i.e. your app will not be able to get the outgoing call number. This will mean both incoming/outgoing numbers will become not known - and your app will not be able to categorize call recording beyond just the simple incoming/outgoing categories.

     

    Call recorder apps previously used the phone number to label, or categorize the call, so the user could find it later with ease.

    Some, like our app (which is primarily an audio recorder), just used it to label the folder the recording was being saved to. Other more professional call recorder apps would use it to show the contact name in a call recorder UI.

     

    What to do going forward ?

    App developers should remove the READ_CALL_LOG (EDIT: and the PROCESS_OUTGOING_CALLS) permission from their top level AndvoidManifest.xml - if some of your libraries are using it, you can override that in the top-level AndroidManifest.xml by adding tools:node="remove" to the declarations:

     

    change:

    <uses-permission android:name="android.permission.READ_CALL_LOG" />

    <uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS" />

    to:

    <uses-permission android:name="android.permission.READ_CALL_LOG" tools:node="remove" />

    <uses-permission android:name="android.permission.PROCESS_OUTGOING_CALLS" tools:node="remove" />

     

    Then remove these permission from the list of run-time permissions you request:

    Manifest.permission.READ_CALL_LOG

    Manifest.permission.PROCESS_OUTGOING_CALLS

    So remove these from the same place where you are requesting Manifest.permission.READ_PHONE_STATE permission - which you can keep using as before. Since you don't want to be asking for this READ_CALL_LOG, and PROCESS_OUTGOING_CALLS permissions at run-time, if you aren't requesting them in the AndroidManifest.xml.

     

    Now in your code, where you are retrieving the incoming and outgoing phone numbers, make sure you check the returned string for null. If it is null, just use some string of your choice, like "incoming"/"outgoing", or "unknown-incoming"/"unknown-outgoing" or whatever suits your app.

     

    change:

    // for incoming

    String incomingPhoneNum = extras.getString(TelephonyManager.EXTRA_INCOMING_NUMBER);

    to:

    // for incoming

    String incomingPhoneNum = extras.getString(TelephonyManager.EXTRA_INCOMING_NUMBER);

    if (incomingPhoneNum == null) {

     // could not retrieve phone number .. replace with something else incomingPhoneNum = "incoming";

    }

     

    change:

    // for outgoing

    String outgoingPhoneNum = intent.getStringExtra(Intent.EXTRA_PHONE_NUMBER);

    to:

    // for outgoing

    String outgoingPhoneNum = intent.getStringExtra(Intent.EXTRA_PHONE_NUMBER);

    if (outgoingPhoneNum == null) {

     // could not retrieve phone number .. replace with something else outgoingPhoneNum = "outgoing";

    }

     

    EDIT: however, to fully comply with Google directive, you should probably not even be querying for the phone number, and just assume it is null, and then just presume "incoming" or "outgoing" as above.

     

    Testing

    Now when testing on Oreo 8.1 (for example), both incoming and outgoing call numbers will still be retrievable by the app - the app will function as before. (this was only true if you just removed READ_CALL_LOG and didn't remove PROCESS_OUTGOING_CALLS)

    But on Pie 9.0, the incoming call number will be 'null', while outgoing call number will still be delivered to your app. So the only problem will be the incoming phone number, which will be delivered as 'null' string, for which you can substitute your own string as described above. NOTE: this was tested on a Nokia 6.1 running Android Pie 9.0.

    EDIT: Now when testing on Oreo 8.1 (for example), just removal of READ_CALL_LOG will not prevent retrieval of incoming call number (i.e. you could still get it if you want), however in the spirit of complying with Google directive, you should probably avoid querying it - and just assume it is null, and just use your own "incoming" or whatever as shown above.

    EDIT: When testing on Oreo 8.1 (for example), removal of PROCESS_OUTGOING_CALLS will mean that your query for outgoing call number will return null. In complying with the spirit of Google's directive, you should then probably not even bother querying the outgoing number, and just assume it is null - replacing it with "outgoing" or whatever you choose (as shown above).

    EDIT: It could be argued that since prior to Pie, you didn't need the READ_CALL_LOG permission, and the PROCESS_OUTGOING_CALLS permission resided in the PHONE permissions group, that an app which continues to behave as before, and is not targeting Pie, is complying, and could get access to both incoming and outgoing call numbers for labelling the call recording. However, it is advised that since this matter is up for debate, and as developers you will not get a forum to have a discussion with Google on this matter, it maybe best to avoid the debate altogether if you value the safety of your apps. With this fear in your mind, you will then make sure that BOTH the READ_CALL_LOG and PROCESS_OUTGOING_CALLS permissions are removed from your apps - EVEN if you are targeting Oreo (i.e. pre-Pie android versions). Taking this to extreme, you would also then perhaps make sure that you not even bother querying for these numbers, and just assume they are null, and substitute with "incoming" and "outgoing" (as shown above).

    Your app should now be compliant and ready for Google's Jan 9, 2019 deadline for removing Call/SMS permissions.

    Of course, the greater problem for the professional call recorder app developers will be to think about how to change their UI to reflect this very odd new behavior, where incoming calls are anonymous, but outgoing calls do have a phone number reference available.

    Of course, the greater problem for the professional call recorder app developers will be to think about how to change their UI to reflect this new behavior - where calls are anonymous, and can only be categorized into incoming and outgoing. One possibility they could explore is to think of "incoming" and "outgoing" as two contacts, and maybe just structure their UI to show these two 'contacts'.

     

    Alternatives for users

    Some users use call recorder apps because they cannot note down what is said in the recording - this can include blind users, as well as users who cannot write down while answering a call.

    For users who desperately need their call recorder app to continue working as it did on Pie before this change, they should download the APK for the app in it's current form - from either one of the reputable APK download sites, or just e-mail the developer and they will be happy to send you a previous version of the app as an APK file (which you can side-load onto your device).

    Future versions of those call recorder apps will start to exhibit this restricted behavior going forward.

    Inadvertently this is also raising the need for an alternate app store which can continue to provide apps which had the full features users were used to.

    However, this may not be the end of it - in the future, it is entirely possible that Google may start to flag apps or remove apps (for example if a user is using an earlier version of the app). If that happens, that will neuter any effort by a user to use an earlier version of the APK.

     

    ADDED: Anti-trust implications of Google restricting permissions for third-party apps, while allowing these for system apps from OnePlus, or Google apps which are self-permitted by Google for listing on Google Play

    Google has violated the implicit compact they have had with developers - that all older apps will run unchanged on newer versions of Pie - they changed this with Pie. This is documented here:

    This means a whole host of apps - many of which had millions of downloads, and were the mainstay for that app developer - are now broken. This is a classic "bait and switch" - when Google needed developers to populate it's Google Play store they allowed all this (witness the difficulty Windows Phone had without the app momentum with it's app store), and are now confident enough to harm developers at will.

    By restricting third party apps from access to certain permissions they are tilting the scales in favor of the system apps which come pre-built into devices, and apps that Google itself distributes.

    It also tilts the scales in favor of the "default dialer" and "default SMS" app - which essentially creates a moat around the dominant apps which are in a position to take over all the phone functionality, or all the SMS functionality of a device. A third party app which innovates on a portion of the features of a dialer app (does call recording, or does local backup of SMS, without needing to upload that info over the internet), cannot gain entry into that space with this new Google directive on Call/SMS.

    In addition, as a commenter has said, OnePlus' built-in call recorder gains an unfair advantage, because of the actions of Google, which restricts call recorder apps from competing fairly with OnePlus' system app offering.

    Google's own apps are self-granted permission to list on Google Play. This creates a situation where there will now be calls for Google to 'anti-trust separate' the policy driving Google Play store, from Google the company - so that the listing requirements are equally strict against Google and their system apps, as they are for third party apps.

    Either someone truly unaware is making these decisions at Google, or they are not looking out for the best interests of Google, or they are deliberately priming Google for anti-trust scrutiny, and provoking a move to break up Google from Google Play store.

     

    EDIT: On a whim, I just posted an e-mail to legal@google.com, providing them some reading material for this upcoming Call/SMS action. I have listed it below (NOTE: if you choose to write a similar e-mail, you will get an auto-reply informing you that "This email address is not monitored and your email will not be read, responded to, or otherwise acted on" - just ignore that, since this is the correct e-mail address for Google's legal department):

    To: legal@google.com

    Subject: Google upcoming deadline for Call/SMS restrictions on third party apps and it's anti-trust implications

    This is a heads up to the legal folks at Google, about an upcoming impact on the Google Play store which may have anti-trust implications for Google's control over the Google Play store.

    If anything, it provides a convenient place for all the reading related to this issue, and might be of interest to some.

    Google is about to break all call recording, and local SMS backup apps on the Google Play store - even though these apps have no interest in uploading this data elsewhere over the internet etc.

    In the absence of any privacy risk, these apps are broken under the guise of privacy - all this while Google does not even have an internet permission - these are granted implicitly for apps!

    Under the Google directive (deadline Jan 9, 2019), Call recorder apps are supposed to stop retrieving phone number related to phone calls - this means their user interfaces are broken - they can no longer show call logs for call recordings that show which contact that call recording was related to.

    Those apps which are labelled "default dialer" or "default SMS" can take over the whole phone - those gain advantage versus apps which seek to optimize a portion of those features.

    In addition system apps - for example OnePlus' built-in call recording feature - then have no competition from third party apps. Google is colluding in this removal of competition from Google Play.

    Google's own apps are self-granted permission by Google Play store - as system apps they do not face the same scrutiny. This is creating a non-level playing field for third-party apps.

    Someone at Google is either unaware of the anti-trust implications of these actions, or is deliberately thrusting Google into a fight where Google will be shorn of all influence over the Google Play store.

    As an app developer, I urge the legal minds to apprise the policy makers who are coordinating Android changes with Pie 9.0, and the policy changes for the Google Play store - to consider the negative implications these action will have in a future anti-trust scrutiny. They are creating all the ammunition that would be needed for a breakup of Google influence over the Google Play store.

    Thanks for your consideration.

    P.S. here is a comprehensive post I recently made on reddit.com (r/androiddev sub-reddit) which examines the hurdles facing developers to comply by the Jan 9, 2019 deadline - it includes a section there addressing the anti-trust implications of these ill-thought out actions.

    (link)

    Guidelines for Call Recorder apps for Google's Jan 9, 2019 deadline - and references to previous posts on Call/SMS fiasco

     

    EDIT: Corrected original post to reflect inclusion of PROCESS_OUTGOING_CALLS to the removal list

    EDIT: u/NLL-APPS has made an interesting comment below, that since Pie has structured a new 'CALL_LOG permissions group' in Pie, and moved PROCESS_OUTGOING_CALLS into this new group (and out of PHONE permissions group), that actually we need to remove both (I have changed the above text now to reflect this changed view):

    READ_CALL_LOG

    PROCESS_OUTGOING_CALLS

    Since 'CALL_LOG permissions group' as structured for Pie, includes:

    READ_CALL_LOG

    WRITE_CALL_LOG

    PROCESS_OUTGOING_CALLS

     

    Restricted access to call logs

    Android 9 introduces the CALL_LOG permission group and moves the READ_CALL_LOG, WRITE_CALL_LOG, and PROCESS_OUTGOING_CALLS permissions into this group. In previous versions of Android, these permissions were located in the PHONE permission group.

    Apps running on Android 9 cannot read phone numbers or phone state without first acquiring the READ_CALL_LOG permission, in addition to the other permissions that your app's use cases require.

     

    If PROCESS_OUTGOING_CALLS is removed, this means the outgoing call number will ALSO become anonymous (and when I stated about incoming call number being anonymous, will also apply to both incoming/outgoing then). This would mean that call recorder apps would not be able to categorize calls at all - they could only be clumped into generic 'incoming' and 'outgoing' groups.

    Here is more on PROCESS_OUTGOING_CALLS:

    PROCESS_OUTGOING_CALLS

    Allows an application to see the number being dialed during an outgoing call with the option to redirect the call to a different number or abort the call altogether.

    So the above comments would have to be changed to not only remove READ_CALL_LOG, but also PROCESS_OUTGOING_CALLS from AndroidManifest.xml, and the run-time permissions.

     

    Background reading:

    Google:

     

     

    XDA-Developers:

     

     

    My posts:

     

    Regarding how Pie for the first time is violating the implicit compact with developers - that older apps will work on newer android versions:

     

    Regarding Google's Call/SMS introduction of Call/SMS restrictions:

     

    Regarding the new discretionary layer Google is inserting specifically for Call/SMS features (while none exists for contact harvesting etc.), and the gaps in the privacy argument for the change:

     

    Regarding options available for developers to appeal Call/SMS - and the parties that might listen:

     

    Regarding absurdity of apps like call recorders (requiring fewer permissions) being rejected from using Task Automation exception:

     

    Posts by Tasker, Call Recorder and SMS Backup type app developers:

     

    By Tasker developer u/joaomgcd:

     

    By u/NLL-APPS - ACR Call Recorder developer

     

    By u/skyvalex SkyValex Call Recorder developer:

     

    By u/nikanorov:

     

    By u/anemomylos Easy Join (SMS backup app) developer:

     

    By u/ProperGearboxInsert:

     

    By u/peakyfblinders:

     

    By u/jderp7 Statistexts developer:

     

    By u/dattech:

     

    By u/RandomHandle31:

     

    By u/MobileSoftEU Callistics developer:

     

    By u/paulpv:

    submitted by /u/stereomatch
    [link] [comments]

    Outrageous thing I just found about people modding our apps

    Posted: 01 Jan 2019 10:17 AM PST

    (posted on mobile)

    Hello everyone. I hope everyone's getting a great year start!

    Now onto the problem...

    Recently on YouTube, I saw an Indian dude teaching how they can reverse engineering an app, then switching Admob ID TO THEIR OWN, then all the ads will profit them and not the developer. Is there any way to avoid this? I don't mind if someone removes the ads from my app and uses it, but now, switching the ID so they can profit off my app? Damn. Rants over, thanks for your attention.

    Btw I'm not posting the link to the video for obvious reasons.

    submitted by /u/DogsLayEggsFYI
    [link] [comments]

    Help bring Wikipedia to rural schools through an offline Wikipedia app

    Posted: 01 Jan 2019 11:07 AM PST

    Hi all

    I work at UNESCO and see a huge number of projects in schools that use Wikipedia, both online and offline. Only around 50% of the world has access to the internet, in many places internet can be slow, unreliable or even censored. Many schools in developing countries use textbooks that are many years even 10s of years old.

    Kiwix is an offline solution created by a not for profit that allows you to access educational content like Wikipedia, the Wiktionary, TED talks and many others on any computer or smartphone - without the need for a live internet connection.

    Currently the Kiwix app for Android and IOS allows people to view the content on their phone but to create a hotspot you need to use a Raspberry Pi or other hardware that is very cost prohibitive to the end users.

    I'm trying to find developers who can help add the ability to create a Wikipedia hotspot in the Kiwix app, which would allow people to use their existing phones to create a hotspot in their school or community. This would greatly reduce the money and skills needed to use offline Wikipedia and allow many more people to access it. Please do take a look at the GitHub issue if you're able to help.

    https://github.com/kiwix/kiwix-android/issues/259

    Thanks very much

    submitted by /u/JanCumin
    [link] [comments]

    Developing on a non Pixel or Nexus device

    Posted: 01 Jan 2019 11:06 AM PST

    What are some pitfalls or concerns when using a non-google device to do development work?

    Since I started developing for android back in the nexus 5 days I have always bought google's hardware offering because (A) it offers the cleanest development experience and stock android and (B) I just liked their offerings.

    The pixel 3 no longer appeal to me as much, and I am considering other manufacturers (maybe the galaxy s9?). Are there any warnings to be aware of for third party phones? Any brands to avoid? Any that come well recommended?

    In the past I have heard that Samsung's camera API is horrible to work with. Is this still the case? Have things improved at all in recent years?

    Thanks!

    ​

    submitted by /u/_polarbear
    [link] [comments]

    Moving the emulator programmatically

    Posted: 01 Jan 2019 01:58 AM PST

    What resources did you use to learn Android Development?

    Posted: 01 Jan 2019 10:50 AM PST

    Still get “SMS and CALL_LOG permissions warning”

    Posted: 01 Jan 2019 06:41 AM PST

    You've designed a great app and now asking yourself how to onboard your users? Then you should read this guide!

    Posted: 01 Jan 2019 07:49 AM PST

    How to handle activities that can be navigated to from multiple screens?

    Posted: 01 Jan 2019 12:19 PM PST

    I have an activity (calculation screen) that handles all calculations of the app. The way "calculation screen" knows what calculation to do is by getting an enum that is put as an extra from the intent of the menu.

    Problem is I can navigate to "calculation screen" from the "Replay session" button. But the replay session doesnt send an enum of what operation to do. What is the solution?

    Here is the user flow

    In general, how do you handle it when suddenly an activity that depended on intent details from another activity is accessed from somewhere else?

    submitted by /u/BigBootyBear
    [link] [comments]

    Freelance vs Own projects

    Posted: 01 Jan 2019 02:55 AM PST

    Asking here because you guys have specific knowledge about how much money do mobile apps make. Right now I am a mobile (both android and iOS) developer almost top-2 of my freelance platform. And I'm looking for the way to increase my income. I am deciding between making some progress in freelance further and starting my own projects. So what is more profitable in your opinion?

    submitted by /u/forshant
    [link] [comments]

    What is happening with playstore? Apps being blocked. Accounts being suspended. Seriously what is going on?

    Posted: 01 Jan 2019 01:27 AM PST

    Sharing Dagger 2 @Modules across multiple build targets in Android apps

    Posted: 01 Jan 2019 06:38 AM PST

    How do you guys deal with fake reviews?

    Posted: 01 Jan 2019 01:10 AM PST

    I keep getting 1* reviews that say something along the lines of "I haven't even played the game". It's so weird to me since it's quick to remove them via reporting but I keep getting them. Am I being trolled by someone or is this a common occurrence?

    submitted by /u/Game_BodgeTogetherer
    [link] [comments]

    How should I make methods that rely on activity and layouts accessible from anywhere?

    Posted: 01 Jan 2019 06:32 AM PST

    I have a helper class called "viewHelper()" which deals with view manipulation like adding, deleting, checking for parents etc. Since all these actions require a context and a layout I gave the viewHelper a constructor of this and ConstraintLayout.

    My problem is - what do I do when I want to manipulate views outside of the activity that initializes the helper? Example:

     public class CalculationScreen { ViewHelper viewHelper = new ViewHelper(this, constraintLayout); //Do I just pass them as constructors every time? seems sloppy and not DRY AnimateableImages = new AnimateableImages(this, constraintLayout); } public class AnimateableImages{ /*Constructors*/ //How do I make the context and layout accessible to every instance of viewhelper? ViewHelper viewhelper = new Viewhelper(this, constraintLayout) }

    ​

    submitted by /u/BigBootyBear
    [link] [comments]

    Google Analytics Causing Crashes on Android Pie Devices

    Posted: 31 Dec 2018 09:20 PM PST

    Hi Everyone,

    I noticed that there are a lot of crashes from Android Pie devices alone suddenly pops up in my Google Play Developer Console related Google Analytics like below one,

    Caused by: java.lang.IllegalStateException: at android.app.ContextImpl.getSharedPreferences (ContextImpl.java:419) at android.app.ContextImpl.getSharedPreferences (ContextImpl.java:404) at android.content.ContextWrapper.getSharedPreferences (ContextWrapper.java:174) at com.google.android.gms.internal.zzath.a (zzath.java:7) at com.google.android.gms.internal.zzari.initialize (zzari.java) at com.google.android.gms.internal.zzark.<init> (zzark.java:92) at com.google.android.gms.internal.zzark.a (zzark.java:29) at com.google.android.gms.analytics.GoogleAnalytics.enableAutoActivityReports (GoogleAnalytics.java) or .getInstance (GoogleAnalytics.java) or .initialize (GoogleAnalytics.java) or .newTracker (GoogleAnalytics.java) or .setDryRun (GoogleAnalytics.java) or .zza (GoogleAnalytics.java) or .zzk (GoogleAnalytics.java) at <OUR_APPLICATION_CLASS>.onCreate (TheAppLockApplication.java:44) at android.app.Instrumentation.callApplicationOnCreate (Instrumentation.java:1155) at android.app.ActivityThread.handleBindApplication (ActivityThread.java:5906) at android.app.ActivityThread.access$1100 (ActivityThread.java:200) at android.app.ActivityThread$H.handleMessage (ActivityThread.java:1660) at android.os.Handler.dispatchMessage (Handler.java:106) at android.os.Looper.loop (Looper.java:193) at android.app.ActivityThread.main (ActivityThread.java:6762) at java.lang.reflect.Method.invoke (Method.java) at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run (RuntimeInit.java:493) at com.android.internal.os.ZygoteInit.main (ZygoteInit.java:858)

    It is happening at the line where i request the GoogleAnalytics singleton instance at GoogleAnalytics.getInstance(this). When i was checking about this, I came across this thread in StackOverflow.

    So, If I add directBoot tag in the application class tag in Manifest file, will it fix the issue? Any other better solution for this? Since I don't have an Android Pie device with me, I can't verify this solution.

    submitted by /u/Balaji_Ram
    [link] [comments]

    Is this a good written privacy policy, from Google compliance point of view?

    Posted: 31 Dec 2018 04:00 PM PST

    We plan to roll out our own cloud storage, as a replacement for Google Drive app data folder. Since, I know Google takes privacy policy very seriously, it is better for me to make it clear in my privacy policy. Do you guys think this is a well written privacy policy, especially under "Cloud storage" section? - https://wenote.jstock.co/privacy-policy.html

    ​

    This is the cloud storage section

    ​

    Cloud Storage

    We provide an option to store all your notes in Google Drive app data folder.

    On December 6, 2018, Google announced that support for storing and syncing in the app data folder will likely be removed from Drive in the future - https://developers.google.com/drive/android/deprecation. In order to ensure you can continue access your cloud data after Google Drive app data folder is discontinued, we will store your notes in WeNote secure server (https://wenote-cloud-storage.jstock.co:2083/upload_file) as an alternative cloud storage. We have taken all steps reasonably necessary to ensure that your data and privacy are protected.

    ​

    • Using SSL for client and server communications.
    • Using Google Sign-In to perform authentication.
    • We do NOT store your email address.
    • Cloud service is provided by Digital Ocean, a renowned cloud infrastructure provider headquartered in New York City.

    ​

    Take note :-

    1. I purposely spell out the API URL, as I know Google is going to scan the app, on which URL we are going to send the data to. Hence, I think it is good to explicitly spell out the API URL.
    2. I purposely mentioned Digital Ocean as our cloud provider, to show I'm using a legit cloud provider. But, I also know that Google does have rule which doesn't allow us to mention other company brand name. So, I'm not sure whether there's a conflict right here.

    Do you think the above is a good written privacy policy, both for Google compliance, and for end users to understand it. Is there any way I can further improve it?

    ​

    Thanks.

    submitted by /u/yccheok
    [link] [comments]

    How to add pinch zoom to layout?

    Posted: 01 Jan 2019 12:37 AM PST

    I have tried some zooms but they don't allow scrolling after zoom . So, how can I add zoom to my layout like relativelayout which also allow scrolling after zoom and zooms at the point where you are pinching.

    submitted by /u/The_artist_999
    [link] [comments]
    Read more
    at

    No comments:

    Post a Comment

    Fashion

    Beauty

    Travel