fidzu : smartphone

Posted by Edward Cunningham, Android Security & Privacy Team

In a previous blog we described how API behavior changes advance the security and privacy protections of Android, and include user experience improvements that prevent apps from accidentally overusing resources like battery and memory.

Since November 2018, all app updates on Google Play have been required to target API level 26 (Android 8.0) or higher. Thanks to the efforts of thousands of app developers, Android users now enjoy more apps using modern APIs than ever before, bringing significant security and privacy benefits. For example, during 2018 over 150,000 apps added support for runtime permissions, giving users granular control over the data they share.

Today we're providing more information about the Google Play requirements for 2019, and announcing some changes that affect apps distributed via other stores.

Google Play requirements for 2019

In order to provide users with the best Android experience possible, the Google Play Console will continue to require that apps target a recent API level:

• August 2019: New apps are required to target API level 28 (Android 9) or higher.
• November 2019: Updates to existing apps are required to target API level 28 or higher.

Existing apps that are not receiving updates are unaffected and can continue to be downloaded from the Play Store. Apps can still use any minSdkVersion, so there is no change to your ability to build apps for older Android versions.

For a list of changes introduced in Android 9 Pie, check out our page on behavior changes for apps targeting API level 28+.

Apps distributed via other stores

Targeting a recent API level is valuable regardless of how an app is distributed. In China, major app stores from Huawei, OPPO, Vivo, Xiaomi, Baidu, Alibaba, and Tencent will be requiring that apps target API level 26 (Android 8.0) or higher in 2019. We expect many others to introduce similar requirements - an important step to improve the security of the app ecosystem.

Over 95% of spyware we detect outside of the Play Store intentionally targets API level 22 or lower, avoiding runtime permissions even when installed on recent Android versions. To protect users from malware, and support this ecosystem initiative, Google Play Protect will warn users when they attempt to install APKs from any source that do not target a recent API level:

• August 2019: New apps will receive warnings during installation if they do not target API level 26 or higher.
• November 2019: New versions of existing apps will receive warnings during installation if they do not target API level 26 or higher.
• 2020 onwards: The target API level requirement will advance annually.

These Play Protect warnings will show only if the app's targetSdkVersion is lower than the device API level. For example, a user with a device running Android 6.0 (Marshmallow) will be warned when installing any new APK that targets API level 22 or lower. Users with devices running Android 8.0 (Oreo) or higher will be warned when installing any new APK that targets API level 25 or lower.

Prior to August, Play Protect will start showing these warnings on devices with Developer options enabled to give advance notice to developers of apps outside of the Play Store. To ensure compatibility across all Android versions, developers should make sure that new versions of any apps target API level 26+.

Existing apps that have been released (via any distribution channel) and are not receiving updates will be unaffected - users will not be warned when installing them.

Getting started

For advice on how to change your app's target API level, take a look at the migration guide and this talk from I/O 2018: Migrate your existing app to target Android Oreo and above.

We're extremely grateful to the Android developers worldwide who have already updated their apps to deliver security improvements for their users. We look forward to making great progress together in 2019.

21 Feb 2019 7:21pm GMT

Posted by Andrew Ahn, Product Manager, Google Play

Google Play is committed to providing a secure and safe platform for billions of Android users on their journey discovering and experiencing the apps they love and enjoy. To deliver against this commitment, we worked last year to improve our abuse detection technologies and systems, and significantly increased our team of product managers, engineers, policy experts, and operations leaders to fight against bad actors.

In 2018, we introduced a series of new policies to protect users from new abuse trends, detected and removed malicious developers faster, and stopped more malicious apps from entering the Google Play Store than ever before. The number of rejected app submissions increased by more than 55 percent, and we increased app suspensions by more than 66 percent. These increases can be attributed to our continued efforts to tighten policies to reduce the number of harmful apps on the Play Store, as well as our investments in automated protections and human review processes that play critical roles in identifying and enforcing on bad apps.

In addition to identifying and stopping bad apps from entering the Play Store, our Google Play Protect system now scans over 50 billion apps on users' devices each day to make sure apps installed on the device aren't behaving in harmful ways. With such protection, apps from Google Play are eight times less likely to harm a user's device than Android apps from other sources.

