I'm working on an application that requires support for forward locking of media files on Android (1.6 and above). Of course, there appears to be no documentation in the APIs on how this might work.
The two questions I have are firstly whether forward locking is supported on Android (and in which versions of the platform) and secondly how to implement it in a program that, for example, downloads DRMed ringtones and wallpapers.
Android isn't that big on DRM, because of the open source heritage of the product. I think you'll have to implement any DRM solution yourself.
Forward lock means that your application offers no way to use protected content on other devices. Literally this means that your application must not have functionality for forwarding (sending) protected content to other devices or for writing to a file system or something else like that. For an open platform like Android that as well might require encrypting/obfuscating your applications content store to prevent access from other apps or from a USB-connected host computer.
A forward lock is identified by a flag in the media metadata (format is media-dependent IMHO). The content is not encrypted. Thus a forward lock is a simple check per content item to disable forwarding functionality as needed.
The whole concept came from and worked with closed embedded devices (like typical mobile phones 5 years ago) and sounds strange with open platforms like Android.
You have to ensure the applications which may want to transfer content to another device via bluetooth etc dont get the permission to transfer it.
OMA has defined how forward lock works. Hence that way you are sure of what has to be done.
You have to check the header information of the content to get information on whether it has to be forward locked or not.
Related
There are apps like Texpand which are able to replace text in any EditText view - even of views which are part of other apps. Looking at the app-info this is happening without any requested permissions. I'm scratching my head how this is done - my (rookie) understanding is that each app resides in its own separated sandbox, so it should not have direct access to other apps views?
I looked for possible global events which could be provided by any central manager, but found nothing. More likely I would expect the replacement to be done passively (that means without the app being aware of the actual EditText), but checking for possible bindings or user dictionaries I found nothing promising either.
Looking at my Android system it seems the app is neither using permissions nor installing a keyboard. Additionally I don't see any entries in my user dictionary. Does anybody have an idea how the described functionality could actually be achieved?
Texpand's Google Play posting indicates that it uses Accessibility Services. Accessibility services are a set of APIs Android offers to help build tools to allow non-standard interactions with apps (such as audio descriptions/voice commands) to expand access to the platform to people with an impairment that might otherwise prevent them from using a touch-screen/smart-phone.
These include the ability to take action on the behalf of a user, such as filling in text fields.
I have an Android app that I would like to add the ability for the user to "cast" what is displayed on the app to a Chromecast. It could just be a local JPG but I would prefer the user to actually see actual "live" content of the app. Does anyone know if this is possible? I know there are apps like AllCast but wasn't sure if they were using supported features of the SDK or if it was a hack. I found some mention of the Default Media Receiver but could not find any documentation on how to use it with local content. Any advice or direction would be appreciated.
There is no Cast api to do that directly; you can look into WebRTC or something of that nature.
The way I do it is to use the Presentation class. The only problem is that you do need to use the ChromeCast app to start screen mirroring before you start your app.
I have not yet found a way to start mirroring my app (or, to be more precise, to show the contents of your Presentation class) from a ChromeCast UIButton within my app, even though I have been able to get that cast button working and connecting ... just not to start app-mirroring when using only my in-app chromecast button.
I recently used Talk back on an Android device. Some apps don't work well with the Talk Back screen reader because the it's not developed according to the accessibility API. Is there any way that I can access the UI of these apps (from OS level) and manipulate them to be compatible with Talk back?
No. Such change should be made in code. There is no way to modify it from OS level.
Those changes have to be made in XML or Java. User cannot access these values from system layer (security policy). You can refer to: Android Developer guidlines for accesibility. Without proper 'contentDescription' set TalkBack is unable to retrive any information about some views: images, imagebuttons etc.
is it somehow possible to create an Android application / service that blocks an URL (or a list or URLs)?
From what I have searched here on StackOverflow and on Google it doesn't seems possible:
https://groups.google.com/forum/?fromgroups#!topic/android-security-discuss/ciepvxyn8UY
However, Norton Safety Minder somehow "blocks" certain websites, although:
It lets the page load entirely before redirecting user (any idea on how they do it?)
It only seems to work for the stock browser (any ideia why? maybe they are listening for changes in the browser bookmark history?)
is it somehow possible to create an Android application / service that blocks an URL (or a list or URLs)?
Not really, for unrooted devices. With root, you might be able to rig up some iptables stuff to route things through some transparent proxy.
It only seems to work for the stock browser (any ideia why? maybe they are listening for changes in the browser bookmark history?)
Given the one Play Store comment ("Going incognito mode bypasses the Web filters. Please fix."), that would be my guess. Script-kiddie techniques like that are never going to be reliable.
Does Android support visually impaired users in the same way as HTML alt tags are used to provide input for screen readers on the web?
If so, what is the best practice to code Buttons and ImageViews etc so they can be read by a screen reader?
I'm not quite clear on your question. The internet browser, or any applications that rely heavily on HTML rendering are not accessible This quote is taken from this blog post.
You can turn on the accessibility features by going to Settings --> Accessibility and checking the box "Accessibility". While the web browser and browser-based
applications do not yet "talk" using these enhancements, we're working on them for upcoming releases.
Android does provide screen reader support for a lot of applications, see this wiki page for a list of applications known to work well with Android using a free and open source screen reader.
I can't find any general guidelines for creating accessible apps but this LinkedIn group may be helpful. I don't have a LinkedIn account though so don't know how active the group is.
The best resource I've found on the Android Accessibility API is this code walk through: https://sites.google.com/site/gdevelopercodelabs/android/accessibility
See http://developer.android.com/guide/practices/design/accessibility.html for plenty of details on writing an accessible app.
The nearest equivalent to HTML's ALT is the contentDescription property - set in code or in XML.
If you are creating you own custom control, you'll need to do a bit more work to specify other details too; more details at the link above.
Most important thing: when you're done, test with TalkBack, the free Android screenreader from Google. (It's pre-installed on some Android models, but you can download from Android Market if you don't already have it.) You should be able to navigate to all the interactive elements in your app using the directional pad alone, and TalkBack should read out appropriate values for all elements as it does so. (It should pick up the contentDescription and read it out here.)
One thing to watch for is that from what I remember, the screenreader only reads out things that you can navigate to, so if you have instructional text on the page, it may not read out, so you may need to ensure that the contentDescription for other controls is suitably descriptive. To be sure, test with TalkBack, and see for you self (er, hear for yourself!) if what is read out makes sense.
(As noted in one of the other replies, although Android has an accessibility API, the Android browser doesn't actually support it (yet), so HTML pages - even properly marked up HTML code - isn't accessible on Android using the default browser. There are a couple of 3rd party browsers that add accessibility to HTML, though, such as the free IDEAL Web Reader app, which appears to wrap the Android HTML control and then add voicing on top of it. Hopefully Android will make their default browser fully accessible in some later release...)