hello!

how can I help you today?

Hello Mark, i have e question about the chapter "Blicking rotations" in "Resources sets and configurations"

I am not certain what "Blicking rotations" means, but, go ahead

i use the attribute: android:screenOrientation="portrait" but i don't understand when you say that: "Also note that Android still treat this as a configuration change..." when i tested it, i don't see anything. Sorry i would say "Blocking rotations" chapter

Android still destroys and re-creates the activity, even though you have android:screenOrientation set

so, even though from the user's perspective nothing should be changing based on screen orientation, your code still needs to handle the configuration change, via the various approaches outlined in the chapter

Yacire: let me take a question from Arun, and I will be back with you shortly

hi mark

Arun: your turn! do you have a question?

my question is: lets say I want to store a token in sharedpreferences or internal storage

but if the device is rooted, someone can take the token right?

yes

so the solution would be to encrypt it before storing it

that will not be much of an impediment

but my question is, where do you put the key?

ah

because of the key issue

your only real options are to have the key baked into the code or have the key stored as yet another file

either of which can be used by the same root user

i see

so storing it in sharedprefs is really the most secure solution?

no, that is no better than in a plain file

since a SharedPreferences *is* a plain (XML) file

on internal storage

ok

is there a better solution?

you can ignore the problem, or you can not store the token (only hold it in RAM)

I am not aware of much else

i see

any scenario in which you treat the user as the enemy is going to be a problem

ok. thanks

since the user "holds the high ground", so to speak

i see

ok that answers my current question

let me switch back to Yacire for a bit, and I'll return to you shortly

Yacire: back to you! do you have another quesion?

er, question?

Ok thanks, but i don't see this. I have a bluetooth connection between my smartphone and a bluetooth low energy module and i tested the connection with the attribute android:screenOrientation and without. I disable the bluetooth connection in the onDestroy() method, and what i see, is with the attribute android:screenOrientation="portrait", when i rotate the device, the callback method onDestroy() isn't called.But whithout the attribute, the method is called.

it is possible that they changed the behavior somewhere along the line, but it definitely destroyed and recreated the activity

you had to *also* use android:configChanges to prevent that

are you using android:configChanges in your manifest?

No, just android:screenOrientation.

:: shrug ::

what version of Android are you running your app on?

Android lollipop and kitkat (with two physical devices)

I will run some tests and see if I can reproduce your findings

ok i wait here or i come back next time ?

you can wait; this should not take long

in the meantime...

Arun: do you have another question?

ok thanks

Yacire: well, in preliminary tests, I can reproduce your findings on 6.0 and 4.3

I wish they would document these changes

I'll do a more thorough round of tests sometime in the next few weeks, to determine when this change came about, or if something else is somehow causing the difference (AppCompatActivity?)

it's ok. Yes i use AppcompatActivity, maybe it the reason

I can't imagine how, but it is one of the variables

thnkas for your help, i have not another question, bye :)

OK, thanks for pointing this out!

hi mark sorry was afk

i do have another question

go right ahead

what is the best way to access Context from a fragment?

i've been storing an instance var in onAttach()

and nulling it out in onDetatch()

but is there a known best solution?

getActivity() works just as well

so as not to cause memory leaks

it should return a non-null value so long as your fragment is attached to a hosting activity

ok

maybe i'm overthinking it haha

Hi everybody

conversely, if getActivity() does return null, the question is: should you be doing whatever it is that you are doing in that fragment at that point in time?

ok

Arun: let me take a question from Rob, and I'll be back with you shortly

sure

Rob: hi! how can I help you today?

I'm trying to write an app that needs to be preinstalled with system permissions. Is there a preferred method to running processes that require root permissions without needing to root the device through conventional means (superSU)

beats me

true

that's getting deeper into how device manufacturers/custom ROM developers do their thing

which is outside of my skill set

gotcha. do you know of any good resources for that or does that kind of thing fall under NDA

presumably, since you are pre-installing the app, you have some control over (or at least know) the Linux user ID for the app

so, in theory, you should be able to grant rights to that app, or to some Linux user group that you add that app's UID to

I've gotten as far as signing the apk with the platform key which lets you set the shared user id to system

in this case, you may not want that, unless you want all apps with the system shared UID to have the same rights

basically, "root" isn't really an Android thing; it's a Linux thing

hmm interesting

so, my assumption would be that you treat this along the same lines of how you grant certain rights to UIDs associated with certain Linux programs (e.g., the UID for your Web server daemon)

but, that's just a lightly educated guess

you might try Karim Yaghmour's _Embedded Android_ book

will an app's user ever change?

only if the app is uninstalled/reinstalled, or an upgrade changes the sharedUserId value

ah ok

in your case, the app probably can't be uninstalled

(outside of rooted devices, which are a whole 'nuther ball of wax)

but it could be updated so long as I don't touch the sharedUserID

yes

cool

thanks for the tip

changing android:sharedUserId can change the Linux UID

I'm going to check out that book

which is why Android SDK developers *really* shouldn't mess with android:sharedUserId, or should set it correctly before ever shipping the app

it's really more for situations like yours, where you control the ROM

can I set up a specific account on the system just for an app

presumably

though for a single app, the account it gets by default should be fine, so long as you know what it is

yeah I'm in kind of a weird spot when it comes to SDK development, since we're making an app that will reside on the app and will not be upgraded by a user unless an update is shipped

ok

anyway, Karim's book is basically "how to create an Android device"

Thanks for the help, do you mind if I bump another post on SO today (unreleated to this_

you might also poke around XDA and other sites with an emphasis on custom ROM development

sure

cool

let me switch back to Arun, and I'll return to you shortly

Arun: your turn! do you have another question?

np, I'm going to depart

i dont right now

OK

if i think of one before 10, ill ask if you're not busy

at this point, it's pretty much free-for-all

if either of you have a question, go right ahead

Rob: I have never tried using a camera sans preview, so I cannot really help you with your SO question, sorry!

I have a question:

in general, do we want to enable hardware acceleration for view animations?

on Android 4.0+, hardware acceleration is enabled by default

at least, IIRC

ok, so only if you're targetting older sdks do you need to explicitly specify it

right?

possibly

ok thanks

prior to Android 3.0, the GPU was not used for 2D graphics acceleration, only for OpenGL

IIRC, hardware acceleration was opt-in for Android 3.x and opt-out for Android 4.0+

what is the difference?

but, my memory is fuzzy in this area

i see

what is the difference between what?

between openGL and 2D graphics acceleration

im not clear on what opengl is

OpenGL is 3D graphics

mostly used by games

got it

so, for example, early versions of Angry Birds were written using OpenGL, even though the game was only 2D, because they needed the graphics acceleration on the older devices

interesting

effectively, they used a 3D graphics API to render 2D graphics, because that was faster than rendering 2D graphics directly

thats pretty funny

it's a side effect of how Google wrote the specifications for what Android required in terms of hardware

eventually, Android "tightened the screws" on GPU requirements, which allowed them to start using the GPU for 2D work

which, in turn, translates into isHardwareAccelerated() and so forth

is this true even if you use the older objectAnimator methods to animate views,

instead of using ViewPropertyAnimator?

I do not recall if TranslateAnimation and kin get hardware accelerated

I would think so, but I am not certain

ok

thats all i got for now. Thanks for your help Mark.

Rob: in case you missed my earlier note, I have never tried using a camera sans preview, so I cannot really help you with your SO question, sorry!