Here are some areas we've been focusing on in the last year and that will continue to be a priority for us in 2019:

Protecting User Privacy

Protecting users' data and privacy is a critical factor in building user trust. We've long required developers to limit their device permission requests to what's necessary to provide the features of an app. Also, to help users understand how their data is being used, we've required developers to provide prominent disclosures about the collection and use of sensitive user data. Last year, we rejected or removed tens of thousands of apps that weren't in compliance with Play's policies related to user data and privacy.

In October 2018, we announced a new policy restricting the use of the SMS and Call Log permissions to a limited number of cases, such as where an app has been selected as the user's default app for making calls or sending text messages. We've recently started to remove apps from Google Play that violate this policy. We plan to introduce additional policies for device permissions and user data throughout 2019.

Developer integrity

We find that over 80% of severe policy violations are conducted by repeat offenders and abusive developer networks. When malicious developers are banned, they often create new accounts or buy developer accounts on the black market in order to come back to Google Play. We've further enhanced our clustering and account matching technologies, and by combining these technologies with the expertise of our human reviewers, we've made it more difficult for spammy developer networks to gain installs by blocking their apps from being published in the first place.

Harmful app contents and behaviors

As mentioned in last year's blog post, we fought against hundreds of thousands of impersonators, apps with inappropriate content, and Potentially Harmful Applications (PHAs). In a continued fight against these types of apps, not only do we apply advanced machine learning models to spot suspicious apps, we also conduct static and dynamic analyses, intelligently use user engagement and feedback data, and leverage skilled human reviews, which have helped in finding more bad apps with higher accuracy and efficiency.

Despite our enhanced and added layers of defense against bad apps, we know bad actors will continue to try to evade our systems by changing their tactics and cloaking bad behaviors. We will continue to enhance our capabilities to counter such adversarial behavior, and work relentlessly to provide our users with a secure and safe app store.

How useful did you find this blog post?

★ ★ ★ ★ ★

13 Feb 2019 6:01pm GMT

Posted by Dave Smith, Developer Advocate for IoT

Over the past year, Google has worked closely with partners to create consumer products powered by Android Things with the Google Assistant built-in. Given the successes we have seen with our partners in smart speakers and smart displays, we are refocusing Android Things as a platform for OEM partners to build devices in those categories moving forward. Therefore, support for production System on Modules (SoMs) based on NXP, Qualcomm, and MediaTek hardware will not be made available through the public developer platform at this time.

Android Things continues to be a platform for experimenting with and building smart, connected devices using the Android Things SDK on top of popular hardware like the NXP i.MX7D and Raspberry Pi 3B. System images for these boards will remain available through the Android Things console where developers can create new builds and push app updates for up to 100 devices for non-commercial use.

We remain dedicated to providing a managed platform for IoT devices, including turnkey hardware solutions. For developers looking to commercialize IoT products in 2019, check out Cloud IoT Core for secure device connectivity at scale and the upcoming Cloud IoT Edge runtime for a suite of managed edge computing services. For on-device machine learning applications, stay tuned for more details about our Edge TPU development boards.

12 Feb 2019 7:00pm GMT

It took a few days, but I've finally migrated my site to Nikola. I used to have blog.mardy.it served by Google's Blogger, the main sections of www.mardy.it generated with Jekyll, the image gallery served by the old and glorious Gallery2, plus a few leftovers from the old Drupal site.

discussion by Nicolas Alejandro, on Flickr

While Jekyll is cool, I was immediately captivated by Nikola's ease of use and by its developers' promptness in answering questions in the forum. Also, one nice thing about Nikola (and Pelican, too) which I forgot to mention in my previous post is it's support for multilingual sites. I guess I'll have to translate this post in interlingua too, to give you a demonstration. :-)

Anyway, while I've fallen in love with static site generators, I still would like to give people the chance of leaving comments. Services like Disqus are easy to integrate, but given the way they can be (ab)used to track the users, I prefered to go for something self hosted. So, enter Isso.

Isso is a Python server to handle comments; it's simple to install and configure, and offers some nice features like e-mail notifications on new replies.

