Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.mobile.android > #36869 > unrolled thread

Android 6

Back to article view | Back to comp.mobile.android

Contents

  Android 6 Bill <Billaboard@gmail.com> - 2016-12-22 17:21 +0000
    Re: Android 6 The Real Bev <bashley101@gmail.com> - 2016-12-22 10:00 -0800
      Re: Android 6 Bill <Billaboard@gmail.com> - 2016-12-23 00:23 +0000
        Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-22 19:30 -0500
          Re: Android 6 Bill <Billaboard@gmail.com> - 2016-12-23 12:42 +0000
            Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2016-12-23 11:58 -0500
              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 13:43 +0100
                Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-30 15:34 +0000
                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-30 22:33 +0100
                    Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-31 13:27 +0000
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 08:59 +0100
                        Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-04 13:40 +0000
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 09:00 +0100
                            Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-15 18:23 +0000
                              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-15 21:20 +0100
                        Re: Android 6 AL <45364747@invalid.com> - 2017-01-04 10:06 -0700
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 09:00 +0100
                        Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-05 01:34 -0500
                          Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-07 14:14 +0000
                            Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-07 13:09 -0500
                              Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-08 18:18 +0000
                                Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-08 15:42 -0500
                                  Re: Android 6 The Real Bev <bashley101@gmail.com> - 2017-01-08 17:11 -0800
                                    Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-08 20:19 -0500
                                  Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-09 23:55 +0000
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 18:07 +0100
                                Re: Android 6 Frank Slootweg <this@ddress.is.invalid> - 2017-01-08 21:34 +0000
                                  Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-09 23:55 +0000
            Re: Android 6 Joerg Lorenz <hugybear@gmx.ch> - 2016-12-24 10:49 +0100
    Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-22 23:55 +0100
      Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-22 19:15 -0500
        Re: Android 6 Joerg Lorenz <hugybear@gmx.ch> - 2016-12-23 05:46 +0100
          Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-23 00:15 -0500
        Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-23 17:11 +0000
          Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-23 12:43 -0500
            Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-23 21:22 +0000
              Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-24 14:29 -0500
                Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-25 11:10 +0000
                  Re: Android 6 Piet <www.godfatherof.nl/@opt-in.invalid> - 2016-12-25 12:37 +0100
                  Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-25 11:18 -0500
                    Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-25 20:28 +0000
            Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-29 12:02 -0500
              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 23:45 +0100
                Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-29 18:02 -0500
                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-30 22:24 +0100
                    Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-31 11:55 -0500
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:04 +0100
                        Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-04 10:14 -0500
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 18:11 +0100
                            Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-11 13:05 -0500
                              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-13 17:23 +0100
                                Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-16 15:35 -0500
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-17 05:39 +0100
                Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-30 15:34 +0000
                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-30 22:26 +0100
                    Re: Android 6 Daniel James <daniel@me.invalid> - 2016-12-31 13:27 +0000
                      Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-31 11:55 -0500
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:11 +0100
                        Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-04 13:40 +0000
                        Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-04 10:14 -0500
                          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-11 18:12 +0100
                            Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-11 13:05 -0500
                              Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-13 17:24 +0100
                                Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-15 18:23 +0000
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-15 21:30 +0100
                                    Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-16 15:42 +0000
                                Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-16 15:35 -0500
                                  Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-17 05:44 +0100
                                  Re: Android 6 Daniel James <daniel@me.invalid> - 2017-01-17 17:47 +0000
                  Re: Android 6 Bill <Billaboard@gmail.com> - 2017-01-01 01:05 +0000
                    Re: Android 6 tlvp <mPiOsUcB.EtLlLvEp@att.net> - 2017-01-02 02:08 -0500
                      Re: Android 6 David Taylor <david-taylor@blueyonder.co.uk.invalid> - 2017-01-02 08:01 +0000
                      Re: Android 6 nospam <nospam@nospam.invalid> - 2017-01-02 08:51 -0500
                      Re: Android 6 Bill <Billaboard@gmail.com> - 2017-01-02 20:41 +0000
                      Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:18 +0100
                    Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2017-01-04 09:14 +0100
            Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 14:05 +0100
        Re: Android 6 nospam <nospam@nospam.invalid> - 2016-12-29 12:02 -0500
          Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 23:46 +0100
            Re: Android 6 Dave Higton <dave@davehigton.me.uk> - 2016-12-31 20:18 +0000
        Re: Android 6 Arno Welzel <usenet@arnowelzel.de> - 2016-12-29 13:47 +0100

