{"id":516,"date":"2017-05-29T23:24:22","date_gmt":"2017-05-29T23:24:22","guid":{"rendered":"http:\/\/fluentreports.com\/blog\/?p=516"},"modified":"2017-06-23T23:53:48","modified_gmt":"2017-06-23T23:53:48","slug":"nativescript-android-3-0-application-upgrade-issue","status":"publish","type":"post","link":"http:\/\/fluentreports.com\/blog\/?p=516","title":{"rendered":"NativeScript: Android application upgrade issues"},"content":{"rendered":"

Updated Information:<\/strong> A RELATED ISSUE<\/strong> CAN<\/strong> also effect ALL<\/strong> normal android applications that are just a simple upgrade in that your newly upgraded app WON'T be upgraded properly on the device.\u00a0 The client running your app, will revert to the prior version and\/or prior data.<\/p>\n

This doesn't normally crash the app, like the original issue (discussed below)-- but your client will be wondering why your upgrade didn't change anything...\u00a0\u00a0 So my recommendation is to apply the application backup disabling fix listed below so you don't run into either of these issues.<\/p>\n

This new issue effects:<\/p>\n

    \n
  1. Android 6 and up devices.<\/li>\n
  2. Any<\/strong> application upgrade\/update.<\/li>\n
  3. Does not affect a brand new installs on a device that has never had your application. Will affect devices that deletes your app and later re-installs.\u00a0 So this is doesn't affect a new customer, but will effect any exist customers.<\/li>\n<\/ol>\n
    \n

    The issue described below has been patched in v3.01 of the Android Runtimes, technically it should be fixed.\u00a0 However as I suspected and we have confirmed recently; the root issue actually can cause other related issues, and it is unpatched and with no eta for its solution, hence this updated blog post with a work around...<\/p>\n

    \n

    For those who don't want to read the hows; the information you need is:<\/p>\n

      \n
    1. This is an Android only issue; iOS doesn't have this issues.<\/li>\n
    2. This is an Android 6.0 and higher issue.<\/li>\n
    3. Fresh new installs will not have this issue, only devices that have had a old version on it.<\/li>\n
    4. The main issue only occurs when you are upgrading from 2.x to 3.0 application.\u00a0 (See update info above, related issue is different) \u00a0\u00a0 So new apps that started as 3.0 won't have this issue; and apps that stay 2.x won't have issues.\u00a0 Only apps upgrading from 2.x to 3.x will have this issue on clients that are upgrading.<\/li>\n
    5. This is a conflict between a file (in 2.5) that was changed into a folder (in 3.0).<\/li>\n
    6. This is in the cases I've seen are caused by Google Auto-Backup auto restoring files\/settings on the application installation.<\/li>\n<\/ol>\n

      If your app is a upgrade from 2.x to 3.x and you are wanting to release it to the Amazon or Google play store; don't do it -- for you and your customers sanity.\u00a0 The app will crash on startup and you will be left scratching your head as to why it works (new customers) sometimes and why it doesn't (existing customers).<\/p>\n

      Progress is aware of the issue and how critical it is; so I would guess we should see a patch shortly (released in 3.01 ), however if you are under the gun and must release today; I have a fix that should also work, see end of blog post.\u00a0\u00a0 \ud83d\ude09<\/p>\n

      \n

      The longer story; Brad Martin pinged me late last week because he ran into this issue<\/a>. \u00a0 He is one of the awesome members of the nStudio <\/a>team, along with myself and Nathan Walker.\u00a0 So I stopped what I was doing and began to help him out.\u00a0\u00a0\u00a0 By the time we finished a couple hours of debugging (it was LATE Friday night) we had determined a number of things, but not the underlying issue.<\/p>\n

      We figured out that on what appeared to be a fully clean device it would still crash.<\/p>\n

      What we knew<\/h3>\n
        \n
      1. It didn't matter if it was Android @ release\u00a0 or Android @ next runtimes.\u00a0 (Wasn't runtime dependent.\u00a0 Included cleaning this multiple times)<\/li>\n
      2. We knew his tns-core-modules was 100% correct and it wasn't related to 3.00 or 3.01<\/li>\n
      3. We knew his his tns-core-modules & widgets matched 100% a clean version on another machine (no npm corruption)<\/li>\n
      4. We knew the .APK generated worked on all the emulators fine.<\/li>\n
      5. We were pretty sure LiveSync couldn't be causing the problem (we nuked it several times and installed via a couple different methods)<\/li>\n
      6. The platforms \/ src did NOT have that file in it, so no way the built APK could even get it.<\/li>\n<\/ol>\n

        Alexander Vakrilov<\/a> (from the NS team) noticed the call stack was pointing to the old 2.5 style.js file.\u00a0\u00a0\u00a0 I knew the 2.5 style.js file couldn't be coming from the freshly built apk and it wasn't in the LiveSync folder; so I actually thought that maybe there must be two different ways this error could appear, one of them would be someone upgrading and having the extra style.js in the node_modules\/tns-core-modules, the other would be what Brad was running into.<\/p>\n

        Then Brad confirmed today that the style.js file was present in his stack trace.\u00a0\u00a0 That actually confused me quite a bit, because with the data we had above, that didn't make any real sense.\u00a0 We had a fully clean APK without that file in it.\u00a0 How was the device getting it? \u00a0 \u00a0 We had manually deleted the livesync folder and even verified it was empty before we ran the app.\u00a0\u00a0\u00a0 But the app would still crash with that call stack.\u00a0\u00a0\u00a0 Color me confused...<\/p>\n

        So I took some time to scan the NativeScript android runtime source code for its livesync stuff.\u00a0 I had seen the code before, but I wanted to make sure nothing major changed in 3.0.\u00a0\u00a0\u00a0 I couldn't find anything other than what I expected to see.\u00a0 No \"other\" LiveSync folders, so I was still confused...<\/p>\n

        So how is the device getting this file on it???<\/strong><\/h3>\n

        So I thought for a few minutes; in my best Sherlock Holmes voice; \"When you have eliminated all which is impossible, then whatever remains, however improbable, must be the truth<\/b>\"<\/p>\n

          \n
        1. Appears to be primarily happening on Real Android devices.<\/li>\n
        2. Clear Data, works if done after the install.<\/li>\n
        3. Doesn't matter how the app is installed.<\/li>\n
        4. LiveSync doesn't appear to be responsible<\/li>\n
        5. The generated APK is 100% correct.<\/li>\n<\/ol>\n

          If finally hit me; some sort of external force is causing the issue.\u00a0\u00a0 I was so focused on NativeScript; I didn't think about the other items on a REAL DEVICE.\u00a0 It hit me like a 2x4... What is one thing that Real devices typically have over emulators???\u00a0\u00a0\u00a0 A Google account is normally setup and syncing...\u00a0\u00a0\u00a0 So I told Brad...<\/p>\n

            \n
          1. De-install app (again)<\/li>\n
          2. Nuke the LiveSync Folder (just to make sure)<\/li>\n
          3. Turn on Airplane Mode (What a trouper he is, didn't even ask me why!)<\/li>\n
          4. do a TNS run<\/li>\n<\/ol>\n

            App worked!\u00a0\u00a0\u00a0 I'm like AWESOME, Brad is like WTF!\u00a0\u00a0\u00a0\u00a0 I don't blame him, I didn't tell him what the test was for, and so he had no idea what I was testing for.\u00a0 And the poor guy has been not only doing my tests, but he had also put in a lot of time himself testing things... \u00a0 He just had the surprising fact that it actually worked on his phone when in Airplane mode.\u00a0 \u00a0 Me, I'm like I know what it is...<\/p>\n

            Android 6.0 Introduced a cool features called Auto-Backup<\/a>; this nice feature backs up your data and files from your app.\u00a0\u00a0 Well unfortunately for us NativeScript users; NativeScript stores its .JS files in the \/files\/app folder.\u00a0\u00a0 Guess what one of the folders that is AUTO BACKED UP?\u00a0\u00a0 \/files folder...<\/p>\n

            What is happening is there is a cool setting with your device, that will Automatically restore<\/strong> application settings when you re-install a application.<\/p>\n

            \"\"<\/a><\/p>\n

            When you install app; it detects the name is the same, it restores the \/files\/<\/code> folder (adding any MISSING files) which then puts the old 2.5 styles.js file into the folder.\u00a0\u00a0\u00a0 And then NativeScript attempts to load this file, and crashes...<\/p>\n

            \n

            My fix:<\/h1>\n
              \n
            1. Open your app\/App_Resources\/Android\/AndroidManifest.xml file change or set\/add the key allowBackup<\/code> in your <Application> tag to \"false\" and the tools:replace<\/code>.\u00a0 So it should look like:<\/li>\n<\/ol>\n

              &lt;application\n   android:name="com.tns.NativeScriptApplication"\n   android:icon="@drawable\/icon"\n   android:label="@string\/app_name"\n   android:theme="@style\/AppTheme"\n\n   android:allowBackup="false"\n   tools:replace="android:allowBackup"\n&gt;<\/pre>
              \nThen in the Manifest section you need to add the xmlns:tools<\/code> namespace entry:
              \n
              &lt;manifest xmlns:android="http:\/\/schemas.android.com\/apk\/res\/android"\n xmlns:tools="http:\/\/schemas.android.com\/tools"\n package="__PACKAGE__"\n android:versionCode="1"\n android:versionName="1.0"&gt;<\/pre>
              \nBy disabled the backup; you also disable the auto-restore of just this app's setting and files...\u00a0 (Thanks Brad for confirming this works!)<\/p>\n
               <\/p>\n","protected":false},"excerpt":{"rendered":"
              Updated Information: A RELATED ISSUE CAN also effect ALL normal android applications that are just a simple upgrade in that your newly upgraded app WON'T be upgraded properly on the device.\u00a0 The client running your app, will revert to the prior version and\/or prior data. This doesn't normally crash the app, like the original issue… Continue reading NativeScript: Android application upgrade issues<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,39],"tags":[16],"class_list":["post-516","post","type-post","status-publish","format-standard","hentry","category-nativescript","category-tips","tag-nativescript","entry"],"_links":{"self":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/516","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=516"}],"version-history":[{"count":7,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/516\/revisions"}],"predecessor-version":[{"id":535,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/516\/revisions\/535"}],"wp:attachment":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=516"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=516"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=516"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}