My Isso setup

Integrating Isso with Nikola was relatively easy, but the desire to keep a multilingual site and some hosting limitation made the process worth spending a couple of words.

FastCGI

First, my site if hosted by Dreamhost with a very basic subscription that doesn't allow me to keep long-running processes. After reading Isso's quickstart guide I was left quite disappointed, because it seemed that the only way to use Isso is to have it running all the time, or have a nginx server (Dreamhost offers Apache). Luckily, that's not quite the case, and more deployment approach are described in a separate page, including one for FastCGI (which is supported by Dreamhost). Those instructions are a bit wrong, but yours truly submitted some amendments to the documentation which will hopefully go live soon.

Importing comments

Isso can import comments from other sites, but an importer for Blogger (a.k.a. blogspot.com) was missing. So I wrote a quick and dirty tool for that job, and shared it in case it could be useful to someone else, too.

Multilingual sites

The default configuration of Nikola + Isso binds the comments to the exact URL that they were entered into. What I mean is that if your site supports multiple languages, and a user has entered a comment to an entry while visiting the English version of the site, users visiting the Italian version of the site would see same blog entry, but without that comment. That happens regardless of whether the blog entry has been translated into multiple languages or not: it's enough that the site has been configured for multiple languages.

My solution to fix the issue could not be accepted into Nikola as it would break old comments in existing sites, but if you are starting a new multilingual site you should definitely consider it.

Testers welcome

Given that I've deployed Isso as a CGI, it's understandable that it's not the fastest thing ever: it takes some time to startup, so comments don't appear immediately when you open a page. However, once it's started it stays alive for several seconds, and that seems to help with performance when commenting.

Anyway, the real reason why I've written all this is to kindly ask you to write a comment on this post :-) Extra points if you leave your e-mail address and enable the reply notifications, and let me know if you receive a notification once I'll reply to your comment. As far as I understand, you won't get a notification when someone adds an unrelated comment, but only when the "reply" functionality is used.

But really, should the commenting system be completely broken, I'm sure you'll find a way to contact me, if you need to. :-)

0 0

30 Jan 2019 8:21pm GMT

In the last few days I've been writing a simple website for Imaginario. I'm a terrible site designer, and I can't really say that I enjoy writing websites, but it's something that from time to time people might need to do. While the PhotoTeleport website is built with Jekyll, this time I decided to try some other static site generator, in order to figure out if Jekyll is indeed the best for me, or if there are better alternatives for my (rather basic) needs.

I set out trying a couple of Python-based generators, Pelican and Nikola. Here is a brief review of them (and of Jekyll), in case it helps someone else make their own choice.

Jekyll

I've been using it since several months for the PhotoTeleport website, which features a news section and a handful of static pages. It does the job very well and I haven't any major complaint. It's very popular and there are plenty of plugins to customize its behaviour or add new functionality. The documentation is sufficient for a basic usage of the site, and information on how to solve more specific issues can easily be found in the internet.

My only issue is that it's not totally intuitive to use, and in order to customize the interactions for your own needs you need to write your own scripts - at least, I didn't find a ready solution to create a new post, or deploy the generated content into my site.

Pelican

My first impression with Pelican has been extremely positive: it's very easy to setup and start a blog. It's also quite popular, even though not as much as Jekyll, and there are may themes for it. By looking at the themes, though, I quickly realized that Pelican is meant to be used for blogs, and not for simple static sites. I'm almost sure that there must be a way to use it to create a static site, maybe with some tweaking, but I couldn't find information about this in its documentation. A quick search in the internet didn't help either, so I gave up and moved to the next one.

If I had to write a blog I'd certainly consider it, though.

Nikola

Nikola is definitely less popular than Jekyll or Pelican, at least if we trust the number of stars and forks in GitHub, but it's still a popular and maintained project, with many plugins. Like Jekyll, it can handle both blogs and sites, or a combination of the two. It's well documented, the people in the forum are helpful, and its command line interface is simpler and more intuitive than Jekyll's. Also, the live preview functionality seems to be more advanced than Jekyll's, in that the browser is told to automatically reload the page whenever the site is rebuilt.