Page 1 of 5  [1] 2 3 4 5  Next page →

#36869 — Android 6

OK, I've temporarily abandoned all hope with my Timmy phone where the 
screen touch alignment is wrong, plus, like the Queen of England, I have 
a most terrible cold, so I'm extremely low-powered.

So, I got a cheapo Android 6 phone by "THL" at what I thought was a very 
keen price, but while it was in the post, saw an offer I couldn't refuse 
on a Medion Android 6 phone in a local supermarket. So, now there are 
two.

Both, of course, immediately asked if I want to use the SD card for 
storage or for internal memory. Googling brought up loads of 
contradictions, and scares about internal, so both phones are using the 
cards as storage for photo and video. Is there a definitive, clear guide 
to this decision anywhere?

The old Timmy was used mainly for vehicle diagnostics and similar and, 
for example, Torque would record trip data onto its SD card. I haven't 
yet found a way to do this in either Android 6 phone. Also, an app to 
move apps to the sd card says the card has to be formatted as internal 
memory, which Google seems to say makes the existing internal memory 
redundant (and bypassed?).

Both phones seem good and touch alignment is fine. The Medion is a bit 
weird in that the app icon screens go vertically and the back button is 
on the wrong side, but it seems to have come with a good "where am I?" 
app and Teamviewer to some get you going operation. It doesn't, however, 
have the developer options in "Settings" that I need.

I wonder if these can be installed?
-- 
Bill

[toc] | [next] | [standalone]

#36870

On 12/22/2016 09:21 AM, Bill wrote:
> OK, I've temporarily abandoned all hope with my Timmy phone where the
> screen touch alignment is wrong, plus, like the Queen of England, I have
> a most terrible cold, so I'm extremely low-powered.
>
> So, I got a cheapo Android 6 phone by "THL" at what I thought was a very
> keen price, but while it was in the post, saw an offer I couldn't refuse
> on a Medion Android 6 phone in a local supermarket. So, now there are
> two.
>
> Both, of course, immediately asked if I want to use the SD card for
> storage or for internal memory. Googling brought up loads of
> contradictions, and scares about internal, so both phones are using the
> cards as storage for photo and video. Is there a definitive, clear guide
> to this decision anywhere?

Probably not, but I chose to use the external card as an extension to 
the internal memory.  I'll never want to take it out to use for any 
other purpose (cards are cheap now) and I copy stuff to my computer via 
wifi/ftp.  I use clickfree (available only through 1 Mobile Market, not 
google play) to back whatever it regards as the whole thing up to 
dropbox and hope for the best.

> The old Timmy was used mainly for vehicle diagnostics and similar and,
> for example, Torque would record trip data onto its SD card. I haven't
> yet found a way to do this in either Android 6 phone. Also, an app to
> move apps to the sd card says the card has to be formatted as internal
> memory, which Google seems to say makes the existing internal memory
> redundant (and bypassed?).

No, it's still internal memory -- there's just a more direct connection 
to the external card.  I guess.  I got tired of the "not enough room" 
messages from google play with my previous phone, so chose to extend the 
internal memory.  Stupid people who insist on not allowing you to choose 
where to install stuff.

> Both phones seem good and touch alignment is fine. The Medion is a bit
> weird in that the app icon screens go vertically and the back button is
> on the wrong side, but it seems to have come with a good "where am I?"
> app and Teamviewer to some get you going operation. It doesn't, however,
> have the developer options in "Settings" that I need.
>
> I wonder if these can be installed?

You can get the developer options opened by doing something weird (tap 
something 9 times or something similar), at least on the two phones I've 
done it with.  Google will probably find instructions.


