Android 6.0 Marshmallow (API 23)

[Emux]

I have advanced dev branch onto Android 6.0 Marshmallow (API 23).

Though I kept target API level to 22, as we need to examine first the new permissions model requests in the code.

http://developer.android.com/preview/features/runtime-permissions.html
Only apps designed to work with the Android M SDK (API level 23) will use the new permission system. App developers can stick to the old system, as long as they target API level 22 (Android 5.1) or earlier.

--
Emux

[Ludwig]

I wonder if we should have for the moment a separate branch that targets API level 23. 

There might be many applications that do not want to make the move to the new permission system even if mapsforge supports it.

Ludwig

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/55DC05A3.2040500%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Emux]

From what I have understood, simply setting as target (in Gradle or manifest) the API 22 is enough for not having to deal with the new permissions model.
And for compilation we can still use API 23 for any other new features.
That's how dev was recently advanced (compile with 23 - keep target 22).

Considering that we have already dev for (unstable) development and that master continues with API 22, I'm hesitant to have another branch in our head to manage and merge.

I'd let things as is, at least until Android M starts arriving at Nexus devices and see again the situation.

--
Emux

[Emux]

On 26/08/2015 02:12 πμ, Ludwig wrote:

There might be many applications that do not want to make the move to the new permission system even if mapsforge supports it.

