Since we use app internal storage and then a contentProvider, I don't think we need permission for external storage. It's up to the external content provider (e.g. files, drive etc) to have access to the appropriate storage.
Refactor the native interface in preparation for switching iOS to use WKWebview.
* Finally rename the folder for device specific interfaces as `tablet` instead of `iPad`
* Update `import` statements to use the new name
* Create new `iOS.js` and `Android.js` based on previous `iPad/iOS.js` to separate the interfaces
* Add new `OS.js` class to manage the class variables, initialize the device interface delegate methods to the correct interface.
* refactor how `utils/lib` detects the current platform based on `navigtor.userAgent` based on https://stackoverflow.com/questions/37591279/detect-if-user-is-using-webview-for-android-ios-or-a-regular-browser. previous method relied on the Android interface being loaded or not. It can be difficult to detect the difference between in a browser and in a webview, but for now ScratchJr doesn’t need to worry about running in a browser
Trying to use the extension pattern this way gets an error when uploading the APK to Google Play, so just hard code the extension patters. This won’t work for PBS kids version.
Don’t export as email message. and be less strict about import requirements.
Android intent filters are really only designed to work with standard mimetypes (like ‘image/png’). Even if you can share something with a custom mime type, it’s likely to get lost somewhere along the way, from email, or Gdrive, or Files app etc.
Path matching patterns in intent filter only apply to `file` schemes, `content` scheme is likely to be some generated id in temp storage. `content` filters maintly go by mimetype, but as noted above, a custom mimetype has often gone AWOL. Generic application files are usually downloaded as `application/octet-stream`. Basically we have to trust the user not to try to load some other random file into ScratchJr. The import function will fail and give an error message if they do.
Finally, fix the way we’re sharing ScratchJr files. While the button says ‘Share by Email’ for a long time Android has shown a selection of ways to share the file. However, we were setting the mime type as an email message so the saved file would always try to open in an email client instead of ScratchJr.
This PR was 95% of the way there, and I didn’t want to ask for changes after not getting to review it for so long, so I just made the changes.
Thanks for submitting!
On some newer android devices the screen tranform matrix already includes the current scale. i.e. the matrix looks like:
```
{
a: scaleX,
b: 0,
c: 0,
d: scaleY,
e: offsetX,
f: offsetY
}
```
where both `scaleX`, and `scaleY` are the current zoom. On other devices the scale is always `1`, and we need to apply our own scaling.
I also added the code to automatically allow webview debgging if the buildType is debuggable. Also, note that you can switch which line is commented out in bundle-compile.sh to get unobfuscated javascript.
The iOS change seems to have a side effect on Android of adding an“Edge Effect” to the web view whenever dragging a block. (Edge effects are the grey curved shadow that appears at the top or bottom of a container when you overscroll. When you drag a block they appear at the top or bottom of the screen)
Adding the `android:overScrollMode=“never”` attribute to the webview means the edge effect doesn’t appear.
* Remove ScratchJrApplication class - it was only being used to initialize the old Google Analytics.
* Change AppUsage (home, school, other, noanswer) from being a prefix on `label` to being a Firebase user property.
* Set the user property when loading the index page - it shouldn’t change for the rest of the session.
PBS Kids has automated testing that looks for uses-sdk with a minimum targetSDK of 23. Even though this gets overridden in the build.gradle settings, adding a line with default values to get through their testing.
Changed android:requiresSmallestWidthDp from 600 to 500.
Android suggests that 600 is a normal value for 7 inch tablets and up. It turns out that many 7-inch tablets are in the 500-600 range (half of the Amazon ones for example).
Fixes#85