-- 
Cheers, Bev
    "The last thing you want is for somebody to commit suicide
     before executing them."
            -Gary Deland, former Utah director for corrections

[toc] | [prev] | [next] | [standalone]

#36879

In message <o3h497$eca$1@dont-email.me>, The Real Bev 
<bashley101@gmail.com> writes
>Probably not, but I chose to use the external card as an extension to 
>the internal memory.  I'll never want to take it out to use for any 
>other purpose (cards are cheap now) and I copy stuff to my computer via 
>wifi/ftp.  I use clickfree (available only through 1 Mobile Market, not 
>google play) to back whatever it regards as the whole thing up to 
>dropbox and hope for the best.

That seems very sensible, but I'm not sure it meets my needs (and 
prejudices).
I have a dashcam that has wifi, but at the moment only has software that 
works with android and ios. The sd card in the camera can be put into a 
PC and the files (video, gps,etc) transferred as they are straight mp4 
files. If I have understood it right, in an emergency, the dashcam will 
record a short clip to the phone either via a deceleration trigger or a 
button push. This clip and a jpg will thus be on the phone.
This worked on my old 4.4 phone, where I believe I'd got the clips etc 
on the SD card. Admittedly, I downloaded without taking the card out of 
the phone
If the sd card on the phone is encrypted and the phone crashes to the 
floor, I'm not sure anything could be recovered.

I think I've convinced myself that I want to keep the card unencrypted 
for data, ie mobile storage, but I'm having trouble in getting the data 
from apps to store on the sd card rather than the existing memory.

I may be wrong in all of this and if so plead illness. The camera 
records in fairly high definition, so uses 128G cards itself, and the 
small emergency clips are fairly large. Files on the old phone could 
easily reach many gigs. A trip halfway along the North Wales coast using 
the old phone into Torque recorder was 970megs.

As an aside, I do have a prejudice about SD cards and encryption as many 
years ago I imported a pioneering Aiwa portable mp3 audio recorder, and 
was horrified to discover that it used the secure feature in the then 
new Secure Data cards that meant the files could not be played back 
anywhere else. This locked the audio to the specific machine.  It made 
it completely useless for field recording and it's only recently that 
I've been forced into ever considering anything else that used SD cards.

Thanks for the useful reply.
-- 
Bill

[toc] | [prev] | [next] | [standalone]

#36880

In article <GF5$UjdX6GXYFwDO@end.of.the.universe>, Bill
<Billaboard@gmail.com> wrote:

> As an aside, I do have a prejudice about SD cards and encryption as many 
> years ago I imported a pioneering Aiwa portable mp3 audio recorder, and 
> was horrified to discover that it used the secure feature in the then 
> new Secure Data cards that meant the files could not be played back 
> anywhere else. This locked the audio to the specific machine.  It made 
> it completely useless for field recording and it's only recently that 
> I've been forced into ever considering anything else that used SD cards.

that is entirely the doing of the aiwa device. other products don't do
that.

[toc] | [prev] | [next] | [standalone]

#36895

In message <221220161930042824%nospam@nospam.invalid>, nospam 
<nospam@nospam.invalid> writes
>In article <GF5$UjdX6GXYFwDO@end.of.the.universe>, Bill
><Billaboard@gmail.com> wrote:
>
>> As an aside, I do have a prejudice about SD cards and encryption as many
>> years ago I imported a pioneering Aiwa portable mp3 audio recorder, and
>> was horrified to discover that it used the secure feature in the then
>> new Secure Data cards that meant the files could not be played back
>> anywhere else. This locked the audio to the specific machine.  It made
>> it completely useless for field recording and it's only recently that
>> I've been forced into ever considering anything else that used SD cards.
>
>that is entirely the doing of the aiwa device. other products don't do
>that.

Not now they don't, but the original push and concept behind SD cards 
was that they were DRM friendly and so were able to restrict user's 
access and options. At the time the other concept was that we all would 
have to pay Fraunhofer for a licence every time we encoded anything to 
mp3. I was there and actually tried to purchase a bunch of mp3 licences, 
but communication with the, I assumed, German or Swiss professor at 
Fraunhofer Institute in the office on his own, didn't go well.