Maybe I'm missing something here, but why the connection of the API level we build Mapsforge and the API level that developers use in their applications?
(Note that we don't use any M features in Mapsforge code)

--
Emux

[Emux]

http://android-developers.blogspot.com/2015/08/building-better-apps-with-runtime.html

--
Emux

[Ludwig]

I have to better understand how the new runtime permissions will work within apps. 

I think we might have two scenarios:

1. an app using mapsforge that targets the old system. Nothing would need to change. 
2. an app using mapsforge targeting 23, i.e. with new runtime permissions. That app would expect that mapsforge also plays nicely with the new runtime permissions.

I agree that multiple branches are undesirable, but I think we will need two code branches depending on what level an app will target. That should maybe not be two git branches, but conditional execution within the code.

Ludwig

On 28 August 2015 at 01:30, Emux <deve...@gmail.com> wrote:

http://android-developers.blogspot.com/2015/08/building-better-apps-with-runtime.html

--
Emux

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/55DF4926.4030806%40gmail.com.

[Emux]

On 28/08/2015 01:18 μμ, Ludwig wrote:

I have to better understand how the new runtime permissions will work within apps.

+1

I agree that multiple branches are undesirable, but I think we will need two code branches depending on what level an app will target. That should maybe not be two git branches, but conditional execution within the code.

Precisely my thoughts Ludwig.
We should handle the new permissions system inside existing structure, thus avoiding branching (just imagine if with every new feature we branch and have to maintain the code).

BTW considering that Mapsforge is a library, I think the weight of permissions handling is still more on the app level (i.e. Samples) than the library itself.

--
Emux

[M. Dietrich]

Am Mittwoch, 26. August 2015 08:18:18 UTC+2 schrieb Emux:

Maybe I'm missing something here, but why the connection of the API level we build Mapsforge and the API level that developers use in their applications?

(Note that we don't use any M features in Mapsforge code)

that was my first thought as well. isn't the permission stuff the duty of the app developer?

[Emux]

On 18/09/2015 11:58 μμ, M. Dietrich wrote:

that was my first thought as well. isn't the permission stuff the duty of the app developer?

AFAIK essentially yes.

--
Emux

[Ludwig]

I think the only thing where Android M comes in for mapsforge is cache reading/writing. This should be somehow modified as to allow an application developer to hook his own permission policy in there.

E.g. if permission is revoke make an upcall into application code, so application can then decide what to do (e.g. disable cache, put warning message out etc)

Ludwig

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/55FC7B8B.2080304%40gmail.com.

[Emux]

The internet permission should be required also for online tile sources (if user wants to play with them), but strangely it's under normal group and will granted automatically at install time.

And now that we moved MyLocationOverlay at Samples app, the library is more clean of additional requirements.

--
Emux

[Ludwig]

I think the reason that internet access is in the normal group (that cannot be banned) is that so many things are ad based that Google just does not want to block them. I would love to block lots of apps that IMHO do not need access to internet. 

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/55FD1C7C.6090301%40gmail.com.

[Ludwig]

Just a very quick test of our Samples app with Google's (now much faster) Android emulator and Android 6.0:

Android 6.0 allows to withdraw the Location and the Storage permission, with the following effects:

1. Location: LocationOverlayMapViewer continues to function but without location marker. After permission is returned, location marker reappears. This seems sensible behaviour and as this is userland/Samples code it is not strictly required to provide additional code.
2. Storage: storage in the Samples case also prevents reading the map file, so the Samples app crashes. For map files stored in app storage or downloaded from internet, this does not apply (tested). The DownloadMapViewer continues to work, as it cannot write to cache it simply stops writing to cache. There is no error or warning message generated.

So we will need to insert some additional code in the main library for the following situations:

1. Reading map file from storage.
2. Writing/reading cache.

Ludwig  

[Andreas Schildbach]

On Saturday, September 26, 2015 at 10:59:15 AM UTC+2, Ludwig wrote:

So we will need to insert some additional code in the main library for the following situations:

1. Reading map file from storage.
2. Writing/reading cache.
   

I think the cache is best placed in one of the app-owned directories, e.g. app external storage. Those directories can be accessed without permission.

[Emux]

Thanks for looking into this Ludwig.

Location: LocationOverlayMapViewer continues to function but without location marker. After permission is returned, location marker reappears. This seems sensible behaviour and as this is userland/Samples code it is not strictly required to provide additional code.

Indeed sensible behavior, like when we on/off the GPS in current Android.

Storage: storage in the Samples case also prevents reading the map file, so the Samples app crashes. For map files stored in app storage or downloaded from internet, this does not apply (tested). The DownloadMapViewer continues to work, as it cannot write to cache it simply stops writing to cache. There is no error or warning message generated.

So we will need to insert some additional code in the main library for the following situations:

1. Reading map file from storage.
2. Writing/reading cache.

+1

--
Emux

[Emux]

On 26/09/2015 12:04 μμ, Andreas Schildbach wrote:

I think the cache is best placed in one of the app-owned directories, e.g. app external storage. Those directories can be accessed without permission.

Right now we use Context.getExternalCacheDir for cache location.

--
Emux

[Andreas Schildbach]

Yeah, that's correct. Then we don't need additional permission-related code for the cache. Just make sure WRITE_EXTERNAL_STORAGE and READ_EXTERNAL_STORAGE keep being requested (via AndroidManifest.xml) for pre-KitKat devices.

[Ludwig]

Just checking, but like getExternalFilesDir() externalCacheDir() does not require permissions from KitKat onwards: https://developer.android.com/reference/android/content/Context.html#getExternalCacheDir()

--

You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/20b13a30-38c8-46f2-a8db-7194ca0082b8%40googlegroups.com.

[Ludwig]

Just tested current code (with a map file that is in application storage, not external storage) and permissions set for external storage set to 

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="18" />

and that works with no permission for storage shown that can be revoked.

Compiling with target-sdk 23, the effect is that permissions are not granted automatically at installation time, so an app will apparently crash that does not include the code to ask the user to grant permission. 

[Emux]

Ludwig maybe I'm missing something on your description, but:

- When you say  "map file that is in application storage, not external storage", what's that application storage path and by external storage do you mean the sd card ?

- Why the crash if it's supposed to not require permission in the first place.

--
Emux

[Ludwig]

Apologies for the total confusion here, testing too many permutations.

I installed the map into private app storage (in /data/ not /sdcard/, so no read permission is needed for map data.

1) No storage permission asked for. This works as cache is silently disabled in apps below 19 and cache is used without permission from 19 on.

2) With <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="18" /> cache works in all versions. In Android 6, no permission that can be revoked is shown. 

The second comment was a more general one on how I now understand the runtime permissions work in Android 6 (when compiled with target 23): then the permissions are not automatically granted even if they are declared. This affects the Samples app with access to the location provider. 

At application start-up they are all disabled, so apps will crash with security exceptions. I had assumed the problem start when a user decides to revoke permissions. In fact, code needs to be included to ask for permission first. 

Not sure if that is any clearer.

Ludwig

[Emux]

Thanks for clarifying it.

On 26/09/2015 01:53 μμ, Ludwig wrote:

I installed the map into private app storage (in /data/ not /sdcard/, so no read permission is needed for map data.

IIRC I had read a Google recommendation against getFilesDir for large size data (use getExternalFilesDir instead), but may be wrong..

1) No storage permission asked for. This works as cache is silently disabled in apps below 19 and cache is used without permission from 19 on.

With cache in getExternalCacheDir, right?

2) With <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="18" /> cache works in all versions. In Android 6, no permission that can be revoked is shown.

That's good.