You can see my progress with the Imaginario website by inspecting the commits in its repository; you'll see how easy it was to set it up, and hopefully following my steps you'll save some time should you decide to create your own site with Nikola.

Overall, I'd rate Jekyll and Nikola on the same level: Jekyll wins for the wider community and amount of available plugins, while Nikola wins for the better command line interactions, and the fact that it's in Python gives me better confidence should I ever need to modify it deeply (though, admittedly, the latter is just a personal preference - Ruby developers will say the opposite).

0 0

20 Jan 2019 11:44am GMT

A Venetian gondoliere thought it a good idea to decorate his gondola with fascist symbols, yet he can't handle that others think it not a good "joke"

The post A Pathetic Human Being appeared first on René Seindal.

0 0

11 Dec 2018 3:40pm GMT

A small brain dump of topics that currently fascinate me. These are mostly pointers and maybe it is interesting to follow it.

Books/Reading:

My kobo ebook reader has the Site Reliability Engineering book and I am now mostly done. It is kind of a revelation and explains my interest to write code but also to operate infrastructure (like struggling with ruby, rmagick, nginx…). I am interested in backends since… well ever. The first time I noticed it when we talked about Kolab at LinuxTag and I was more interested in the backend than the KDE client. At sysmocom we built an IoT product and the backend was quite some fun, especially the scale of one instance and many devices/users, capacity planning and disk commissioning, lossless upgrades.

It can be seen in my non FOSS SS7 map work on traffic masquerading and transparent rewriting. It is also clear to see which part of engineering is needed for scale (instead of just installing and restarting servers).

Lang VM design