Common sense and the public seem to have won with SD and, to an extent, 
mp3.

I just gave this as background about why I don't want some third party 
or machine encrypting my original data. I want to be the one who 
controls the data and access if I own (ie recorded ) it.

The question still remains - is it an "Android policy" that data 
generated by apps on the machine cannot be stored on an unencrypted sd 
card or is it just that I haven't found how to do it on Android 6?
-- 
Bill

[toc] | [prev] | [next] | [standalone]

#36896

On Fri, 23 Dec 2016 12:42:05 +0000, Bill wrote:

> ... question still remains - is it an "Android policy" that data 
> generated by apps on the machine cannot be stored on an unencrypted sd 
> card or is it just that I haven't found how to do it on Android 6?

Can't be "Android policy" flat-out, because the camera app on a Motorola
Droid of mine is perfectly happy to put the jpeg files it captures into a
folder (explicitly: /dcim/Camera/ )on the external microSDHC card I have
installed in the microSD slot on that handset.

(Among the Settings then available, once the Camera app is open, there is
Storage Location, which offers both Internal Phone Storage and SD Card.)

OTOH, there's NO guarantee that *every* app on *every* Android device will
surely *always* offer the same storage alternatives. 

HTH. Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#37025

tlvp wrote:

> On Fri, 23 Dec 2016 12:42:05 +0000, Bill wrote:
> 
>> ... question still remains - is it an "Android policy" that data 
>> generated by apps on the machine cannot be stored on an unencrypted sd 
>> card or is it just that I haven't found how to do it on Android 6?
> 
> Can't be "Android policy" flat-out, because the camera app on a Motorola
> Droid of mine is perfectly happy to put the jpeg files it captures into a
> folder (explicitly: /dcim/Camera/ )on the external microSDHC card I have
> installed in the microSD slot on that handset.

Pictures taken by a camera app are not the same as *private* data of an
app which is usually stored in SQlite databases (like the contacts
database).



-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37057

In article <449f715e-6c60-7051-98a5-bed4624d9a68@arnowelzel.de>, Arno 
Welzel wrote:
> Pictures taken by a camera app are not the same as *private* data
> of an app which is usually stored in SQlite databases (like the
> contacts database).

That's largely true ... but it is up to the programmer to decide what 
data an app uses should be "private" and what should be generally 
accessible. Even then, Android doesn't make the creation of generally 
accessible data areas easy -- the camera app is a special case.

There's nothing special about SQLite databases. They're just files.

The issue is whether the programmer has chosen to make the app write 
data to the SD card, and whether the app has the necessary permission to 
do so.

Android apps are not supposed to write to any area of external storage 
apart from their own app directory. Before Android 4.4 "KitKat" that 
rule was not enforced. In KitKat it was enforced for the first time, 
which caused a lot of annoyance as many developers had not understood 
the requirements correctly, or had assumed that the rule would never be 
enforced. In Lollipop a new permission was added whereby an app could 
request permission to write outside its own directory (essential for 
file managers, and the like).

In Marshmallow Google have changed the rules by making the user choose 
whether SD cards should be "internal" or "portable" storage. The old 
rules apply to "portable" storage, but (I think, I'm still learning 
about this) Android will no longer automatically move apps and their 
data to the card in that mode.

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37061

Daniel James wrote:

> In article <449f715e-6c60-7051-98a5-bed4624d9a68@arnowelzel.de>, Arno 
> Welzel wrote:
>> Pictures taken by a camera app are not the same as *private* data
>> of an app which is usually stored in SQlite databases (like the
>> contacts database).
> 
> That's largely true ... but it is up to the programmer to decide what 
> data an app uses should be "private" and what should be generally 
> accessible. Even then, Android doesn't make the creation of generally 
> accessible data areas easy -- the camera app is a special case.
> 
> There's nothing special about SQLite databases. They're just files.