The second comment was a more general one on how I now understand the runtime permissions work in Android 6 (when compiled with target 23): then the permissions are not automatically granted even if they are declared.

So if we set targetSdkVersion 22, we indeed have old behavior in Android 6 ?

--
Emux

[Ludwig]

With target-sdk=22 we get the old behaviour (permissions that have been declared are enabled, e.g. location), but user can revoke. 

The effect if a user revokes the permission is that no location updates are received, but the app does not crash. With target-sdk=23 the app crashes with a security exception if the code is not changed. 

The storage is revocable unless it the permission request is done like this: <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="18" /> 

but the effect is that our cache is silently disabled. 

So my apps seem to work on Android 6 without change. But if I move to target-sdk=23 I will have to make changes. 

Ludwig 

So if we set target 22, we indeed have old behavior in Android 6 ?

At the end you make me to start searching also the permissions behavior, we cannot postpone it for ever.. :)

--
Emux

--
You received this message because you are subscribed to the Google Groups "mapsforge-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mapsforge-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mapsforge-dev/56068077.8030401%40gmail.com.

[Emux]

Ok, thanks for taking the time to check all these.

--
Emux

[Emux]

After making also tests with Android 6, I have the same results as Ludwig.

It's important to keep targetSdkVersion=22 if you don't want to make permission code changes.

Mapsforge thankfully (nice work!) continues (in memory) operation if storage permission is revoked.

--
Emux

[Glensimar Garcia]

Hi Guys!

I apply here your advice about keep target version in 22, but i have to make changes because many of our users have updated the android version.

I'm using mapsforge 5.1.

So i need some hint here to continue: 

Do i make changes on manifest?

or update de mapsforge version? I run the samples and crashes on my MotoG2 device with Android 6.0

Thanks!

[Emux]

It's not mandatory to have target sdk to >22 if you don't want to, the app will work in Android 6.

But if you want it's recommended, you just need to follow Android guides for requesting properly your app's permissions.

We have an optional module "mapsforge-map-android-extras" which supports the runtime permissions introduced in Android 6.
You can check the latest Samples app how it's used.

Also in MF downloads we offer two Samples flavors, with old permissions model and with the new one to test.

--
Emux

[Glensimar Garcia]

Thanks for the answer Emux!

i have to set a maxSdkVersion at 22 because in android 6.0 when i try to move the map, app crash..

The same happened to me when i test 

Samples-runtimepermissions-debug.apk

so.. i have the problem now that user with 6.0 can download my app.

I will follow android guides like you said..

[Emux]

On 11/03/2016 03:20 μμ, Glensimar Garcia wrote:

The same happened to me when i test 

Samples-runtimepermissions-debug.apk

You mean you tested Samples "runtimepermissions" on Android 6 and it crashed?
We need to check that (if you can provide a log).

--
Emux

[Glensimar Garcia]

Yes! Where i find the log.

Sample app  create a directory ?

[Emux]

I mean the stack trace on your IDE logcat (if there are any exceptions).

--
Emux

[Emux]

FYI
I rechecked Samples (runtime permissions) 0.6 from downloads on a Android 6 device and seems working as expected.

--
Emux

[Glensimar Garcia]

Attach log.

Let me know if it helps..

[Emux]

Seems like another Skia crash on a Motorola device with Android 6 (see issue 789).
Is it the Moto G (2nd gen) LTE version?

Also which exactly Samples have you tried?
Because dev edition has HA enabled, which we don't recommend.

--
Emux

[Glensimar Garcia]

We have Moto G XT1068 

We tried this one:

http://ci.mapsforge.org/job/0.6.0/lastSuccessfulBuild/artifact/Applications/Android/Samples/build/outputs/apk/Samples-runtimepermissions-debug.apk

And without runtime permissions also crash..

[Emux]

On 11/03/2016 09:11 μμ, Glensimar Garcia wrote:

We have Moto G XT1068

Yes that's Motorola Moto G (2nd gen).

And without runtime permissions also crash..

This crash also seems related to Skia graphics engine and the particular device.

--
Emux

[Emux]

There is an older topic about crashes on Motorola (with Android 5).

https://groups.google.com/forum/#!topic/mapsforge-dev/wqRgHpdicas

--
Emux

[Glensimar Garcia]

We have no crashes until update to android 6.0 

Thanks Emux!

[Glensimar Garcia]

Acording with issue 789

El viernes, 11 de marzo de 2016, 15:27:12 (UTC-4:30), Glensimar Garcia escribió:

BTW We have no crashes until update to android 6.0