One technology that made Java fast (Hotspot) and has seen its way into JavaScript is dynamic optimization. Most Just in Time Compilers start with generating native code per method, either directly or after the first couple of calls when the methods size is significant enough. The VM records which call paths are hot, which types are used and then can generate optimized code (e.g. specialized for integers, remove type checks). A technique pioneered at Sun for the "Self" language (and then implemented for Strongtalk and then brought to Java) was "adaptive optimization and deoptimization" and was the Phd topic of Urs Hoelzle (Google's VP of Engineering). One of the key aspects is inlining across method boundaries as this removes method look-up, call stack handling and opens the way for code optimization across method boundaries (at the cost of RAM usage).

In OpenJDK, V8 and JavaScriptCore this adaptive optimization is typically implemented in C++ and requires quite some code. The code is complicated as it needs to optimize but also need to return to a basic function (deoptimize, e.g. if a method changed or the types passed don't match anymore), e.g. in the middle of a for loop with tons of inlined code (think of Array.map being inlined but then need to be de-inlined). A nice and long blog post of JSC can be found here describing the On Stack Replacement (OSR).

Long introduction and now to the new thing. In the OpensmalltalkVM a new approach called Sista has been picked and I find it is genius. Like with many problems the point of view and approach really matters. Instead of writing a lot of code in the VM the optimizer runs next to the application code. The key parts seem to be:

• Using branches taken/not-taken as indicator how hot a path is. The overhead of counting these seem to be better than counting method calls/instructions/loops.
• Using the Inline Caches for type information on call sites (is that mono-, poly- or megamorphic?)
• Optimize from one set of Bytecode to another set of Bytecode.

The revelation is the last part. By just optimizing from bytecode to bytecode the VM remains in charge of creating and managing machine code. The next part is that tooling in the higher language is better or at least the roundtrip is more quick (edit code and just compile the new method instead of running make, c++, ld). The productivity thanks to the abstraction and tooling is likely higher.

As last part the OSR is easier as well. In Smalltalk thisContext (the current stack frame, activation record) is an object as well. At the right point (when the JIT has either written back variables from register to the stack or at least knows where the value is) one can just manipulate thisContext, create and link news ones and then resume execution without all the magic in other VMs.

Go, Go and escape analysis

Ken Thompson and Robert Pike are well known persons and their Go programming language is a very interesting system programming language. Like with all new languages I try to get real world experience with the language, the tooling and which kind of problems can be solved with it. I have debugged and patched some bigger projects and written two small applications with it.

There is plenty I like. The escape analysis of the compiler is fun (especially now that I know it was translated from the Plan9 C compiler from C to Go), the concurrency model is good (though allowing shared state), the module system makes sense (but makes forking harder than necessary), being able to cross compile to any target from any system.

Knowing a bit of Erlang (and continuing to read the Phd Thesis of Joe Armstrong) and being a heavy Smalltalk user there are plenty of things missing. It starts with vague runtime error messages (e.g. panicslice not having parameters) and goes to runtime and post-runtime inspection. In Smalltalk thanks to the abstraction a lot of hard things are easy and I would have wished for some of them to be in Go. Serialize all unrecovered panics? Debugging someone else's code seems like pre 1980…

So for many developers Go is a big improvement but for some people with a wider view it might look like a lost opportunity. But that can only be felt by developers that have experienced higher abstraction and productivity.

Unsupervised machine learning

but that is for another dump…

25 Sep 2017 10:11am GMT

02 Sep 2017 10:00pm GMT

01 Sep 2017 10:00pm GMT

Shopping for 3D TV (again), few findings:

• There are no non-LED 3D TVs for sale in this part of world anymore (in particular, my older favorite, LE40C750 is no longer available)
• Samsung D6xxx series (the cheapest) were caught red-handed not providing FullHD resolution in 3D: via Samygo. (Note from myself: Samsung was caught because lots of people actually buy their stuff, what one can think about other vendors?)
• LG goes out of line of vendors with 3D shutter glasses technology with their FPR ("Cinema 3D" in marketing speak) technology. It uses passive (no power needed) polarized glasses, like RealD cimenas. Announced April (on these longitudes), already in local shops at not-so-indecent prices. FPR is Film Patterned Retarder, and I hope the last word is spelled right, because I have high hopes for this tech. It shares the same issue as Samsung D6xxx: there won't FullHD here for sure, but at least it's official and there're other benefits.

12 Nov 2011 6:55pm GMT

I finally going to get Arduino, and while I'm choosing flavor and waiting for it, I can't help but disassembling all devices I have at home, each time speaking: "This must have Arduino inside!" (meaning of course that I expect it to be based on general-purpose MCU). Gosh, I usually get "blob chip" (uncased chip with blob of epoxy on top).

Well, I finally had my expectations fulfilled - Luxeon SP-1 voltage stabilizer/cutter features ATMEGA48V-10PU (Flash: 4k, EEPROM: 256, RAM:512). Not only that, it is installed in DIP socket! Buy from Luxeon, they're hacker-friendly ;-).

I bought the device actually for a wattmeter it features (which fact is hard to figure out from common specs found in the shops, I accidentally read somebody mentioning it on a forum). The wattmeter is of course not bright - for a lamp rated 100W it shows 88W, and for more powerful equipment (like perforator) understates wattage even more (maybe it's difference between real and apparent power factor).

Still, for $17 you get Arudino-alike with voltage/current sensor and hacking possibility. Woot!

BOM:
High-power board:

• Relay: Coil: 24VDC, 5A/240VAC
• 7805
• Coil transformer LR-019B

MCU board:

• ATMEGA48V-10PU
• 2 buttons
• 2 LEDs (red & green)
• 3-digit 7-segment LED indicator

12 Nov 2011 5:58pm GMT

Kindle:

• Amazon Kindle official GPL source code
• Kindle keyboard shortcuts and other reference
• Latest jailbreak appears to be one from NiLuJe (forum). It's known to work with firmware 3.3. Hacks/updates should be copied to Kindle USB drive root.
• SirAlex's page
• Intro for writing kindlets
  

Linux kernel module tricks:

• How to bind Linux driver to device whose IDs it doesn't know (yet), without recompiling
• Building a kernel module separately
• (build module from a kernel source tarball using currently installed kernel config)

10 Nov 2011 3:21pm GMT

In Debian Unstable the transition to Gnome 3 is taking place; when Gnome 3.0 firstly came out some unnamed geeky users complained loudly about the design decisions of the development team to push strongly towards gnome-shell as a new default UI; gnome-shell was designed focusing on usability (usability is a metric relative to a certain target audience BTW) and simplicity, hiding a lot of details from the users. Obviously you can never make everyone happy so some of us simply happened to be "out of target": you know us computer people (*cough cough*), we like to be in charge and control The Machine... I must admit I still don't have a definitive opinion about the gnome-shell concept, for now I just know that it does not suit me; I am going to try it eventually, maybe I'll get used to it, but in the mean time I need my desktop back just like I shaped it through the years; can this be done without loosing all the good Gnome technologies (Empathy over all of them)?

To be completely fair I have to say that there is little to complain about with Gnome developers, we can still get our good old GNOME desktop fully back by using the fall-back mode based on gnome-panel and live happily ever after, let's take a look at how this can be accomplished.

NOTE: GNOME people state that the fall-back mode is meant for systems with older graphic cards which cannot run gnome-shell, however it can very well be seen as a good opportunity for those who do not want to run gnome-shell just yet.

Getting back to the topic: some minor touches are needed to make the panel look more like what we are used to, maybe some of these settings could even become default for fall-back mode, we'll see.

First, enable fall-back mode (on Debian there is a dedicated session you can choose from the Log-in Manager for that) and change some desktop settings, in a terminal type:

$ gsettings set org.gnome.desktop.session session-name 'gnome-fallback'
$ gsettings set org.gnome.desktop.interface 'menus-have-icons' true
$ gsettings set org.gnome.desktop.interface 'buttons-have-icons' true
$ gsettings set org.gnome.desktop.background 'show-desktop-icons' true

gnome-tweak-tool can be used for some of these settings like shown in the attached images.

Then rearrange the applets on the panel as you please (use Alt-RightClick to access the panel properties), and fix the theming using this patch to have a light panel again (against gnome-themes-standard=3.0.2-1):

$ mkdir $HOME/.themes
$ cd $HOME/.themes
$ cp -r /usr/share/themes/Adwaita Adwaita-fallback
$ cd Adwaita-fallback
$ patch -p1 < $HOME/adwaita-fallback-panel-theme.patch
$ gsettings set org.gnome.desktop.interface 'gtk-theme' 'Adwaita-fallback'

Some final touches for the Metacity window manager and to the clock applet, and we are all set:

$ gconftool-2 --type string --set /apps/metacity/general/focus_mode mouse
$ gconftool-2 --type boolean --set /apps/metacity/general/compositing_manager true
$ gconftool-2 --type string --set /apps/panel3-applets/clock/custom_format '<span color="#333">%a %d %b</span> <b>%H:%M</b>'
$ gconftool-2 --type string --set /apps/panel3-applets/clock/format custom

Ah, in the new gnome-panel based on Gtk3 there are still some details to take care of, I hope issues like that will be addressed and that the panel will be supported for quite some time.

Attached images:

Attached files:

Adwaita theme patch for fall-back mode

19 Oct 2011 9:37pm GMT

After letting us wait for a bit longer than scheduled (13 days), the hospital initiated the contractions. For the first couple of hours, everything went just perfect, but then the little one got stuck on the way and we had to resort to a cesarean section. Lara Marie Lauer was born 8th of June at 04:41 (AM) with 3460 gramms and 49 cm.

Mummy was still on intensive care and so they gave her to me. I can't express the feelings I had in this very moment. I'm still kind of overwhelmed every time I see her. Thanks for all of you who waited anxiously with me and those who prayed for us. The most important tasks for the near future is getting Mummy to recover and Lara Marie to become accustomed to us and the rest of the outside world.

Please bear with me if in the next time I'm not as responsive as usually

09 Jun 2011 4:06pm GMT

And now for something completely different… while we are all waiting for my baby to arrive (who was scheduled for 25th of May), she just received her first greeting card - together with a personalized bib and a towel (with integrated hood - pretty fancy!) from my good friends at #openmoko-cdevel.

Guys, seeing this card was very heartwarming - it means a lot to me that you share my anticipation, thanks a lot! And I'm 100% sure she will appreciate her gifts… now let's cross fingers it won't take much longer… waiting is the hardest part of it

Yours,

Mickey.

30 May 2011 8:54am GMT