I know.

I mentioned "database" to make it clear that there is a difference in
"take a picture to be stored as a file" or "manage the data of an app".

JFTR: <https://github.com/arnowelzel/periodical>

Yes - I know how Android works ;-).

> The issue is whether the programmer has chosen to make the app write 
> data to the SD card, and whether the app has the necessary permission to 
> do so.

Correct. But apps don't need to write their to the SD card to store
their own data - therefore most apps just don't do this.



-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37070

In article <98f471b5-835a-7fd5-698a-cdc0e88929c2@arnowelzel.de>, Arno 
Welzel wrote:
>> The issue is whether the programmer has chosen to make the app
>> write data to the SD card, and whether the app has the necessary
>> permission to do so.
> 
> Correct. But apps don't need to write their to the SD card to store
> their own data - therefore most apps just don't do this.

Point taken.

However, I'd say that some of an app's data is internal in nature, but 
some is external, and in that latter case the app developer *should* 
give the user the option to store it on external media.

In the (special) case of the camera app there will be settings -- e.g. 
the flash on/off/auto setting -- that apply to that app on that device 
and don't need to be accessed by anything else, but there are also the 
actual photographs that other apps might want/need to read. 

A mail app, for example, might need to read the photos so that it can 
attach them, a photo-editing program might need to read the photographs 
to make changes (and might also want to write back updated versions).

The photos are typically stored as JPEG files; JPEG is a common format 
used by many other applications both on Android and on other systems. 
The whole point of having portable file formats is to enable the files 
to be moved between devices/systems so it makes perfect sense to store 
them on removable media that can be read in another device.

Some people regularly transfer photographs between a camera and a PC by 
removing the card from the camera and inserting it into a card reader in 
the PC. I do that with my DSLR, but I don't do that with my phone. I do, 
however, value the fact that if my phone gets broken I can use this 
method to pull any data off the micro-SD card that hasn't yet been 
backed-up. 

An Android device's internal memory is a finite resource, and should be 
used sparingly. Apps should make sure that where an SD card is available 
they make provision for using it.

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37276

Daniel James wrote:

> In article <98f471b5-835a-7fd5-698a-cdc0e88929c2@arnowelzel.de>, Arno 
> Welzel wrote:
>>> The issue is whether the programmer has chosen to make the app
>>> write data to the SD card, and whether the app has the necessary
>>> permission to do so.
>>
>> Correct. But apps don't need to write their to the SD card to store
>> their own data - therefore most apps just don't do this.
> 
> Point taken.
> 
> However, I'd say that some of an app's data is internal in nature, but 
> some is external, and in that latter case the app developer *should* 
> give the user the option to store it on external media.

The problem is once again - security.

As soon as you allow to store *any* data on an SD card this also means
that it is readable by *anyone* and not only the app involved.

Of course one could say, that it is the users responsibility to deal
with this. But how many people do really understand the implication of
putting data on a media which can be read by any app with storage
permission?

> In the (special) case of the camera app there will be settings -- e.g. 
> the flash on/off/auto setting -- that apply to that app on that device 
> and don't need to be accessed by anything else, but there are also the 
> actual photographs that other apps might want/need to read. 

That's the reason why camera apps usually allow to store photos on the
SD card as well (or the "internal" media storage) so other apps like
"gallery" apps or e-mail apps can read them.

> An Android device's internal memory is a finite resource, and should be 
> used sparingly. Apps should make sure that where an SD card is available 
> they make provision for using it.

No - only if it makes sense. Putting *everyhing* on an SD card just
because it is there, makes no sense. If you need this, then format the
SD card in Android as "internal memory" - then it is also protected
agains unauthorized access BTW.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37302

In article <60f194ae-3c1d-5179-2ade-25c34f5528ee@arnowelzel.de>, Arno 
Welzel wrote:
>> However, I'd say that some of an app's data is internal in nature,
>> but some is external, and in that latter case the app developer
>> *should* give the user the option to store it on external media.
> 
> The problem is once again - security.
> 
> As soon as you allow to store *any* data on an SD card this also
> means that it is readable by *anyone* and not only the app involved.

Yes, of course ... but we're talking about a removable SD card, here. 
There is NO POINT in trying to implement security within Android when 
the user can take the card out and mount it in a PC and read/write 
everything anyway.

If you care about security in that case you simply encrypt the data.

> Of course one could say, that it is the users responsibility to deal
> with this. But how many people do really understand the implication of
> putting data on a media which can be read by any app with storage
> permission?

I think that the fact that the card is removable sends a pretty strong 
signal to anyone who understands anything about data.

>> In the (special) case of the camera app there will be settings --
>> e.g. the flash on/off/auto setting -- that apply to that app on
>> that device and don't need to be accessed by anything else, but
>> there are also the actual photographs that other apps might
>> want/need to read. 
> 
> That's the reason why camera apps usually allow to store photos on
> the SD card as well (or the "internal" media storage) so other apps
> like "gallery" apps or e-mail apps can read them.

Your comment seems a little confused ...

Android apps can access the images in the DCIM directory in internal 
storage without any special permission, but can only access images in 
the DCIM directory on an SD card if they have permission to read 
external storage.

My point, again, is that the files on external storage can always be 
read by mounting that storage on another device (PC, etc) so requiring 
special permission for that is daft. Files in internal storage can only 
be read by Android apps, so there would be some point in requiring 
permission for that, but ironically none is needed.

>> An Android device's internal memory is a finite resource, and
>> should be used sparingly. Apps should make sure that where an SD
>> card is available they make provision for using it.
> 
> No - only if it makes sense. Putting *everyhing* on an SD card just
> because it is there, makes no sense. If you need this, then format the
> SD card in Android as "internal memory" - then it is also protected
> agains unauthorized access BTW.

I wrote "make provision for using it", not "force the user to use it all 
the time". My point is that only the user knows what meets his own 
requirements, and the user should be in a position to decide how the 
available storage should be used. That requires app writers to write 
their apps so that they give the user the choice.

Formatting the SD card as "internal" storage is not the answer if the 
user wants to be able to transfer data by removing the card and reading 
it in another device.

It's not an everyday event, but when my first Android phone failed (the 
screen suddenly decided to display an intricate pattern of many colours, 
instead of text) I was very grateful for the fact that all my data were 
on an SD card because (a) some data had not yet been backed up, and (b) 
I could return the phone for repair without worrying too much about 
personal data being left in memory (it was impossible to do a factory 
reset without being able to read the screen).

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37657

Daniel James wrote:

> In article <60f194ae-3c1d-5179-2ade-25c34f5528ee@arnowelzel.de>, Arno 
> Welzel wrote:
>>> However, I'd say that some of an app's data is internal in nature,
>>> but some is external, and in that latter case the app developer
>>> *should* give the user the option to store it on external media.
>>
>> The problem is once again - security.
>>
>> As soon as you allow to store *any* data on an SD card this also
>> means that it is readable by *anyone* and not only the app involved.
> 
> Yes, of course ... but we're talking about a removable SD card, here. 
> There is NO POINT in trying to implement security within Android when 
> the user can take the card out and mount it in a PC and read/write 
> everything anyway.

It's not about the *user* - the security protects the data agains *apps*
on the device.

> If you care about security in that case you simply encrypt the data.

Which does not protect data from being read by other apps on the device
itself since the devices will have access to *all* data on the card.

>> That's the reason why camera apps usually allow to store photos on
>> the SD card as well (or the "internal" media storage) so other apps
>> like "gallery" apps or e-mail apps can read them.
> 
> Your comment seems a little confused ...

Why?

> Android apps can access the images in the DCIM directory in internal 
> storage without any special permission, but can only access images in 
> the DCIM directory on an SD card if they have permission to read 
> external storage.

No, they need storage access even for the "internal" storage. It's only
called "internal" because it uses another mount point in the file
system. But nevertheless it is treated as "storage".

> My point, again, is that the files on external storage can always be 
> read by mounting that storage on another device (PC, etc) so requiring 
> special permission for that is daft. Files in internal storage can only 
> be read by Android apps, so there would be some point in requiring 
> permission for that, but ironically none is needed.

No, because it's about APPS on the DEVICE ITSELF and not other devices.

[...]
> Formatting the SD card as "internal" storage is not the answer if the 
> user wants to be able to transfer data by removing the card and reading 
> it in another device.

So the user has to decide what he want's - either secured storage or
simple transfer. Android does not provide both at the same time.

> It's not an everyday event, but when my first Android phone failed (the 
> screen suddenly decided to display an intricate pattern of many colours, 
> instead of text) I was very grateful for the fact that all my data were 
> on an SD card because (a) some data had not yet been backed up, and (b) 
> I could return the phone for repair without worrying too much about 
> personal data being left in memory (it was impossible to do a factory 
> reset without being able to read the screen).

And I do backups in a different way by saving the data on my PC via ADB
or MPE - because I have seen failing SD cards too often. And even when
you have all you data on the SD card you still have a lot of personal
data on the device, e.g. your Google account information if you use
Google services to install Apps etc.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37753

In article <a2e50d8a-4983-8f71-e13b-526cef47b069@arnowelzel.de>, Arno 
Welzel wrote:
>> Yes, of course ... but we're talking about a removable SD card, here. 
>> There is NO POINT in trying to implement security within Android when 
>> the user can take the card out and mount it in a PC and read/write 
>> everything anyway.
> 
> It's not about the *user* - the security protects the data agains
> *apps* on the device.

It *is* about the user, to the extent that it is the user who should get 
to choose whether or not to trust the other apps with his data.

>> If you care about security in that case you simply encrypt the data.
> 
> Which does not protect data from being read by other apps on the
> device itself since the devices will have access to *all* data on
> the card.

It doesn't protect the encrypted data written to the card from being 
read in its encrypted form by other apps, but those apps can't decrypt 
the data (they could corrupt it, though, if they can write to the card).

If other apps can read the cleartext data in memory then we have more to 
worry about than permissions to access the card.

Note that I'm not talking about card-wide encryption that can be 
performed by Android, here, but application-specific encryption carried 
out by individual apps using encryption keys that are not available to 
other apps.

Essentially, though, you should not install any apps that you don't 
trust, and have good reason to trust. Running dodgy software and hoping 
that Android will somehow save you from its actions is bound to end in 
tears.

>> Android apps can access the images in the DCIM directory in internal 
>> storage without any special permission, but can only access images in 
>> the DCIM directory on an SD card if they have permission to read 
>> external storage.
> 
> No, they need storage access even for the "internal" storage. It's
> only called "internal" because it uses another mount point in the
> file system. But nevertheless it is treated as "storage".

Yes, sorry ... that little word "internal" confused me. Android uses the 
term "external" to refer to both emulated and physical storage areas and 
we've been using "internal" to refer to an emulated external storage 
area ... what with the tortuous naming in Android and the fact that the 
rules change between SDK versions it's amazing anyone gets this stuff 
right! The docs (sometimes) talk about "primary" (aka emulated) and 
"secondary" (aka physical) external storage, but don't often enough 
(IMHO) distinguish between them.

However, we were talking about photos, and they're stored in a "public" 
area (the DCIM directory) of "external" storage (that may be emulated in 
internal memory). 

Being a public area, of course, the DCIM directory is readable by all 
apps so your point about protecting data from other apps doesn't apply.

Note: I have read (but I have not tested or verified this) that the 
READ_EXTERNAL_STORAGE permission is required to read a public directory 
in external storage if it is held on a physical SD card (or USB stick) 
but not if it's on an emulated SD card ... maybe that's not correct?

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37754

Daniel James wrote:

> In article <a2e50d8a-4983-8f71-e13b-526cef47b069@arnowelzel.de>, Arno 
> Welzel wrote:
>>> Yes, of course ... but we're talking about a removable SD card, here. 
>>> There is NO POINT in trying to implement security within Android when 
>>> the user can take the card out and mount it in a PC and read/write 
>>> everything anyway.
>>
>> It's not about the *user* - the security protects the data agains
>> *apps* on the device.
> 
> It *is* about the user, to the extent that it is the user who should get 
> to choose whether or not to trust the other apps with his data.

Maybe there is a misunderstanding about "file system encryption".

[...]
> Note that I'm not talking about card-wide encryption that can be 
> performed by Android, here, but application-specific encryption carried 
> out by individual apps using encryption keys that are not available to 
> other apps.

Of course not. But I talked about the Android storage encryption for the
device and SD cards. Application specific encryption is something
completely different.

> Essentially, though, you should not install any apps that you don't 
> trust, and have good reason to trust. Running dodgy software and hoping 
> that Android will somehow save you from its actions is bound to end in 
> tears.

Yep.

[...]
> Note: I have read (but I have not tested or verified this) that the 
> READ_EXTERNAL_STORAGE permission is required to read a public directory 
> in external storage if it is held on a physical SD card (or USB stick) 
> but not if it's on an emulated SD card ... maybe that's not correct?

It is. The word "external" is more a historical thing from the days were
devices only had very limited internal flash memory. Nowadays it is
usually "internal" and some devices *also* allow to use SD cards in
addition.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37317

On 1/4/2017 12:59 AM, Arno Welzel wrote:

> As soon as you allow to store *any* data on an SD card this also means
> that it is readable by *anyone* and not only the app involved.

Depends on the phone. Some Android phones (like mine) have a switch in 
settings to encrypt the card.

[toc] | [prev] | [next] | [standalone]

#37658

AL wrote:

> On 1/4/2017 12:59 AM, Arno Welzel wrote:
> 
>> As soon as you allow to store *any* data on an SD card this also means
>> that it is readable by *anyone* and not only the app involved.
> 
> Depends on the phone. Some Android phones (like mine) have a switch in 
> settings to encrypt the card.

Even then all apps can read the data. Encryption just means, that no
*other* device can read it.


-- 
Arno Welzel
https://arnowelzel.de
https://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#37374

On Wed, 4 Jan 2017 08:59:53 +0100, Arno Welzel wrote:

> Putting *everyhing* on an SD card just
> because it is there, makes no sense. If you need this, then format the
> SD card in Android as "internal memory" - then it is also protected
> agains unauthorized access BTW.

Is this compromise possible? -- partition the SD card into 2 drives, one to
be exploited 'as "internal memory"', as you say, the other as external SD
card space? That could give the best of both worlds :-) . Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

#37505

In article <1j82t0lhjggh1$.11lzxyrmqqrc9.dlg@40tude.net>, Tlvp wrote:
> Is this compromise possible? -- partition the SD card into 2 drives,
> one to be exploited 'as "internal memory"', as you say, the other
> as external SD card space?

Apparently not. I've recently acquired an Android 6 device and had a 
look at the way the card is partitioned by the phone as "internal" and 
as "portable" storage.

When I selected "portable" storage the card was formatted in the same 
way as a PC or an earlier version of Android would format it: with a 
BIOS-style partition table and a single FAT32 (or exFAT) data partition.

When I selected "internal" storage the card was formatted with a GUID 
partition table and two partitions of non-standard types (or, rather, of 
types private to Android) and the labels "android_meta" and 
"android-expand".

As the two types of cards don't even use the same partitioning scheme, I 
don't see how a card could be set up to offer a partition of each type!

Pity.

-- 
Cheers,
 Daniel.
 

[toc] | [prev] | [next] | [standalone]

#37509

On Sat, 07 Jan 2017 14:14:32 -0000, Daniel James wrote:

> As the two types of cards don't even use the same partitioning scheme, I 
> don't see how a card could be set up to offer a partition of each type!

Hmm ... no way to do that using something like parted? ... worth trying? 

Cheers, -- tlvp
-- 
Avant de repondre, jeter la poubelle, SVP.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.mobile.android

csiph-web